Java garbage collection mechanism (previous version)

Java garbage collection mechanism in our general understanding, should be considered as a low-priority background process to achieve, in fact, the earlier version of the Java Virtual machine is not implemented in this way.

Let's start with a very simple garbage collection method.

Reference count

Reference counting is a simple, but slow, garbage collection technique.

Each object contains a reference counter to be given, and when a reference is connected to the object, the reference count is +1.

When the reference leaves the scope or is set to NULL, the reference count-1.

When a reference count of one object is found to be 0 o'clock, it frees up the space it occupies.

　　

This method of overhead persists throughout the program life cycle, and the method has a flaw in the case that if there is a circular reference between objects, the "object should be retracted, but the reference count is not zero".

That

B.seta (a); A.setb (b);

For the garbage collector, locating such an exchange of self-referencing groups of objects requires a great deal of work. Reference counting is often used to illustrate how garbage collection works, but it does not seem to be applied to any Java virtual machine implementation.

How to Solve

Many garbage collector is not based on reference count counts. The ideas they rely on are:

For any "live" object, it must eventually be traced back to the reference in its surviving stack or static storage area. This reference chain may pass through several object hierarchies. As a result, all the "live" objects can be found by traversing all references, starting from the stack and the static store. For each reference that is discovered, you must trace the object it references, and then all the references that this object contains, and so on, to know that the network that originated from the stack and static store references is all accessed. The object you have visited must be "live".

Note that this solves the problem of "interacting with self-referencing groups of objects"-a phenomenon that is not discovered at all and is therefore automatically recycled.

Stop-Copy

Obviously, it means that this method should pause the program first (so he is not in the background recycle mode), then copy all the surviving objects from the current stack to the other heap (all references to it will be re-corrected), and all that is not copied is garbage.

When objects are copied to the new heap, they are one next to each other, so the new heap remains compact and the new space can be allocated directly according to the aforementioned method.

The problem: inefficiency is too low.

(1) in the Daoteng between two heaps, it is necessary to maintain more than one space;

(2) After the program enters a stable state, it may produce only a small amount of garbage, the copy-type collector will still copy all the memory from one place to another, which is wasteful.

In order to solve the second problem, "Mark-sweep" was produced.

Mark-Sweep

From stack and static storage, traverse all references to find all the live objects, and mark that the entire process will not reclaim any objects.

The cleanup action will only begin when all marks are completed. During the cleanup process, objects that are not marked are freed and no copy actions occur.

However, this method must also be performed in the event of a program pause.

A combination of two methods to form an early Java recovery mechanism-"adaptive" technology

As the name implies, the Java virtual opportunity to monitor, if the object is stable, the efficiency of the garbage collector is reduced, switch the "mark-clean" mode;

Similarly, the Java Virtual Opportunity tracks the effect of mark-and-clean, and if there is a lot of fragmentation in the heap space, it switches back to stop-copy mode.

　　

Java garbage collection mechanism (previous version)