12.doc.html

java语言规范

<a name="44725"></a>
Next, the initializers for the instance variables of class <code>ColoredPoint</code> are executed. This step assigns the value <code>0xFF00FF</code> to <code>color</code>. Finally, the rest of the body of the <code>ColoredPoint</code> constructor is executed (the part after the invocation of <code>super</code>); there happen to be no statements in the rest of the body, so no further action is required and initialization is complete.<p>
<a name="44726"></a>
Unlike C++, the Java language does not specify altered rules for method dispatch during the creation of a new class instance. If methods are invoked that are overridden in subclasses in the object being initialized, then these overriding methods are used, even before the new object is completely initialized. Thus, compiling and running the example:<p>
<pre><a name="44727"></a>
class Super {
<a name="44728"></a>	Super() { printThree(); }
<a name="44729"></a>	void printThree() { System.out.println("three"); }
<a name="44730"></a>}
</pre><pre><a name="48312"></a>
class Test extends Super {
<a name="44732"></a>	int indiana = (int)Math.PI;													// That is, 3
<a name="44733"></a>
	public static void main(String[] args) {
<a name="44734"></a>		Test t = new Test();
<a name="44735"></a>		t.printThree();
<a name="44736"></a>	}
<a name="44737"></a>	void printThree() { System.out.println(indiana); }
<a name="44738"></a>}
</pre><a name="44739"></a>
produces the output:
<p><pre><a name="44740"></a>
<code>0
</code><a name="44741"></a>3
</pre><a name="44742"></a>
This shows that the invocation of <code>printThree</code> in the constructor for class <code>Super</code> 
does not invoke the definition of <code>printThree</code> in class <code>Super</code>, but rather invokes 
the overriding definition of <code>printThree</code> in class <code>Test</code>. This method therefore 
runs before the field initializers of <code>Test</code> have been executed, which is why the first 
value output is <code>0</code>, the default value to which the field <code>three</code> of <code>Test</code> is initialized. 
The later invocation of <code>printThree</code> in method <code>main</code> invokes the same definition 
of <code>printThree</code>, but by that point the initializer for instance variable <code>three</code> has 
been executed, and so the value <code>3</code> is printed.
<p><a name="44746"></a>
See <a href="8.doc.html#41652">&#167;8.6</a> for more details on constructor declarations.<p>
<a name="44748"></a>
<h2>12.6    Finalization of Class Instances</h2>
<a name="44752"></a>
The class <code>Object</code> has a <code>protected</code> method called <code>finalize</code> &#32;<a href="javalang.doc1.html#23198">(&#167;20.1.11)</a>; this 
method can be overridden by other classes. The particular definition of <code>finalize</code> 
that can be invoked for an object is called the <i>finalizer</i> of that object. Before the 
storage for an object is reclaimed by the garbage collector, the Java Virtual 
Machine will invoke the finalizer<i> </i>of that object.
<p><a name="44753"></a>
Finalizers provide a chance to free up resources (such as file descriptors or operating system graphics contexts) that cannot be freed automatically by an automatic storage manager. In such situations, simply reclaiming the memory used by an object would not guarantee that the resources it held would be reclaimed.<p>
<a name="44754"></a>
The Java language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused. Also, the Java language does not specify which thread will invoke the finalizer for any given object. If an uncaught exception is thrown during the finalization, the exception is ignored and finalization of that object terminates.<p>
<a name="44755"></a>
The <code>finalize</code> method declared in class <code>Object</code> takes no action. However, the fact that class <code>Object</code> declares a <code>finalize</code> method means that the <code>finalize</code> method for any class can always invoke the <code>finalize</code> method for its superclass, which is usually good practice. (Unlike constructors, finalizers do not automatically invoke the finalizer for the superclass; such an invocation must be coded explicitly.)<p>
<a name="44756"></a>
For efficiency, an implementation may keep track of classes that do not override the <code>finalize</code> method of class <code>Object</code>, or override it in a trivial way, such as:<p>
<pre><a name="44757"></a>protected void finalize() throws Throwable {<br>
	super.finalize();<br>
}
</pre><a name="44758"></a>
We encourage implementations to treat such objects as having a finalizer that is 
not overridden, and to finalize them more efficiently, as described in <a href="12.doc.html#44760">&#167;12.6.1</a>.
<p><a name="44759"></a>
A finalizer may be invoked explicitly, just like any other method.<p>
<a name="44760"></a>
<h3>12.6.1    Implementing Finalization</h3>
<a name="44761"></a>
Every object can be characterized by two attributes: it may be <i>reachable</i>, <i>finalizer-
reachable</i>, or <i>unreachable</i>, and it may also be <i>unfinalized</i>, <i>finalizable</i>, or <i>finalized</i>.
<p><a name="44762"></a>
A <i>reachable</i> object is any object that can be accessed in any potential continuing computation from any live thread. Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a compiler or code generator may choose, explicitly or implicitly, to set a variable or parameter that will no longer be used to <code>null</code> to cause the storage for such an object to be potentially reclaimable sooner. A <i>finalizer-reachable</i> object can be reached from some finalizable object through some chain of references, but not from any live thread. An <i>unreachable</i> object cannot be reached by either means.<p>
<a name="44763"></a>
An <i>unfinalized</i> object has never had its finalizer automatically invoked; a <i>finalized</i> object has had its finalizer automatically invoked. A <i>finalizable</i> object has never had its finalizer automatically invoked, but the Java Virtual Machine may eventually automatically invoke its finalizer.<p>
<a name="48746"></a>
The life cycle of an object obeys the following transition diagram, where we abbreviate "finalizer-reachable" as "f-reachable":<img src="12.doc.anc.gif"><p>
<a name="48817"></a>
<p>
<a name="48818"></a>
When an object is first created (A), it is reachable and unfinalized.<p>
<a name="48565"></a>
As references to an object are discarded during program execution, an object that was reachable may become finalizer-reachable (B, C, D) or unreachable (E, F). (Note that a finalizer-reachable object never becomes unreachable directly; it becomes reachable when the finalizer from which it can be reached is invoked, as explained below.)<p>
<a name="44823"></a>
If the Java Virtual Machine detects that an unfinalized object has become finalizer-reachable or unreachable, it may label the object finalizable (G, H); moreover, if the object was unreachable, it becomes finalizer-reachable (H).<p>
<a name="44824"></a>
If the Java Virtual Machine detects that a finalized object has become unreachable, it may reclaim the storage occupied by the object because the object will never again become reachable (I).<p>
<a name="44825"></a>
At any time, a Java Virtual Machine may take any finalizable object, label it finalized, and then invoke its <code>finalize</code> method in some thread. This causes the object to become finalized and reachable (J, K), and it also may cause other objects that were finalizer-reachable to become reachable again (L, M, N).<p>
<a name="44826"></a>
A finalizable object cannot also be unreachable; it can be reached because its finalizer may eventually be invoked, whereupon the thread running the finalizer will have access to the object, as <code>this</code> <a href="15.doc.html#31980">(&#167;15.7.2)</a>. Thus, there are actually only eight possible states for an object.<p>
<a name="44830"></a>
After an object has been finalized, no further action is taken until the automatic storage management determines that it is unreachable. Because of the way that an object progresses from the <i>unfinalized</i> state through the <i>finalizable</i> state to the <i>finalized</i> state, the <code>finalize</code> method is never automatically invoked more than once by a Java Virtual Machine for each object, even if the object is again made reachable after it has been finalized.<p>
<a name="44831"></a>
Explicit invocation of a finalizer ignores the current state of the object and does not change the state of the object from unfinalized or finalizable to finalized.<p>
<a name="44832"></a>
If a class does not override method <code>finalize</code> of class <code>Object</code> (or overrides it in only a trivial way, as described above), then if instances of such as class become unreachable, they may be discarded immediately rather than made to await a second determination that they have become unreachable. This strategy is indicated by the dashed arrow (O) in the transition diagram.<p>
<a name="44833"></a>
Java programmers should also be aware that a finalizer can be automatically invoked, even though it is reachable, during finalization-on-exit <a href="12.doc.html#44857">(&#167;12.9)</a>; moreover, a finalizer can also be invoked explicitly as an ordinary method. Therefore, we recommend that the design of <code>finalize</code> methods be kept simple and that they be programmed defensively, so that they will work in all cases.<p>
<a name="44837"></a>
<h3>12.6.2    Finalizer Invocations are Not Ordered</h3>
<a name="44838"></a>
Java imposes no ordering on finalize method calls. Finalizers may be called in any 
order, or even concurrently.
<p><a name="44839"></a>
As an example, if a circularly linked group of unfinalized objects becomes unreachable (or finalizer-reachable), then all the objects may become finalizable together. Eventually, the finalizers for these objects may be invoked, in any order, or even concurrently using multiple threads. If the automatic storage manager later finds that the objects are unreachable, then their storage can be reclaimed.<p>
<a name="48740"></a>
It is straightforward to implement a Java class that will cause a set of finalizer-like methods to be invoked in a specified order for a set of objects when all the objects become unreachable. Defining such a class is left as an exercise for the reader.<p>
<a name="48744"></a>
<h2>12.7    Finalization of Classes</h2>
<a name="44843"></a>
If a class declares a class method <code>classFinalize</code> that takes no arguments and 
returns no result:
<p><pre><a name="44844"></a>static void classFinalize() throws Throwable { . . . }
</pre><a name="44848"></a>
then this method will be invoked before the class is unloaded <a href="12.doc.html#44850">(&#167;12.8)</a>. Like the 
<code>finalize</code> method for objects, this method will be automatically invoked only 
once. This method may optionally be declared <code>private</code>, <code>protected</code>, or <code>public</code>.
<p><a name="44850"></a>
<h2>12.8    Unloading of Classes and Interfaces</h2>
<a name="44851"></a>
A Java Virtual Machine may provide mechanisms whereby classes are <i>unloaded</i>. 
The details of such mechanisms are not specified in this version of the Java Language
Specification. In general, groups of related class and interface types will be 
unloaded together. This can be used, for example, to unload a group of related 
types that have been loaded using a particular class loader. Such a group might 
consist of all the classes implementing a single applet in a Java-based browser 
such as HotJava, for example.
<p><a name="48002"></a>
A class may not be unloaded while any instance of it is still reachable <a href="12.doc.html#44748">(&#167;12.6)</a>. A class or interface may not be unloaded while the <code>Class</code> object that represents it is still reachable.<p>
<a name="44855"></a>
Classes that declare class finalizers <a href="12.doc.html#48744">(&#167;12.7)</a> will have these finalizers run before they are unloaded.<p>
<a name="44857"></a>
<h2>12.9    Virtual Machine Exit</h2>
<a name="44858"></a>
A Java Virtual Machine terminates all its activity and <i>exits</i> when one of two things 
happens:
<p><ul><a name="44862"></a>
<li>All the threads that are not daemon threads <a href="javalang.doc18.html#2860">(&#167;20.20.24)</a> terminate.
<a name="44866"></a>
<li>Some thread invokes the <code>exit</code> method <a href="javalang.doc15.html#34351">(&#167;20.16.2)</a> of class <code>Runtime</code> or class <code>System</code> and the exit operation is not forbidden by the security manager <a href="javalang.doc16.html#14111">(&#167;20.17.13)</a>.
</ul><a name="57365"></a>
A Java program can specify that the finalizers of all objects that have finalizers, 
and all classes that have class finalizers, that have not yet been automatically 
invoked are to be run before the virtual machine exits. This is done by invoking 
the method <code>runFinalizersOnExit</code> of class <code>System</code> with the argument <code>true</code>. The 
default is to not run finalizers on exit, and this behavior may be restored by invoking
<code>runFinalizersOnExit</code> with the argument <code>false</code>. An invocation of the <code>runFinalizersOnExit
</code> method is permitted only if the caller is allowed to <code>exit</code>, and 
is otherwise rejected by the <code>SecurityManager</code> <a href="javalang.doc16.html#46274">(&#167;20.17)</a>.
<p>

<hr>
<!-- This inserts footnotes--><p>
<a href="index.html">Contents</a> | <a href="11.doc.html">Prev</a> | <a href="13.doc.html">Next</a> | <a href="j.index.doc1.html">Index</a>
<p>
<font size=-1>Java Language Specification (HTML generated by Suzette Pelouch on February 24, 1998)<br>
<i><a href="jcopyright.doc.html">Copyright &#169 1996 Sun Microsystems, Inc.</a>
All rights reserved</i>
<br>
Please send any comments or corrections to <a href="mailto:[e-mail]">[e-mail]</a>
</font>
</body></html>