This is the second day of my August challenge

First, why to carry out garbage collection?

With the previous two chapters, we looked at the various parts of the Java memory runtime area. The program counter, virtual machine stack, and local method stack are born and die with the thread, so memory allocation and reclamation in these areas are deterministic.

The other two areas (the method area and the heap) have significant uncertainty. We don’t know which objects and how many objects will be created until the program is running, and this part of the collection is dynamic. It is this area of memory that the garbage collector focuses on, and the sole purpose of garbage collection is to free up memory in this area.

Two, how to judge the object is dead

The heap holds almost every instance in the Java world, and the first thing the garbage collector does before the heap can be collected is confirm which objects are still “alive” and which are “dead.”

Here are two algorithms:

• Reference counting algorithm

This makes sense. Add a reference counter to an object, and there’s nowhere to reference it, and the counter increments by one, and when the reference expires, the calculator decays by one; An object whose counter is zero at any time cannot be used again.

There is A problem: If A refers to B, and B refers to A, and both are invalid references (the two objects have no declaration code except to refer to each other), this results in invalid references even though they refer to each other.

• Accessibility analysis algorithm:

A series of GC Roots are used as the starting node set. From these nodes, search down according to the reference relationship. The path taken in the search process is called “reference chain”. Fixed as GC Roots object:

1) Objects referenced in the virtual machine stack, parameters, local variables, temporary variables used by the current running method

2) Variables referenced by class static attributes in the method area

3) The object referenced by the constant in the method area

4) Objects referenced in the local method stack

5) Objects called inside the VIRTUAL machine

6) All objects held by the synchronization lock

7) JMXBeans that reflect the internal conditions of Java virtual machines

Three, the object self-help

Even if the object is judged to be unreachable in the reachability analysis algorithm, it does not have to die. If there is no reference chain connected to GC Roots during the reachability analysis of the object, then it will be marked for the first time and filtered again based on whether it is necessary to execute the Finalize () method.

How to redeem yourself:

1. The object overwrites the Finalize () method (so that it can be called after being condemned to death and have the chance to do the final salvation);

2. Rereference to “GC Roots” chain in finalize() method (e.g., assign the reference this of the current object to a class variable/member variable of an object, and re-establish reachable reference)