The 5th Chapter (2) Java garbage collector

End Processing

Java has a garbage collector that reclaims memory resources that are occupied by useless objects. But the garbage collector only knows to release the memory allocated through new, and if we get a "special" area of memory in another way, we need to do the cleanup ourselves. Java provides a finalize () method to solve this problem.

Finalize () Method :

How it works: Once the garbage collector is ready to release the storage space occupied by the object, its finalize () method is called first , and the memory occupied by the object is actually reclaimed when the next garbage collection action occurs.

The effect, in other words, is that if you have to perform certain actions before you no longer need an object, you have to do it yourself.

For example, suppose an object will draw itself to the screen during creation, and if it is not explicitly erased, it may never be cleaned up, and we need to include the erase function in the finalize () method.

Garbage collection

Let's talk about how the garbage collector works.

Common garbage collection mechanisms:

(1). Reference count (simple but slow)

Each object contains a reference register.

When a reference is linked to an object, the reference count is added to 1.

When the reference leaves the scope or is set to null , the reference count is reduced by 1.

Although the overhead of managing reference counts is small, this overhead will continue to occur throughout the program life cycle. The garbage collector iterates over the list of all objects, releasing the space it occupies when it finds that the reference count of an object is 0 ( However, the reference notation pattern is often changed to 0 immediately after the object is released ).

There is a flaw in this approach, and if there is a circular reference between objects, the "object should be recycled, but the reference count is not zero" scenario may occur. For the garbage collector, locating such an interactive self-referencing group of objects requires a great deal of work. Reference counts are often used to illustrate how garbage collection works, but it never seems to be applied to any kind of Java virtual machine implementation.

(2). "Retrospective reference"

In some faster modes, the garbage collector is not based on reference counting techniques. They are based on the idea that any "live" object must eventually be traced back to the reference in which it survives in the 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 refers to, and then all the references that this object contains, and so on, until the network formed by "references from stacks and static stores" is all accessed. The objects you have visited must all 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.

This approach has the following two approaches:

(2-1). Stop - copy (stop-and-copy) (Low garbage efficiency, need for large space)

There is a practice called Stop - copy (stop-and-copy). Obviously this means that the program is paused ( so it is not in background recycle mode ), and then all surviving objects are copied from the current heap to the other heap, and all that is not replicated is garbage. (picking work) when objects are copied to the new heap, they are next to each other, so the new heap is kept in a compact arrangement, and the new space can be easily and directly allocated as described above.

When moving an object from one place to another, all references to it must be corrected. References that reside in a heap or static store can be corrected directly, but there may be other references to those objects that can be found during traversal ( Imagine a table that maps old addresses to new addresses ).

There are two reasons why this so-called "copy-on-the-collector" is less efficient.

First, you have to have two heaps, and then you have to churn back and forth between the two separate heaps to maintain more space than you actually need. Some Java virtual machines deal with this problem by allocating a few large chunks of memory from the heap on demand, and replication actions occur between these large chunks of memory.

The second problem is replication. After the program enters a stable state, it may produce only a small amount of rubbish, or even no rubbish.

(2-2). Mark - sweep (Mark-and-sweep) (faster, takes up less space, but is not contiguous after release)

  However, the replication collector will still copy all memory from one place to another, which is wasteful. To avoid this situation, some java virtual opportunity to check: if there is no new garbage to produce, will be converted to another mode of operation ( - sweep (mark-and-sweep) , sun Earlier versions of the company java virtual machines use this technology. For general purposes, "Mark - Sweep" mode is quite slow, But when you know that it only produces a small amount of rubbish and doesn't even produce garbage, it's fast.

The idea of "tag - sweep" is also based on a stack and a static storage area, traversing all references to find all the surviving objects. Whenever it finds a surviving object, it sets a tag for the object, and the process does 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. So the remaining heap space is discontinuous, and the garbage collector will have to rearrange the remaining objects if it wants to have contiguous space.

Stop - copy "means that this garbage collection action is not done in the background; instead, the garbage collection action occurs while the program is paused. In Sun 's documentation, many references see garbage collection as a low-priority background process, but in fact the garbage collector is in the early versions of Sun's Java This is not the way virtual machines are implemented. When the amount of available memory is low,theSun version of the garbage collector pauses the program, as well, the "tag - sweep" Work must also be done when the program is paused.

"Adaptive, generational, stop - Copy, Tag - sweep" garbage collector:

Java Virtual opportunities are monitored, and if all objects are stable and the garbage collector becomes less efficient, switch to the "tag - sweep" approach; Similarly,theJava Virtual Opportunity Tracking Tag - sweep "effect, if there is a lot of fragmentation in the heap space, it will switch back to" Stop - copy "mode. This is "adaptive" technology, you can give it a wordy salutation: "Adaptive, generational, stop - Copy, Tag - sweep" garbage collector.

The 5th Chapter (2) Java garbage collector