Objects created in Java heap memory are a resource hogger. Memory resources are limited, and when local variables of no method reference the instance object, they are treated as garbage, requiring the JVM’s garbage collection machine to clean up the non-referenced objects

All you need to do is start a JVM process, and it will have a garbage collection background thread that will constantly check for instance objects in the JVM heap memory in the background

If an instance object does not have any local variables of any method pointing to it, nor does any static variables of any class, including constants, point to it.

The garbage collection threads, then the “Demo” instance of a nobody to recycling, remove from the memory, let him no longer take up any memory resources, in this way, these are no longer people point to the object instance, namely the “junk” in the JVM, will be the background gc thread on a regular basis, constantly release memory resources

How to determine if an object is dead and no longer referenced

Reference counting method

Reference counting describes an algorithm that increments an object with a reference counter that increases by 1 each time it is referenced. When a reference is invalid, the counter is -1; An object whose counter is zero at any point in time is no longer usable is “dead”. Reference counting method is simple to implement and has high judgment efficiency. It is a better algorithm in most cases. The Python language, for example, uses reference counting for memory management. However, reference counting is not used to manage memory in mainstream JVMS, mainly because reference counting does not solve the problem of circular references to objects.

Accessibility analysis algorithm

Java does not use reference counting to determine whether an object is “dead”, but “reacability analysis” to determine whether an object is alive (as does C#, Lisp- one of the first languages to use dynamic memory allocation). The core idea of this algorithm is as follows: Through a series of objects called “GC Roots” as the starting point, search down from these nodes, the path is called “reference chain”, when an object is not connected to GC Roots any reference chain (from GC Roots to this object is not reachable), the object is proved to be unavailable. Here are some examples:

Object5 — Object7 are still related to each other, but they are not reachable to GC Roots, so they are judged to be recyclable.

In the Java language, objects that can be used as GC Roots include the following:

  • The object referenced in the virtual machine stack (the local variable table in the stack frame)
  • Objects referenced by static properties in the method area
  • The object referenced by the constant in the method area
  • Objects referenced in the Native method stack

Static variables can also be considered GC Roots in the JVM specification

As long as your objects are referenced by local variables of a method or static variables of a class, they are not recycled

Will there be garbage collection in the method area

Classes in a method area are reclaimed in several cases

  • First, all instance objects of the class have been reclaimed from Java heap memory
  • Second, the ClassLoader that loaded this class has been reclaimed
  • Finally, there is no reference to the Class object of that Class

Different types of references to objects in Java

The relationships between references and garbage collection are strong references, soft references, weak references, and virtual references

Strong reference

 private static Demo1 demo1 = new Demo1();
Copy the code

This is common code, a variable refers to an object, as long as it is a strongly referenced type, then garbage collection will never collect the object

Soft references

 private static SoftReference<Demo1> softReference = new SoftReference<>(new Demo1());
Copy the code

Wrap a Demo1 instance with a SoftReference SoftReference. The SoftReference reference to Demo1 is a SoftReference

Garbage collection is not normally recycled soft reference object, but if you make after recycling, found that is not enough memory space to store the new object, memory is overflow, at this time will drop these soft reference object to the collection, even if he was hit by a variable reference, but because he is a soft reference, so still need to recycle

A weak reference

public static WeakReference<Demo1> demo1WeakReference = new WeakReference<Demo1>(new Demo1());
Copy the code

Weak references are similar to no references, and if garbage collection occurs, the object will be reclaimed

Strong reference, soft reference and weak reference:

  • The most commonly used are strong references and soft references. Strong references are objects that must not be reclaimed, and soft references are objects that can be dispensable if memory is not available

Enough, soft references can be reclaimed, weak references will be reclaimed whenever garbage collection occurs

The role of finalize() method

Before garbage collection, the finalize() method of the objects below will be called first, so objects that do not have GC Roots reference may not be collected immediately. You can use the following code to save yourself

public class HelloWorld {

    public static  HelloWorld instance;

    @Override
    protected void finalize(a) throws Throwable {
        HelloWorld.instance=this; }}Copy the code

Suppose a HelloWorld Object is being garbage collected. Suppose that Object overrides the finialize() method in the Object class

We will first try to call our Finalize () method to see if we give our instance object to a GC Roots variable, such as the static variable of HelloWorld class

If you re reference yourself to a GC Roots variable, you don’t need to be garbage collected

When is garbage collection triggered

Garbage recovery judgment conditions:

  • Objects with GC Roots references cannot be reclaimed, and objects without GC Roots references can be reclaimed
  • If there are GC Roots references, but if they are soft or weak references, they may also be recycled.