Singleton mode: Singleton mode and garbage collection

Whether or not the JVM garbage collection mechanism recycles unneeded Singleton mode objects for a long time is indeed a controversial issue. The purpose of this part is to discuss this issue with a wide range of bloggers. In order to allow more people to see this article, please read the article and click "TOP" to rank this article as high as possible. I would like to thank you.

Proposition: Will a single-instance object be recycled by the JVM's garbage collection mechanism if it is not used for a long time.

First of all, I have never considered the impact of garbage collection on the singleton model before. I read a book last year, zen of design patterns by Qin Xiaobo. In the book, it is mentioned that in J2EE applications, the JVM garbage collection mechanism treats long-used Singleton objects as garbage and recycles them when the CPU is idle. I have read several books on design patterns, including Java and patterns, which do not mention the impact of the JVM garbage collection mechanism on Singleton instances. In addition, I have never had the experience of recycling single-instance objects during my work. In addition, many predecessors once warned me not to declare too many static attributes, these static attributes are not released after being loaded. Therefore, I am skeptical about the statement that JVM garbage collection will recycle Singleton objects. Gradually, I found that, among my colleagues and online technical staff, this problem is basically a stark opposition between the two schools. In the end, will the JVM recycle unused Singleton objects for a long time.

The author's opinion on this issue is: it will not be recycled.

The following is my testing code.

class Singleton {private byte[] a = new byte[6*1024*1024];private static Singleton singleton = new Singleton();private Singleton(){}public static Singleton getInstance(){return singleton;}}class Obj {private byte[] a = new byte[3*1024*1024];}public class Client{public static void main(String[] args) throws Exception{Singleton.getInstance();while(true){new Obj();}}}

　　

The purpose of this program is to simulate the J2EE container. First, the singleton class is instantiated. This Singleton class occupies 6 MB of memory, and then the program enters an endless loop to constantly create objects, force the JVM to perform garbage collection, and then observe the garbage collection information. If the memory is greater than 6 MB after garbage collection, the garbage collection will not recycle the singleton object.

The virtual machine used to run this program is the hotspot virtual machine, which is also the official Virtual Machine Provided by the most popular Java, also known as JDK. The version is jdk1.6.0 _ 12.

The parameter of VM arguments during runtime is-verbose: GC-xms20m-xmx20m, which means that the memory information is displayed every time the JVM recycles garbage, and the JVM memory is set to a fixed 20 m.

Running result:

......

[Full GC 18566 K-> 6278 K (20352 K), 0.0101066 secs]

[GC 18567 K-> 18566 K (20352 K), 0.0001978 secs]

[Full GC 18566 K-> 6278 K (20352 K), 0.0088229 secs]

......

From the running results, we can see that there is always 6 MB space not collected. Therefore, I believe that at least in the hotspot virtual machine, spam will not recycle Singleton objects.

Later, I checked some related materials. The garbage collection algorithm of the hotspot virtual machine uses the root search algorithm. The basic idea of this algorithm is that any "active" object will be traced back to its reference in the stack or static storage zone. Use a series of references named root (GC roots) as the starting point to start searching from these roots. After a series of paths, if you can reach the objects in the Java heap, this object is "active" and cannot be recycled. The root objects can be:

The referenced object in the Virtual Machine stack (the local variable table in the stack metadata.
The object referenced by the class static attribute in the method area.
The object referenced by constants in the method area.
The referenced object of JNI in the local method stack.
The method area is a memory area of JVM used to store class-related information. Obviously, objects created in Java Singleton mode are referenced by static attributes in their own classes and comply with the second one. Therefore, the singleton object will not be garbage collected by JVM.

Although the singleton object in the JVM heap will not be garbage collected, will the singleton class be collected if it is not used for a long time? Because JVM also has a garbage collection mechanism for the method area. If the singleton class is collected, the objects in the heap will be lost to the root path and will be collected by garbage. In this regard, I checked the method of garbage collection in the Method Area by the hotspot virtual machine. The criteria for determining the JVM uninstall class are as follows:

All instances of this class have been recycled, that is, no instances of this class exist in the Java heap.
Classloader for loading this class has been recycled.
The Java. Lang. Class Object corresponding to this class is not referenced anywhere and cannot access this class through reflection anywhere.
Only when all three conditions are met will JVM uninstall classes during garbage collection. Obviously, the singleton class does not meet condition 1, so the singleton class will not be uninstalled. That is to say, as long as the static reference in the singleton class points to the singleton object in the JVM heap, the singleton class and singleton object will not be garbage collected. Based on the root search algorithm, whether the object will be garbage collected has nothing to do with the length of time it has not been used, just because the object is "active. If an object has not been used for a long time and is recycled, the collection algorithm should be the longest recently unused algorithm. The longest unused algorithm is generally used in the internal and external memory swap of the operating system, isn't it too insecure if it is used in Virtual Machine garbage collection? The above is my opinion.

Therefore, the author's point of view is: In the hotspot virtual machine version 1.6, unless the link to the singleton object statically referenced in the singleton instance is artificially disconnected, the JVM garbage collector will not recycle the singleton object.

References

Java virtual machine specification

Java hotspot VM Memory Management

Java programming ideas

Java and Mode

Design Mode

Zen of design patterns

Deep understanding of Java Virtual Machine

Singleton mode: Singleton mode and garbage collection