Java does not have the same concept as the "sabotage" of C + +. In C + +, the destruction method is automatically invoked once the object is destroyed (cleared). The reason to omit it is probably because in Java you simply forget objects without forcing them to break. The garbage collector automatically reclaims memory when necessary.
Garbage collectors work well most of the time, but in some cases our classes may take some action during their own existence, and these actions require a clear cleanup effort. As the 4th chapter has pointed out, we do not know when the garbage collector will become apparent, or when it will be invoked. So once you want to clear something for a class, you have to write a special way to do it explicitly and specifically. Also, let the client programmer know that they have to call this method. And behind all this, as in chapter 9th (violation control) to be explained in detail, such a purge code must be placed in a finally clause to prevent any possible violations.
The following is an example of a computer-aided design system that can depict graphics on the screen:
: Cadsystem.java//Ensuring proper cleanup import java.util.*;
Class Shape {shape (int i) {System.out.println ("shape constructor");
} void Cleanup () {System.out.println ("Shape cleanup");
Class Circle extends Shape {Circle (int i) {super (i);
System.out.println ("Drawing a Circle");
} void Cleanup () {System.out.println ("erasing a Circle");
Super.cleanup ();
Class Triangle extends Shape {triangle (int i) {super (i);
System.out.println ("Drawing a triangle");
} void Cleanup () {System.out.println ("erasing a triangle");
Super.cleanup ();
} class Line extends Shape {private int start, end;
Line (int start, int end) {super (start);
This.start = start;
This.end = end;
System.out.println ("Drawing a line:" + start + "," + end);
} void Cleanup () {System.out.println ("Erasing a line:" + start + "," + end);
Super.cleanup (); }} public class Cadsystem extends Shape {private Circle C;
Private triangle t;
Private line[] lines = new LINE[10];
Cadsystem (int i) {super (i + 1);
for (int j = 0; J <; J +) Lines[j] = new Line (j, J*j);
c = new Circle (1);
t = new triangle (1);
System.out.println ("Combined constructor");
} void Cleanup () {System.out.println ("cadsystem.cleanup ()");
T.cleanup ();
C.cleanup ();
for (int i = 0; i < lines.length i++) Lines[i].cleanup ();
Super.cleanup ();
public static void Main (string[] args) {Cadsystem x = new Cadsystem (47);
try {//Code and exception handling ...} finally {x.cleanup (); }
}
} ///:~
Everything in this system belongs to some kind of shape (geometry). Shape itself is an object (object) because it is explicitly inherited from the root class. Each class redefined the cleanup () method of the shape, and also calls the base class version of that method with super. Although all of the methods invoked during the object's existence are responsible for doing some cleanup work, they all have their own builders for specific shape-class--circle (circles), triangle (triangles), and line (lines) that can complete the "drawing" (draw) task. Each class has its own cleanup () method for restoring something that is not memory back to the scene before the object existed.
In main (), you see two new keywords: try and finally. We will not be able to introduce them formally until the 9th chapter. Where the Try keyword indicates that the following block (bounded by curly braces) is a "warning area". In other words, it will receive special treatment. One treatment is that the code for the finally clause following the alert area is bound to be executed-regardless of whether the try block exists (through the illegal control technology, try block can have a variety of unusual applications). Here, the finally clause means "always call Cleanup () for X, no matter what happens". These keywords will be fully and completely explained in chapter 9th.
In your own purge method, you must pay attention to the order in which you call the underlying class and the member object purge methods-if one child object is to be based on another. In general, you should take the same form as the C + + compiler does with its "sabotage": first complete all the special work related to the class (which may require that the underlying class element is still visible), and then call the underlying class cleanup method, as demonstrated here.
In many cases, purging may not be a problem; just let the garbage collector do its job. But once it has to be clear by itself, it must be particularly cautious and require thoughtful consideration.
1. Order of garbage collection
You can't expect to know exactly when the garbage collection will start. The garbage collector may never be invoked. Even if it is invoked, it may reclaim the object in any order that it wishes. In addition, the garbage collector mechanism of the Java 1.0 implementation typically does not invoke the Finalize () method. In addition to memory recycling, it is best not to rely on garbage collectors for recycling. If you want to clear anything explicitly, make your own cleanup method, and do not rely on finalize (). However, as previously noted, you can force Java1.1 to call all closure modules (Finalizer).