The program counter, local method stack, and virtual machine stack in the JVM are all private to the thread. They are generated, dying, and dying when the thread is generated. The memory allocation and recovery of these areas are deterministic, while in the Java heap and method area The recovery of memory is uncertain. Only during the runtime can it be known how many objects will be created. Memory allocation and recovery are dynamic.
Almost all Java objects are stored in the heap. When the garbage collector reclaims the heap, it must first determine which objects in the heap are still alive and those objects are dead (objects with no purpose).
Reclaim the Java heap area
Judging the object is alive
Reference counting
Add a reference counter to the object. Whenever there is a reference to it, the counter is incremented by one; when the reference becomes invalid, the value of the counter is decremented by one. An object whose counter is zero at any time cannot be used.
**Advantages: **Simple principle and high judgment efficiency
** Disadvantages: ** Takes up additional memory.
In the Java field, no reference counter algorithm is used to manage memory in mainstream Java virtual machines.
Reason: A lot of extra processing must be used to ensure correct operation. For example, reference counting alone is difficult to solve the problem of circular references between objects.
For example: the objects objA and objB have the field instance, and the assignments make objA.instance = objB and objB.instance = objA. The two objects can no longer be accessed because their counter is not zero and the reference counting method cannot reclaim them.
Reachability analysis algorithm
Currently, Java uses reachability analysis algorithms to determine whether an object is alive. The basic idea of the algorithm uses a series of root objects called "GC Roots" as the starting node set. Starting from these nodes, search downwards according to the reference relationship. The chain traversed by the search process is called the "reference chain". If there is no reference chain between GC Roots, or the object is unreachable from GC Roots, it proves that the object cannot be used anymore.
O1, O2, O3 can not be recycled, O4, O5, O6 can be recycled.
Can be used as the object of GC Roots:
- Objects referenced in the virtual machine stack (local variable table in the stack frame), such as the parameters, local variables, and temporary variables used in the method stack that each thread is called.
- Objects referenced by static properties of the class in the method area, such as static variables of the reference type of a Java class.
- Objects referenced by constants in the method area, such as references in the string constant pool.
- The object referenced by JNI (Native method) in the native method stack.
- References inside the Java virtual machine, such as the Class object corresponding to the basic data types, some resident objects (NullPointException, OutOfMemoryError), etc., as well as the system class loader.
- All objects held by the synchronization lock (synchronized keyword).
- The JMXBean that reflects the internal situation of the Java virtual machine and the callback registered in JVMTI. Local code cache, etc.
In addition to these fixed GC Roots collections, depending on the garbage collector selected by the user and the memory area currently reclaimed, objects can also be added temporarily.
Four types of references appearing after JDK1.2: strong references, soft references, weak references, and phantom references
Reachability algorithm judgment process
When an object is determined to be unreachable, it will not be recovered immediately for the time being. To truly declare an object dead, it must undergo at least two marking processes. If the reference chain with GC Roots is not found after the reachability analysis, the first step will be performed. Mark once, and then filter. The condition of the filter is whether it is necessary for this object to execute the finalize() method. If the object does not cover the finalize() method, or the finalize() method has been called by the virtual machine , the virtual machine will In both cases, implementation is deemed unnecessary.
If this object is determined to be necessary to execute the finalize() method, this object will be added to the F-Queue queue, and the low-key and low-priority Finalizer thread will be automatically created by the virtual machine later to execute their finalize() method. But it does not necessarily wait for the end of its operation (infinite loop may occur).
If the object associates itself with an object in the reference chain in the finalize() method, it may not be recycled. For example, assign yourself (this) to a variable of a certain class or a member variable of an object. This method is not recommended
Recovery method area
There are two main reclaims: obsolete constants and types that are no longer used.
Recycling constant
No object refers to this constant, and there is no other place to refer to this constant in the virtual machine. If this is a memory reclamation and the garbage collector determines that it is necessary, the constant will be cleared out of the constant pool by the system (such as string Constant ). The symbolic references of other classes (interfaces), methods, and fields in the constant pool are similar to this.
Recycling type
- Instances of this type have been recycled, that is, there are no instances of this class and any derived subclasses of this class in the Java heap.
- The class loader that loads this class has been recycled, which is difficult to achieve unless carefully designed.
- The java.lang.Class object corresponding to this class is not referenced anywhere , and the methods of this class cannot be accessed through reflection anywhere .
The Java virtual machine is allowed to reclaim useless classes that meet the above three conditions at the same time .