Break one of the Java myths

The garbage collection feature is a great help for Java programmers and is a great advantage in using the Java language. However, the actual situation should not be because garbage collection can eliminate useless memory without thinking about memory problems. The point here is that if you ignore this problem, it can cause problems.

First, the garbage collection algorithms are different on different JVMs, so if you want your program to run well on different JVMs, you can't rely on the specific behavior of garbage collection. Garbage collection is a very active research issue, and better, faster and more accurate collectors are always in the implementation.

However, many modern garbage collectors have the same problem. One of them is that when they run, they do not always release all the objects that can be collected.

Analysis shows that most objects in Java programming have a short lifetime, therefore, for collectors that need to improve performance, they reduce the frequency of checking objects that have longer lives, based on the relatively short lifetime of most objects, and those objects that have longer lifetimes are often referred to, so It is not necessary to check whether such an object can be reclaimed at every check.

You may need to call garbage collection multiple times to release the memory of a particular object. You can run the garbage collector by calling the System.GC method suggestion (note is recommended). The result of requesting this method usually results in a complete collection of garbage collectors. This is usually more thorough and complete than the VM call garbage collection and will be done as quickly as possible. If programmers explicitly invoke System.GC, then the corollary is to have more time to do more work (note that there are more things to do more, which means a lot of checking, and remember the changes in the frequency of checking for long life objects?). Rather than really thorough removal). In either case (explicit invocation of garbage collection and VM call garbage collection) do not assume that all objects that can be collected are actually collected.

Explicit invocation System.GC has a greater chance of completing a thorough collection, but is not guaranteed to be completed.

The trouble with another programmer is that they tend to keep references to objects that are no longer needed. This will prevent the garbage collector from releasing the object.

This happens when you manage the list yourself.

Consider the following Objstack class. This class uses the push and pop methods to manage objects in the stack. Two methods take advantage of the index, which indicates the next available location in the stack. The push method stores a reference to the new object and increases the index value, while the Pop method decreases the index value and returns the topmost element of the stack.

Example one: The objstack of not realizing the pop method correctly

class ObjStack
{
　private Object[] stack;
　private int index;
　public void push(Object o)
　{
　　stack[index] = o;
　　index++;
　}
　public Object pop()
　{
　　index-;
　　return stack[index];
　}
　//...
}

Now create an object with a capacity of 10 and then call the 8 push method to add an object to it, then the index value is 8.

Now consider what happens when you call the Pop method three times. The index value at this point is 5, but note that there is no other change in the outer stack except for this index value to be changed!

Although the Pop method reduces index values, the stack actually retains a reference to those objects. Calling pop methods often means that those objects should be collected (most of the time, even if not immediately, after the object is used later). However, since the stack still retains a reference to the object, it cannot be collected. These objects can be collected only if they are replaced after the call to push. The implementation of the correct pop is as follows:

public Object pop()
{
　index-;
　Object o = stack[index];
　stack[index] = null;
　return o;
}

In this version of the Pop method, when the reference is returned, the stack deletes the reference to them so the garbage collector can recycle them later.

In your own code, for those unwanted objects, do not refer to them! The execution of the program is greatly affected by the available memory, the less available memory, the more execution times of garbage collection, which will greatly damage performance.