The life cycle of static variables in Android

The life cycle of a static variable, starting with the load of the class, terminates the release of the class.
When does the class load?
We know that when the app is opened, a process is created, and then an instance of the DVM is initialized, which is responsible for the load release and garbage collection of the class.
In other words, after the process is created, the class is loaded and the static variable is born.
When will it be released?
Of course, when the class is unloaded. With the top. The static variable dies before the process ends.
We know that Android, you are not sure when the process will be killed. So
1. There is no guarantee that static variables will persist. (process may be killed)
2. The value of the static variable is the initial value each time the app is opened (the process has not been killed so the static variable is saved or the last value).
Also, static variables are not garbage collected, their objects remain referenced, and arc cannot be 0.
So you have to release the static variable yourself.

RELATED LINKS found on the Internet

Single-case mode discussion: Singleton mode and garbage collection: http://blog.csdn.net/zhengzhb/article/details/7331354

It is indeed a controversial issue that the JVM's garbage collection mechanism will not be able to reclaim long-unused singleton schema objects. This part of the content of a separate article is also to the broad masses of Bo friends to discuss the issue. In order to let more people see this article, please bo friends after reading the article, click on the "top", so that this article ranked as far as possible before. I thanked the author here.
Discussion proposition: When a singleton object is not used for a long time, it will be recycled by the JVM garbage collection mechanism.
First of all, why this question arises, I have never considered the impact of garbage collection on the single-case model, until last year read a book, "Design mode of Zen" Qin Xiaobo. It is mentioned in the book that in the Java EE application, the JVM garbage collection mechanism treats the long-unused singleton class objects as garbage and recycles them when the CPU is idle. Several of the previously read design patterns, including Java and patterns, did not mention the effect of the JVM garbage collection mechanism on the singleton. And in the process of work, there is no single object has been recycled experience, coupled with the work of many predecessors have warned the author: Try not to declare too many static properties, because these static properties will not be released after loading. It is therefore doubtful that the JVM garbage collection will reclaim singleton objects. Gradually, found in colleagues and online technical staff, the problem is also basically a stark opposition to the two factions. So will the JVM recycle the long-unused singleton objects?
On this issue, * * My opinion is: do not recycle * *.
The following gives my test code

classSingleton {Private byte[] A =New byte[6*1024*1024];Private StaticSingleton Singleton =NewSingleton ();PrivateSingleton () {} Public StaticSingleton getinstance () {returnSingleton; }  }classOBJ {Private byte[] A =New byte[3*1024*1024];} Public classclient{ Public Static voidMain (string[] args)throwsexception{singleton.getinstance (); while(true){NewObj (); }}}

The purpose of this procedure is to simulate the Java EE container, first instantiate a singleton class, this singleton class accounted for 6 m of memory, then the program into the dead loop, constantly create objects, forcing the JVM to garbage collection, and then observe the garbage collected information, if the garbage collection, the memory is still greater than 6M, It means that garbage collection does not reclaim singleton objects.
The virtual machine running this program is a hotspot virtual machine, that is, we use the most Java-provided virtual machine, commonly known as JDK, version is Jdk1.6.0_12
The runtime vm arguments parameter is-verbose:gc-xms20m-xmx20m, which means that the JVM's memory is set to a fixed 20M each time the JVM is garbage collected and the memory information is displayed.
Operation Result:
......
[Full GC 18566k->6278k (20352K), 0.0101066 secs]
[GC 18567k->18566k (20352K), 0.0001978 secs]
[Full GC 18566k->6278k (20352K), 0.0088229 secs]
......
From the running results you can see that there is always 6M of space not being collected. Therefore, I think, at least in the hotspot virtual machine, garbage collection is not recycled singleton objects.
Some related information was later consulted, and the garbage collection algorithm of the hotspot virtual machine uses the root search algorithm. The basic idea of this algorithm is that any "live" object must eventually be traced back to its reference in the stack or static storage area. By a series of references called Root (GC Roots) as a starting point, searching from these roots, through a series of paths, if you can reach the objects in the Java heap, then this object is "live", is not recyclable. The objects that can be used as roots are:
The referenced object in the virtual machine stack (the local variable table in the stack frame).
The object referenced by the class static property in the method area.
The object referenced by a constant in the method area.
The referenced object of JNI in the local method stack.
A method area is a memory area of the JVM that holds information about the class. Obviously, the object created in the singleton schema in Java is referenced by a static property in its own class, conforming to the second one, so that the singleton object is not collected by the JVM garbage.
Although the singleton objects in the JVM heap are not garbage collected, will the singleton classes themselves be collected for long periods of time? Because the 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 inevitably be garbage collected. In this paper, the author looks at the garbage collection method of the hotspot virtual machine to the method area, and the criteria of the JVM unloading class are as follows:
All instances of the class have been reclaimed, that is, no instances of the class exist in the Java heap.
The ClassLoader that loaded the class have been recycled.
The corresponding Java.lang.Class object of this class is not referenced anywhere, and cannot be accessed anywhere by reflection on the method of the class.
Only three conditions are met, and the JVM unloads the class at garbage collection time. Obviously, the Singleton class does not satisfy the condition one, so the Singleton class will not be unloaded. That is, as long as a static reference in a singleton class points to a singleton object in the JVM heap, neither the Singleton class nor the Singleton object is garbage collected, depending on the root search algorithm, whether the object will be garbage collected and not used for the length of time, simply because the object is not "live". If an object is recycled for a long time, then the collection algorithm should be the most recent unused algorithm, the most recent unused algorithm is generally used in the internal and external exchange of the operating system, if used in virtual machine garbage collection, it is not too insecure? The above is the author's view.

Second (reproduced) The life cycle of the Android static variable

Android is developed in Java, and its static variable life cycle adheres to the Java design. We know that a static variable allocates memory when the class is load and exists in the method area. When the class is unloaded, the static variable is destroyed. In a PC's client program, a class is loaded and unloaded, which can be simply equivalent to the start and end of the JVM process. What about Android? The same Dalvik VM is used. However, Android is not a very prominent process concept, so the life cycle of static variables will be blurred, this ambiguity for value types is irrelevant, if it is a static object reference, it is related to memory recovery, memory leaks, it is necessary to deepen research and understanding.

A static variable allocates memory when the class is loaded.

When is the class loaded?

When we launch an app, the system creates a process that loads an instance of the Dalvik VM, then the code runs on the DVM, the load and unload of classes, garbage collection, and so on are the responsibility of the DVM. This means that when the process starts, the class is loaded and the static variable is allocated memory.

Static variables are destroyed when the class is unloaded.

When was the class unloaded?

At the end of the process.

Note: In general, all classes are default ClassLoader loaded, as long as ClassLoader exist, the class will not be unloaded, and the default ClassLoader life cycle is consistent with the process, this article discusses the general situation.

Iii. when the process of Android is over

This is Android's process and memory management is different from the core of the PC-if the resources are sufficient, Android will not kill any process, another means that the process can be killed at any time. Android will restart the process of being killed when resources are sufficient. That is, the value of a static variable, if not done, is unreliable, it can be said that everything in memory is unreliable. If you want to be reliable, you still have to save it to the NAND or SD card and restore it back when you reboot.

Another scenario is that you cannot leave all activity equal to the exit of the process, so when the user clicks on the icon to launch the application, the value that was previously stored in the static variable may still exist, so it is necessary to give the empty operation depending on the situation.

Four, application is equally unreliable

Application is actually a singleton object, also put in memory, when the process is killed, it is completely emptied, but the Android system will help rebuild the application, and we stored in the application data naturally no, or have to deal with their own.

V. Objects that are statically referenced are not garbage collected

As long as the static variable is not destroyed and there is no null, its object has been kept referenced, that is, the reference count cannot be 0, and therefore is not garbage collected. Therefore, singleton objects are not recycled at run time.

The life cycle of static variables in Android