Java garbage collection mechanism and reference type

An important feature of the Java language is the introduction of an automatic memory management mechanism, so that developers do not have to manage the memory in the application on their own. C/C ++ developers need to use functions such as malloc/free and new/Delete to explicitly allocate and release memory. This puts forward high requirements for developers, which may cause problems such as memory access errors and Memory leakage. A common problem is that "dangling references" occurs, that is, the memory block pointed to by an object reference has been mistakenly recycled and re-allocated to the new object, if the program continues to use this reference, it will cause unexpected results. Developers may forget to explicitly call the function to release the memory, resulting in Memory leakage. Automatic memory management refers to handing over memory management tasks to the running environment of the programming language. Developers do not need to care about the underlying details of memory allocation and recovery. Java platform uses the Garbage Collector for automatic memory management.

Java garbage collection mechanism

Java garbage collector is responsible for completing three tasks: allocating memory, ensuring that the memory of referenced objects is not recycled incorrectly, and reclaim the memory space of objects that are no longer referenced. Garbage collection is a complex and time-consuming operation. If the JVM spends too much time on garbage collection, the running performance of the application will inevitably be affected. Generally, when the Garbage Collector recycles an application, the execution of the entire application is temporarily suspended (STOP-the-world. This is because the Garbage Collector needs to update the actual memory address referenced by all objects in the application. Different hardware platforms support different garbage collection methods. For example, on a multi-CPU platform, garbage collection can be performed in parallel. A single CPU platform can only be used in serial mode. Different applications may expect different garbage collection methods. The server-side application may wish to spend less time on garbage collection during the entire running time of the application, the better. For applications that interact with users, it is possible that the interval between application pauses caused by garbage collection is smaller, the better. In this case, JVM provides a variety of garbage collection methods and corresponding performance tuning parameters. Applications can be customized as needed.

The most basic method of Java garbage collection mechanism is generational collection. The regions in the memory are divided into different generations, and objects are stored in the region of the corresponding generation according to their survival time. Generally, it is divided into three generations: young, old, and permanent. Memory Allocation occurs in the young generation. When an object remains long enough, it will be copied to the older generation. Different garbage collection algorithms can be used for different generations. The starting point of generation Division is the statistical rule obtained after studying the object survival time in the application. In general, the survival time of most objects in an application is very short. For example, the survival time of local variables is only in the method execution process. Based on this, the garbage collection Algorithm for the young generation can be very targeted.

The memory areas of the young generation are further divided into Eden and two surviving vor spaces ). Eden is the place for memory allocation and a continuous idle memory area. The above memory allocation speed is very fast, because you do not need to find available memory blocks. One of the two survival zones is always blank. During garbage collection, the surviving objects in the Garden of Eden and one of the non-empty survival zones are copied to the current blank survival zone or older generation based on their survival time. After this replication, the previous non-empty survival zone contains objects that are currently still alive, and the content in the Garden of Eden and another survival zone is no longer needed, simply clear the two regions. During the next garbage collection, the roles in the two survival zones are exchanged. Generally, the young generation has a small area and most objects are no longer alive. Therefore, it is more efficient to search for surviving objects.

For memory regions of older and permanent generations, different recycling algorithms are used, called Mark-sweep-compact )". The marking process is to find and mark the currently alive objects. If it is cleared, it traverses the entire memory area and finds the area where the objects need to be recycled; compression moves the memory of the surviving object to one end of the entire memory area, making the other end a continuous idle area for convenient memory allocation and replication.

JDK 5 provides four different garbage collection mechanisms. The most common method is serial collection, that is, using a single CPU to reclaim memory for young and old generations. During the recycle process, the application is temporarily suspended. The recycling method is the most basic generational recycling mentioned above. The serial recycling method is suitable for a Single-CPU desktop platform. If it is a multi-CPU platform, it is suitable for parallel recovery. In this way, multiple CPUs are used for parallel processing when the young generation is recycled, which can improve the recovery performance. The concurrent tag-clear collection method is suitable for scenarios with high response time requirements for applications, that is, the temporary suspension time of applications caused by garbage collection needs to be reduced. The advantage of this method is that it can mark the alive object and recycle garbage while the application is running, but it only needs to suspend the application for a short time.

Using the jconsole provided in JDK, you can easily view the memory usage of the current application. When JVM is started, add the parameter-verbose: GC to view the running result of the garbage collector.

Java reference type

If an object in the memory has no reference, it indicates that the object is no longer in use and can become a candidate for garbage collection. However, because the running time of the garbage collector is unknown, the actual time for recycling objects that can be recycled is unknown. For an object, as long as there is a reference, it will always exist in the memory. If more and more such objects exceed the total JVM memory, the JVM will throw an outofmemory error. Although the specific running of garbage collection is controlled by JVM, developers can still interact with the garbage collector to a certain extent, the purpose is to better help the Garbage Collector manage the application memory. This interaction method is to use the java. Lang. Ref package introduced by JDK 1.2.

Strong reference

In general Java programs, strong reference is the most commonly seen ). For example, if date = new date (), date is a strongly referenced object. Strong references of objects can be passed everywhere in programs. In many cases, multiple references point to the same object. The existence of strong references limits the lifetime of objects in the memory. If object A contains a strong reference of object B, the survival time of object B is generally not shorter than that of object. If object A does not explicitly set the reference of object B to null, object B no longer directs to object a only after object A is reclaimed by garbage collection, to obtain the opportunity for garbage collection.

In addition to strong references, the Java. Lang. Ref package provides different references to an object. The JVM Garbage Collector has different processing methods for different types of references.

Soft reference

Soft reference is less powerful than soft reference, expressed by softreference. Its function is to tell the Garbage Collector which objects in the program are less important and can be recycled temporarily when the memory is insufficient. When the memory in the JVM is insufficient, the garbage collector will release the objects pointed to by soft references. If all these objects are released and the memory is insufficient, an outofmemory error is thrown. Soft references are ideal for creating caches. When the system memory is insufficient, the content in the cache can be released. For example, consider an image editor program. This program will read all the content of the image file into the memory for convenient processing. You can also open multiple files at the same time. When too many files are opened at the same time, the memory may be insufficient. If soft references are used to point to the image file content, the garbage collector can reclaim the memory when necessary.

Public class imagedata {private string path; private softreference <byte []> dataref; Public imagedata (string path) {This. path = path; dataref = new softreference <byte []> (New byte [0]);} private byte [] ReadImage () {return New byte [1024*1024]; // The object reading operation is omitted.} public byte [] getdata () {byte [] dataarray = dataref. get (); If (dataarray = NULL | dataarray. length = 0) {dataarray = ReadImage (); dataref = new softreference <byte []> (dataarray) ;}return dataarray ;}}

When running the above program, you can use the-xmx parameter to limit the available JVM memory. Since objects pointed to by soft references may be recycled, when you use the get method to obtain objects actually pointed to by soft references, you always need to check whether the object is still alive.

Weak reference

Weak reference is weaker than soft reference in strength and is represented by weakreference. It references an object but does not prevent the object from being recycled. If a strongly referenced object exists, the referenced object cannot be recycled. Weak references do not cause this problem. When the garbage collector is running, if all references of an object are weak references, the object will be recycled. Weak references are used to solve the coupling relationship between objects brought about by strong references on the survival time. Weak references are most commonly used in collection classes, especially in hash tables. The hash table interface allows you to use any Java object as the key. When a key-value pair is put into a hash table, the hash table object itself has reference to these key-value objects. If this type of reference is strongly referenced, as long as the hash table object itself is still alive, the key and value objects contained in it will not be recycled. If a long-lived hash table contains many key-value pairs, it may eventually consume all the memory in the JVM.

In this case, the weak reference is used to reference these objects, so that the key and value objects in the hash table can be recycled. Java provides weakhashmap to meet this common requirement.

Ghost reference

Before introducing ghost references, we should first introduce the object termination mechanism (finalization) provided by Java ). There is a Finalize method in the object class. Its original design is that it can be used to perform some cleanup before an object is actually recycled. Because Java does not provide a mechanism similar to the C ++ destructor, it is implemented through the Finalize method. However, the problem is that the running time of the garbage collector is not fixed, so the actual running time of these cleanup tasks is unpredictable. Phantom reference can solve this problem. You must specify a reference queue when creating a ghost reference phantomreference. When an object's Finalize method has been called, the object's ghost reference will be added to the queue. Check the content in the queue to see if an object is ready to be recycled.

The usage of ghost references and their queues is rare. It is mainly used to implement fine-grained memory usage control, which makes sense for mobile devices. The program can apply for memory to create a new object after determining that an object is to be recycled. In this way, the memory consumed by the program can be maintained in a relatively low amount. For example, the following code provides a buffer implementation example.

Public class phantombuffer {private byte [] DATA = new byte [0]; private referencequeue <byte []> queue = new referencequeue <byte []> (); private phantomreference <byte []> ref = new phantomreference <byte []> (data, queue); Public byte [] Get (INT size) {If (size <= 0) {Throw new illegalargumentexception ("wrong buffer size");} If (data. length <size) {DATA = NULL; system. GC (); // force run the Garbage Collector try {queue. remove (); // This method will be blocked until the queue is not empty ref. clear (); // The Ghost reference will not be automatically cleared. Manually run ref = NULL; Data = new byte [size]; ref = new phantomreference <byte []> (data, queue);} catch (interruptedexception e) {e. printstacktrace () ;}} return data ;}}

In the above Code, each time you apply for a new buffer, you must first ensure that the byte array of the previous buffer has been successfully recycled. The Remove Method of the reference queue is blocked until a new ghost reference is added to the queue. However, this method causes the Garbage Collector to run too many times and may cause low program throughput.

Reference queue

In some cases, the program will be notified when the accessibility of an object changes. For example, a strong reference of an object does not exist, and only soft reference or weak reference is left. However, you still need to process the reference itself. A typical scenario is in a hash table. The referenced object is a key object in weakhashmap. After the actual object referenced by it is reclaimed by garbage collection, you need to delete the key-value pair from the hash table. With the referencequeue, you can easily obtain these weak reference objects and delete them from the table. Before a soft reference or weak reference object is added to a queue, its reference to the actual object is automatically cleared. By referencing the poll/remove methods of the queue, you can obtain the referenced objects in the queue in non-blocking and blocking ways.

 

Transferred from: http://www.infoq.com/cn/articles/cf-java-garbage-references authorCheng Fu