As an Android engineer, I have read a lot of related optimization articles about Android memory leaks, most of which tell you what to do, what to do, and some specific measures. And it never explained why it was done.
Today, I want to start with the mechanism behind this aspect of memory optimization, and explore the principles behind it. However, if you want to study Java's memory optimization, you must study the Java recovery mechanism. If you want to be able to understand GC basically, you must understand the memory area of the Java program when it is running. No way, learn the whole set.
Besides, I am professional.
The following is the memory model of the Java program at runtime
- When your Java bytecode is executed, the virtual machine will roughly divide the memory it manages into these five parts, and throw your code into these five boxes:
- Method area: used to store class information, constant static variables, etc.
- Local method stack: used to provide services for the execution of local methods, pass
- Stack: Strictly speaking, it is called the virtual machine stack, which is an important memory model for the virtual machine to execute Java methods. At the same time store local variables, object references (with this, you can find the object) and so on.
- Heap: The area where the object instance is stored (for example, A a=new A(), then the reference to a is stored in the stack, and the object of new A() is placed in the heap)
- Program counter: used to record the address of the bytecode executed by the current thread, and instruct the execution engine to execute the code.
Speaking of this, you may start to feel a little dizzy, my fault, this is the old problem of writing essays when I was young, and I often used to make up the number of words, so that I started to do things as soon as I stroked the pen. You put down the knife and listen to me continue.
The program data you write is allocated after those five areas. The hungry garbage collection mechanism hiding in the dark immediately jumped out.
But he does not collect garbage in every area. Don't think that only people are snobbery. In fact, the GC program is also very snobbery and realistic. It always collects garbage only where it is easy to receive garbage. That is, in the heap. Because the heap occupies the bulk of the Java runtime memory...Of course, I'm joking, in fact, where the GC goes to collect garbage is prescribed.
- "The organization has decided, and you will collect garbage in the heap in the future." (We will talk about the history of the garbage heap here...)
Well, it's finally time for memory optimization. As mentioned earlier, Java will focus on recycling garbage in the heap, and the heap basically stores object instances, so the focus of memory recovery is object instances! !
So, what are the criteria for GC to reclaim objects? The answer is GC Roots reference chain
- Searching down through this reference chain, all on these chains are "living" objects, and the rest are recycled.
Actually, I know that even if I explain so much, you don t understand it. It s okay. I just paint a picture. I ll do a full set of things.
Besides, I am professional.
- The GC program starts from the top of the stack and always finds the bottom of the stack, looking for the object instance corresponding to each object reference, and then looking for references to other objects in the instance, if so, continue to look for (this part is not drawn, but it is also Important) If no, return to the stack and continue searching to the bottom of the stack.
- Of course, GC will not only look for references in the stack, but also look for references in the static storage area (where static variables are stored, guess what corresponds to the above area), (because some objects in the heap are not referenced in the stack , Its reference is in the static storage area, similar to static A a =new A())
Okay, we finally finished talking about the mechanism of Java memory recovery, then the mechanism behind memory optimization is basically uncovered by us:
- When the object is no longer used, empty the reference, then the GC will not find the corresponding object in the heap along the stack or the reference in the static storage area, and the corresponding object will be recycled.
- Try not to refer to other unnecessary object instances that occupy a large amount of memory in object instances that have a long life cycle (may not be recovered during program execution)
Then the recommendations for memory optimization corresponding to Android are very intuitive, basically around one point:
- In Android, Activity and other objects occupy a large memory space. When not in use, it must be ensured that all direct references and indirect references of the current object are set to null. The memory can be released. Otherwise, there will be a memory leak.
The most fundamental principle of Java memory optimization is to work hard to adapt your program to Java's GC mechanism .
You may be a little impatient, thinking that I can actually make things clear in a few words, but I have a lot of moths, wasting your precious time.
As I said, making up the word count is my old fault, besides, I am still professional.