Simple Talk about Java garbage collection _java

Long time no read about Java books, recently, saw James Gosling <<java programming language >>, and made some reading notes. This part is about garbage collection.

I. Garbage collection

object is created with new, but there is no corresponding delete operation to reclaim the memory occupied by the object. When we complete the use of an object, simply stop the reference to that object:

-> change the reference to point to another object
-> Point reference to NULL
-> is returned from the method so that the local variable of the method ceases to exist

Points:

-> when we can't get to an object from any executable code, the space it occupies can be reclaimed.
-> garbage collection means we never have to worry about the presence of a virtual overhang reference (dangling reference). A dashed reference is a reference to a memory space that has been deleted. This problem occurs in systems where programmers can directly control when objects are deleted.
-> garbage Collector Model: Reference counter Method (cannot resolve circular reference), Mark-Clear (mark-and-sweep).

Two. Summary

Finalize method

-> The garbage collector calls this method when the garbage collector determines that the object is unreachable and that the object's space is reclaimed.
-> This method can clear all the non-memory resources used by the object and can only be invoked once for each object, even if the execution of this method makes the object become unreachable again immediately after it has been executed.
The->finalize method can be invoked within any given time period, and it may never be invoked (the Java Virtual machine ends).

Overwrite Finalize method

-> when an object becomes garbage, the other objects it references are also likely to become garbage. This garbage may have been terminated before invoking the Finalize method we wrote, so they may be in an unpredictable state.
-> the Finalize method is, plus the Super.finalize method. It is better to add to the finally sentence. Ensure that some of the content declared in its superclass can also be terminated.

Three. Related classes and methods interacting with the garbage collector

Class: Runtime.getruntime (), System
Methods: GC (), Runfinalization (), Freememory (), TotalMemory (), MaxMemory ()
The system class supports static GC () and Runfinalization () methods, which call the corresponding methods on the current runtime object.

Four. Accessibility status and Reference objects

An object can be garbage collected only if it is not specified by any reference, but sometimes we might want to recycle the object as garbage when the selected reference still points to the object.

The only purpose of referencing an object is to maintain a reference to another object called a referent. Usually we maintain references to objects through fields or local variables, but now we can maintain a direct reference to a reference object that wraps the object we actually need. The garbage collector may determine whether a residual reference to an object is referenced to the object by reference object surface, so it can decide whether to recycle the object. The strength of the referenced object determines the behavior of the garbage collector, which is the most intensive reference.

Reference class

-> Bag: Java.lang.ref
-> Typical method: Get (), clear (), Enqueue (), isenqueued ()

Reference and accessibility strength

-> objects are strongly accessible (strongly reachable): normal references
The-> object is soft (softly reachable): SoftReference
The-> object is weakly accessible (weakly reachable): WeakReference
The-> object is an imaginary (phantom reachable):P Hantomreference
-> object is not available: no reference link
Once an object becomes weakly accessible (or weak), it can be terminated. If the object is unreachable after the end, it can be reclaimed.

The object accessibility phase triggers the garbage collector to make the appropriate behavior for the associated reference object type:

-> soft objects may be allowed to be recycled by the garbage collector. What we can be sure of is that all softreference to the soft object will be cleared before the OutOfMemoryError error is thrown.
-> weakly accessible objects will be reclaimed by the garbage collector.
The-> virtual reachable object is not really reachable because its reference object cannot be accessed through phantomreference, and its Get method always returns NULL. However, the existence of a virtual reference prevents the object from being reclaimed until the virtual reference is explicitly purged. Virtual references allow us to deal with objects whose finalize methods have been invoked, and thus safely assume that they are "dead".