A detailed explanation of the problem of handling garbage collection in Java

As we know, many programming languages allow for the dynamic allocation of memory space during the runtime of a program.

The way in which memory is allocated varies depending on the grammatical structure of the language. However, regardless of which language is allocated in memory, the last thing to return is the starting address of the allocated memory block, which returns a pointer to the first address of the memory block.

When the allocated memory space is no longer needed, in other words, when the handle pointing to the memory block is out of use, the program or its operating environment should reclaim the memory space to save valuable memory resources.

In c,c++ or other programming languages, both objects and dynamically configured resources or memory must be generated and recycled by the programmer, otherwise the resources will be consumed, resulting in a waste of resources or even panic. But the manual collection of memory is often a complex and arduous task. Because it's very difficult to predetermine whether the memory footprint should be reclaimed! If a program cannot reclaim memory space, and the program runs without the memory space that can be allocated in the system, the program can only crash. In general, the memory space that we allocate, but cannot reclaim, is called the "Memory leak body (Memory leaks)".

The potential dangers of this program are not allowed in a language that is known to be rigorous and secure in Java. However, the Java language can not limit the freedom of programmers to write programs, and can not remove the part of the Declaration object (otherwise it is not object-oriented programming language), then the best solution is from the Java program language itself to start with the characteristics. As a result, Java technology provides a system-level thread (thread), a garbage collector thread (garbage Collection thread), to track each piece of allocated memory space when the Java virtual machine Machine) in an idle loop, the garbage collector thread automatically checks every fast-allocated memory space and automatically reclaims the unused chunks of memory that can be recycled every fast.

A garbage collector thread is a low-priority thread that, in the life cycle of a Java program, only has the opportunity to run when memory is idle. It effectively prevents the emergence of the memory leak, and greatly saves valuable memory resources. However, the scenario of executing the garbage collector through a Java Virtual machine can be varied.

The characteristics of the garbage collector and its enforcement mechanisms are described below:

The garbage collector system has its own set of schemes to determine which memory block should be recycled, and which is not eligible for temporary recovery. The execution of the garbage collector in a Java program is automatic and cannot be enforced, and even if the programmer can clearly determine that a piece of memory is useless, it should be recycled and the programmer cannot force the garbage collector to reclaim the memory block. The only thing a programmer can do is by calling system. GC method to "recommend" the execution of the garbage collector, but whether it can be performed and when it is performed is unknowable. This is also the main drawback of the garbage collector. Of course, this shortcoming is afterward relative to the great convenience it brings to programmers.

The main features of the garbage collector are:

1. The goal of the garbage collector is to reclaim the memory space of the object that is already useless, so as to avoid the generation of the memory leak, save the memory resource and avoid the crash of the program code.

2. The standard for the garbage collector to determine whether an object's memory space is useless is if the object cannot be referenced by any "active part" of the program, at which point we say that the object's memory space is useless. The so-called "part of the activity" refers to the invocation of a part of the program, which is in the process of execution and has not been completed.

3. While the garbage collector thread runs as a low-priority thread, it may execute suddenly to save memory resources when the system's available memory is too low. Of course, its implementation is unpredictable.

4. The garbage collector cannot be enforced, but the programmer can invoke system. GC method to recommend execution of the garbage collector.

5. There is no guarantee that a useless object will be collected by the garbage collector or that the garbage collector will perform in a section of the Java language code. Therefore, the memory space allocated during program execution may be retained until the program is executed, unless the space is reassigned or otherwise reclaimed. Thus, it is impossible to completely eradicate the emergence of the memory leakage body. But don't forget that the Java garbage collector frees programmers from the heavy work of manually reclaiming memory space. Imagine a programmer to use C or C + + to write a paragraph of 100,000 lines of code, then he will fully appreciate the Java garbage collector's advantages!

6. There is also no way to predict which of the objects in the collection of garbage collector criteria will be collected first.

7. Circular referencing objects do not affect their collection by the garbage collector.

8. You can imply that the garbage collector collects an object by initializing its reference variable (reference variables, or handle handles) to a null value. But at this point, if the object is connected to an event listener (a typical AWT component), it cannot be collected. So before you set a reference variable to be a null value, you should be aware that the reference variable points to whether the object is listening, and if so, remove the listener first before you can assign a null value.

9. Each object has a finalize () method, which is inherited from the object class.

10. The Finalize () method is used to reclaim system resources other than memory, such as file processors and network connectors. The invocation order of the method is independent of the order in which the object used to invoke the method is created. In other words, the order of the method and the actual invocation order of the method are irrelevant when writing the program. Please note that this is only a feature of the Finalize () method.

11. Each object can invoke only the Finalize () method once. If an exception (exception) is generated when the Finalize () method executes, the object can still be collected by the garbage collector.

12. The garbage collector tracks each object, collects the unreachable objects (that is, the object is not invoked by any "living part" of the program), and reclaims the memory space it occupies. But when garbage collection is done, the garbage collector invokes the Finalize () method to "revive" the unreachable object again as a reachable object by letting other objects know it exists. Since each object can only invoke the Finalize () method once, each object can only "recover" once.