Java garbage collection mechanism

From: http://www.cnblogs.com/cesc711/archive/2009/05/11/1454337.html

Java garbage collection mechanism

By cesc711, 456 visits, network Abstract, favorites, Edit

1. Who is doing garbage collection?

A popular saying is that in C ++, the system is doing garbage collection, while in Java, Java is doing it.
In C ++, the released memory is manually processed. You must use the delete operator to release the allocated memory. This is a popular saying. Specifically, when an application deems that a certain entity is not required, it must use the DELETE command to tell the system that this space can be recycled. This requirement is very troublesome and difficult for the coders. For any BBS, there are always a lot of topics about memory leakage in the C/C ++ forum.
Java uses a different and convenient method: garbage collection. The garbage collection mechanism is put in JVM. JVM is fully responsible for garbage collection. applications only apply for space when needed, and do not need to worry about space collection when discarding objects.

2. When will the object be discarded?

In C ++, when an object leaves its scope, the object is discarded by the application.
In Java, the life cycle of an object is no longer related to its scope, but only to references.
Java's garbage collection mechanism generally includes nearly 10 algorithms. We do not have to worry about the majority of these algorithms. Only the simplest one is the reference counting method, which is related to encoding.
An object that can point to one or more referenced variables. When an object no longer has any referenced variable pointing to it, the object is discarded by the application. Or, this object can be recycled by the garbage collection mechanism. That is to say, when there is no reference to an object, it means that the application tells JVM: I don't want this object, you can recycle it.
The JVM garbage collection mechanism performs real-time detection on heap space. When the reference count of an object is 0, the object is included in the list to be recycled. However, it is not immediately destroyed.

3. are discarded and recycled?

This object is considered unnecessary, so the memory occupied by it can be released. Recycled memory can be used for subsequent redistribution.
However, the object is not recycled immediately after it is discarded. JVM process has a high system overhead for space collection. If an application discards an object every time, it immediately recycles its space, which will inevitably make the entire system very inefficient. As mentioned above, the JVM garbage collection mechanism has multiple algorithms. In addition to the reference counting method, other algorithms are used to determine when and how to recycle objects. JVM's garbage collection mechanism should balance time and space.
Therefore, to improve system efficiency, the garbage collector generally runs only when two conditions are met: that is, objects are to be recycled and the system needs to be recycled. Note that garbage collection takes up time. Therefore, the Java runtime system only uses it when necessary. Therefore, you cannot know the exact time of garbage collection.

4. Is it useful to reference objects that do not point to variables?

As mentioned above, objects without variables referenced are discarded by the application, which means that the object is garbage in the heap space and may be recycled by JVM at any time. However, here is an exception. For a one-time object (called a temporary object in some books), you do not need to reference a variable to point to it. The simplest and most common example: system. Out. println ("I am Java !"); After a String object is created, it is directly passed to the println () method.

5. Can applications interfere with garbage collection?

Many people are uneasy about Java garbage collection and want to control JVM garbage collection operations in application code. This is impossible. For the garbage collection mechanism, the application only sends messages to the JVM in two ways. As mentioned above, the first one is to remove all the reference variables pointing to an object. This is equivalent to sending a message to JVM: This object is no longer needed. The second is to call the library method system. GC (), which is called in most books for Java garbage collection.
The first is a notification, and calling system. GC () is just a request. After JVM accepts the message, it does not immediately perform garbage collection, but only weighted several garbage collection algorithms to make garbage collection easy or happen early, or there are many recycles.
It is a requirement that JVM recycle garbage in a timely manner. In fact, there is another need: it is better not to recycle garbage in a certain period of time. This is often expected for real-time systems that require the fastest running speed, especially embedded systems.
Java's garbage collection mechanism serves all Java application processes, rather than a specific process. Therefore, no process can command the Garbage Collector to do anything, how to do it, or how much.

6. What to do when the object is recycled

When an object is running, something may be related to it. Therefore, when an object is about to be destroyed, some aftercare work is required. You can write these operations in the finalize () method (often called the terminator.

Protected void finalize ()
{
// Finalization code here
}

The Terminator is similar to the destructor in C ++ and is automatically called. However, the call time of the two is different, which makes the performance of the two significantly different. The C ++ destructor is always called when the object leaves the scope. This means that the call time of the C ++ destructor is fixed and can be determined by the application. However, the Java Terminator is called when the object is destroyed. Once the garbage collector is ready to release the storage space occupied by useless objects, it first calls the finalize () method of those objects, and then truly recycles the object's memory. The application cannot know when the discarded object is destroyed. In addition, in most cases, discarded objects are not destroyed after the application is terminated.
This is taken into account in encoding. For example, an object opens a file during operation and does not close it when it is discarded. Instead, it writes the file close statement in the Terminator. This will cause problems in file operations. If the file is exclusively opened, other objects cannot access the file. If the file is shared and opened, the object accessing the file cannot read the new content written to the file by the discarded object until the end of the application.
At least for file operations, the coders should recognize the differences between the Java Terminator and the C ++ destructor.
So when the application is terminated, will it execute all finalize () in the application? According to Bruce Eckel's opinion in thinking in Java: "By the end of the program, not all finishing modules will be called ". This only refers to the normal termination of the application. What if the application is terminated abnormally? Therefore, the final operations that can be placed in finalize () need to be considered.