How the Java garbage Collection period works (programming ideas)

How the garbage collector works:
In previous programming languages, it was expensive to allocate objects on the heap, so the reader would naturally feel that it was very expensive to allocate all objects in Java (except the base type) on the heap. However, the garbage collection period has an obvious effect on how to increase the object's creation speed.
For example, you can think of the heap in C + + as a yard where every object is responsible for managing its own turf. After some time, the object may be destroyed, but the site must be reused. In some Java virtual machines, the implementation of the heap is quite different: it is more like a conveyor belt, and it moves forward one grid for each assigned object. This means that the allocation of object storage space is very fast. Java's "heap pointer" simply moves to an area that has not yet been allocated, and is more efficient than C + + allocating space on the stack.
The heap in Java does not work exactly like a conveyor belt. If it does, it is bound to cause frequent memory paging ———— move it out of the hard drive, so it will appear to require more memory than is actually needed. Page scheduling can significantly affect performance, and eventually, after you have created enough Cui Xiang, memory resources will be exhausted. The secret lies in the garbage collector's involvement. When it works, it recycles the space on one side, making the objects in the heap compact, so that the "heap" pointer can easily move closer to the beginning of the carousel and avoid page faults. By reordering objects through the garbage collector, a high-speed heap model with infinite space to allocate is implemented.
To get a better understanding of garbage collection in Java, you can learn about garbage collection mechanisms in other systems. The reference counter is a simple but slow garbage collection technique. Each object contains a reference counter, and the reference technique adds 1 when a reference is connected to the object. The reference counter is reduced when the object is out of scope or is set to null. Although the overhead of managing reference technologies is modest, this overhead continues throughout the program life cycle. The garbage collection period is traversed on the list that contains all the objects, and when a reference count of one object is found to be 0 o'clock, it frees up the space it occupies (however, the reference count pattern often releases the object at the count value to 0 o'clock immediately). There is a flaw in this approach, if there is a circular reference between objects, it is possible that the object should be recycled, but the reference count is not zero. For the garbage collector, locating such an interactive self-referencing group of objects requires a great deal of work. Reference counting is often used to illustrate how garbage collection works, but it never seems to be applied to any kind of Java Virtual machine implementation.
In some faster modes, the garbage collection period is not based on the reference counting technique. They are based on the idea that any "live" object must eventually be traced back to the reference to its inventory 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 locks to, and then all references that this object contains, and so on, so repeatedly that the network that originated from the stack and static store references is all accessed. The objects you have visited must all be "live". Note that this solves the problem of "interactive self-referencing groups of objects" ———— this phenomenon is not discovered at all, and therefore is automatically recycled.
In this way, the Java virtual machine will employ an adaptive garbage collection technology. The surviving objects that are placed on how to find depend on the different Java Virtual machine implementations. There is a practice named stop-Assignment (stop and copy). It is obvious that the program is paused (so it is not in the background recycle mode), then all surviving objects are assigned from the current heap to the other heap, none of the assigned values are garbage, and when the objects are assigned to the new heap, they are next to each other, so the new heap remains compactly arranged, and then it can be as simple as the aforementioned A new space is allocated directly to it.
When moving an object from one place to another, all references to it must be corrected. References in the heap or static storage can be corrected directly, but there may be other references to those objects that can be found during traversal (imagine a table with the old address mapped to the new address)
For this so-called replication-type collector, the efficiency is reduced, for two reasons. First, you have to have two heaps, and then you have to churn back and forth between the two separate heaps to maintain 1 time times 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 only produce a small amount of garbage, or even no garbage, however, the replication collector will still copy all the memory from one place to another, which is wasteful. To avoid this scenario, some Java virtual opportunities are checked: If no new garbage is generated, it is converted to another mode of operation ("adaptive"). For general purposes, the "mark-sweep" approach is quite slow, but it is fast when you know that only a small amount of rubbish will be generated and not even produce garbage.
The idea of "mark-sweep" Lock is also based on the stack and the 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 will not begin until all marked work is complete. During the cleanup process, objects that are not marked are freed, and no copy operations 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 performed in the background, but the program will be paused when the garbage collector acts on the colleague. In Sun's documentation, many reference documents treat garbage collection as a low-priority background process, but in fact the garbage collector is not implemented in this way in earlier versions of Sun's Java virtual machines. When the amount of available memory is low, the sun version of the garbage collector pauses the program, as well, the "tag-sweep" Work must also be done when the program is paused.
As mentioned above, in the Java Virtual Machine discussed here, the memory allocation is in a larger "block" unit. If the object is large, it occupies a separate block. Strictly speaking, stop-copy requires that all inventory cashing be copied from the old heap to the new heap before releasing the old object, which results in a large amount of memory replication behavior. As soon as possible, the garbage collection period can be recycled to the flying blocks to copy objects. Each block uses the corresponding algebra (generation count) to record whether it survives. In general, if a reference is made quickly, its algebra will increase, the garbage collection period will be fully cleaned up periodically ———— large objects will still not be copied (only their algebra will increase), and the chunks containing small objects are copied and organized. Java Virtual opportunities are monitored, and if all objects are stable and the garbage collector becomes less efficient, switch to the "mark-sweep" mode, and the Java Virtual Opportunity tracks the "mark-sweep" effect, and if there is a lot of fragmentation in the heap space, it switches back to the "stop-copy" mode. This is "adaptive" technology, you can give it a wordy salutation: "Adaptive, generational, stop-copy, tag-sweep" garbage collector.

How the Java garbage Collection period works (programming ideas)