A brief analysis of the significance of the GC garbage collector in Java and its interaction with the GC

The object is created using new, but there is no corresponding delete operation to recycle the memory occupied by the object. When we are done using an object, we simply stop referring to it: change our reference to point to another object or to null; or return from the method so that the method's local variables no longer exist, thus Make the references to these local variables point to no objects. Objects that are no longer referenced are called garbage, and the process of finding and recycling these objects is called garbage collection. o

The Java virtual machine uses garbage collection to ensure that referenced objects will be Retained in memory, the storage space occupied by objects that are not reachable through any reference in the executing code will be released. This is a strong guarantee - if an object can be reached by following the reference chain starting from the root reference (that is, the reference that is directly accessible in the executing code), then the object will not be recycled.

In short, when we cannot reach an object from any executable code, the space it occupies can be reclaimed. Note that we use the word "can" because whether the memory space is recycled is determined by the garbage collector. Normally, the garbage collector will only recycle the memory space when more memory space is needed or to avoid memory overflow. run. However, the program may exit without a memory overflow, or even when it is not close to a memory overflow, so there may be no need to perform garbage collection at all. If in all methods currently executed, no variables contain references to an object, and starting from these variables, no reference to this object is found in any field or array element along the reference chain, then we Just say that this object is "unreachable".

Garbage collection means we never have to worry about dangling references. In systems where the programmer has direct control over when objects are deleted, the programmer can delete an object that is still referenced by other objects. If the programmer deletes such an object, then the references that are still referring to the deleted object will be deleted. become dangling because they refer to memory space that the operating system considers to be allocatable (but which has actually been freed). The system can allocate this allocable space to new objects, so that those references that originally pointed to the space actually get completely different objects than they expected. In this case, unpredictable disasters may occur when the program uses values ​​stored in this space and operates on them as objects they do not belong to. Garbage collection solves the dangling reference problem for us, because all objects that are still referenced will not be treated as garbage collection, so the space they occupy cannot be released. Garbage collection also solves the problem of accidentally deleting the same object multiple times—a problem that can lead to disaster. The recycling of garbage objects does not require our intervention, but recycling garbage will occupy certain system resources. The creation and recycling of large numbers of objects can be disruptive to time-critical applications, so when designing such systems, we need to carefully handle the number of objects created in order to reduce the amount of garbage to be recycled.

Garbage collection does not guarantee that there will always be space in memory to create new objects. For example, if we keep creating objects and put them in a list, then when there is not enough space to create new objects, and there are no unreferenced objects, no new objects can be created. . If we let the above list hold references to objects that are no longer needed, we would create a memory leak. Garbage collection solves many (but not all) memory allocation problems.

Although the Java language itself does not have any explicit method of disposing of idle objects, we can still find objects that are no longer used by directly calling the garbage collector. Some convenient methods in the Runtime class and the system class allow us to call the garbage collector, request to run all finalizers to be run, or view the current memory status:

　.public void gc Q: This method requests Java The virtual machine spends energy reclaiming objects that are no longer used so that the memory occupied by these objects can be reused.

　.public void runFinalization(): This method requests the Java virtual machine to spend energy to run the following finalizers: objects that have been found to be unreachable, but whose finalizers have not yet been executed.

　“public long freememory(): Returns the estimated number of bytes of system memory available.

　·public long total Memory (): Returns the total number of bytes of system memory.

　.public long maxmemoryo: Returns the maximum number of bytes of system memory available to the Java virtual machine. If the operating system has no memory usage limit for the Java virtual machine, Long . MAX-VALUE will be returned. There is no use in Java. How to set the maximum memory of the system. Usually, the Java virtual machine sets this value through the command line or other configuration options

To call the above method, we need to obtain a reference to the current Runtime object through the static method Runtime.getRuntime. The system class supports static gc and runFinalization methods, which will call the corresponding methods on the current Runt-ime object; in other words, the System.gc() and Runtime.getRuntime().gc() methods are equivalent.

When calling the Runtime.gc() method, the garbage collector may not be able to release any additional memory, because there may be no garbage to collect, and not all garbage collectors can find available memory on demand. Recycle objects. So calling the garbage collector may have no effect. However, it is still advisable to call the Runtime.gc() method before creating a large number of objects, especially in time-critical applications where the overhead of garbage collection may affect it. There are two potential benefits to doing this: the first is that we can get as much memory as possible before running the application, and the second is that we can reduce the likelihood of the garbage collector running during the execution of the task. The following method actively releases all the space that can be released at runtime:

public static vo记ful1GC(){
 
Runtime rt=Runtime.getRuntime();
 
long isFree=rt.freeMemory ();
 
long wasFree;
 
do{
 
wasFree=isFree;
 
rt.runFinalization ();
 
rt.gc();
 
isFree二rt.freeMemory();
 
}while (isFree>wasFree);
 
}

This method is continuously looping. By continuously calling the runFinalization and gc methods, the value of freememory continues to increase. When the amount of free memory no longer increases, the loop of this method ends.

We usually do not need to call the runFinalization method because the finalize method is called asynchronously by the garbage collector. In some cases, such as when an item's resources that can be reclaimed by the finalize method are exhausted, it is useful to force as much finalization as possible by calling run-Finalization. But remember, there is no guarantee that any object waiting to be finalized is using this resource, so runFinalization may not have any effect.

The fullGc approach is too aggressive for most applications. In the special case where garbage collection needs to be forced, a single call to the system.gc method collects most, if not all, of the available garbage, so repeated calls will reduce the output of garbage collection. rate, and in many systems these repeated calls are unproductive.

For more articles on the meaning of the GC garbage collector in Java and its interaction with the GC, please pay attention to the PHP Chinese website!