Analysis of the significance of GC garbage collector in Java and its interaction with GC _java

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 our reference to point to another object or point to null, or return from the method so that the local variable of the method ceases to exist, making the reference to the local variable irrelevant to any object. Objects that are no longer referenced are called Garbage (garbage), and the process of finding and reclaiming them is called garbage collection (garbage collection) O

The Java Virtual machine uses garbage collection to guarantee that the referenced object will be retained in memory while releasing the storage space occupied by objects that are unreachable by any reference in the execution code. This is a strong guarantee-if an object is reached by a reference chain that starts with a reference to the root (that is, a reference that can be accessed directly in the execution code), the object is not reclaimed.

In short, when we can't get to an object from any executable code, the space it occupies can be recycled. Note that we use the word "yes" because the garbage collector determines whether or not the memory space is recycled, and the garbage collector will normally run only if more memory space is required or if there is a memory overflow to avoid. However, the program may not have a memory overflow, even when it is not close to the memory overflow, so it may not need to perform garbage collection. In all currently executing methods, if all variables do not contain references to an object, and the reference to that object is not found in all fields or array elements along the chain of references, then we say the object is "unreachable."

Garbage collection means that we never have to worry about the occurrence of a virtual overhang reference (dangling reference). In systems where programmers can directly control when to delete objects, programmers can delete objects that are still referenced by other objects, and if the programmer deletes such objects, references to the deleted objects will become dangling because they refer to the

The system is considered to be an allocated memory space (but the space has actually been released). The system can allocate this allocated space to new objects, so that the references that originally pointed to the space actually get the objects that are completely different from what they expected. In this case, when the program operates with values stored in this space and treats them as objects they do not belong to, it can cause unpredictable disasters. Garbage collection solves the problem of dangling references because all still referenced objects are not garbage collected, so the space they occupy is not likely to be released. Garbage collection also solves the problem of accidentally deleting the same object multiple times-a problem that can also cause disaster. Garbage collection does not require our intervention, but garbage collection consumes a certain amount of system resources. The creation and recycling of a large number of objects can interfere with time-critical applications, so when designing such systems, we should carefully handle the number of objects created in order to reduce the amount of garbage to be recycled.

Garbage collection does not guarantee that memory will always have space to create new objects. For example, if we keep creating objects and placing them in a list, we cannot create new objects without enough space to create new objects and no objects that are not referenced. If we keep the list of references to objects that we no longer need, we can create a memory leak. Garbage collection solves many, but not all, memory allocation problems.

interacting with the garbage collector
Although the Java language itself does not have any way of explicitly disposing of idle objects, we can still look for objects that are no longer in use by calling the garbage collector directly. The runtime class and some handy methods in the system class allow us to invoke the garbage collector, request a finalizer to run, or view the current memory state:

. public void GC Q: This method requests the Java virtual machine to expend energy to reclaim objects that are no longer in use so that the memory occupied by those objects can be reused.

. public void Runfinalization (): This method requests the Java virtual machine to expend effort 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 an estimate of the available bytes of system memory.

public Long Memory (): Returns the total number of bytes in 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 restrictions on the Java virtual machine, it returns a long. Max-value. There is no method in Java to set the maximum memory for the system, which is typically set by a command line or other configuration option.

To invoke the above method, we need a static method runtime.getruntime to get a reference to the current runtime object. The System class supports static GC and Runfinalization methods, which call the corresponding methods on the current Runt-ime object; in other words, System.GC () and Runtime.getruntime (). The GC () method is equivalent.

When the Runtime.gc () method is invoked, the garbage collector may not be able to release any additional memory because there may not be garbage to recycle, and not all garbage collector can find recyclable objects on demand. Therefore, invoking the garbage collector may not produce any effect. However, it is advisable to invoke the RUNTIME.GC () method before creating a large number of objects, especially in time-critical applications where the cost of garbage collection may be affecting them. There are two potential benefits to executing it: The 1th is that we get as much memory as possible before we run the application, and the 2nd is the possibility that we can lower the garbage collector's operation during the execution of the task. The following method actively frees up all the space that can be freed at run time:

public static Vo Ful1gc () {

Runtime rt=runtime.getruntime ();

Long Isfree=rt.freememory ();

Long Wasfree;

do{

Wasfree=isfree;

Rt.runfinalization ();

Rt.gc ();

Isfree two rt.freememory ();

}while (isfree>wasfree);

}

The method is continuously cycled, and the value of the freememory is continuously increased by successive calls to Runfinalization and GC methods. The loop of the method ends when the amount of free memory no longer increases.

We usually do not need to invoke the Runfinalization method, because the Finalize method is invoked asynchronously by the garbage collector. In some cases, such as when a resource that can be reclaimed by the Finalize method is exhausted, it is useful to enforce as many ends as possible by invoking Run-finalization. But keep in mind that we do not guarantee that any object waiting to be terminated is using this resource, so runfinalization may not have any effect.

The FULLGC approach is too radical for most applications. In special cases where garbage collection needs to be enforced, the garbage collected from a single call to the System.GC method is also the vast majority of it, even if not all of the available garbage, so repeated calls can reduce the output of garbage collection, and in many systems these repeated calls are unproductive.