Introduction
App optimized memory optimization (order) as a small part of memory optimization in the app optimization series.
Due to the relatively jerky memory-related knowledge, memory optimization used in the relevant tools, there are many proper nouns. There is a theoretical understanding of Java memory Management, GC, Android memory management, Dalvik/art and other knowledge that allows us to better use these tools to analyze memory problems.
So let's start with the theory and talk about the GC stuff.
1, what is GC
GC is the abbreviation of garbage collection, the meaning of garbage collection. It can also be garbage Collector, which is the garbage collector.
1.1 Garbage collector
Let's first explain the garbage Collector (garbage collector).
Memory management has always been a big problem in programming. In older languages, such as the C + + language, memory management is explicit, which means that the user requests memory usage and frees the memory itself. This is why the C + + language has destructors in addition to constructors. We call the constructor when we create the object, and the system calls the destructor at the end of the object's scope, and all we need to do is release the associated resource we requested in the destructor to free the memory address.
Obviously, this explicit programmer's own control of the way to release memory is prone to problems, forgetting, leaking, can cause memory issues. Also does not conform to the programmer to lazy characteristics.
Therefore, the Java language introduces the mechanism of automatic memory management, that is, the garbage collector. Most of the modern object-oriented languages are also using automatic memory management mechanisms.
The Memory auto-management recycling mechanism can solve most, but not all, memory problems, which is why we are talking about memory leaks.
Responsibilities of the garbage collector
The garbage collector has three major responsibilities:
- allocating memory;
- Ensure that any referenced objects remain in memory;
- Reclaims the memory of an object that cannot be found by referencing a relationship .
General flow of garbage collection GC process1.2 related concepts garbage collection (GC)
There is a process in the garbage collector to do these things, this process looks up the relationship of our object reference and frees its memory, this process is garbage collection (garbage collection), which is what we often call GC.
Heap and Stack
Simply put:
- Heap memory refers to the memory that the Java Runtime environment uses to assign to objects and JRE classes. is the memory space of the application.
- Stack memory is relative to thread threads, which holds short-lived variable values in methods in threads and references to objects in the heap.
- Stack memory, as the name implies, is a class stack method, always last-in-first-out (LIFO).
- We usually say that the GC is for heap memory. Because stack memory is the equivalent of a random pin.
HEAP&STACKGC Root
We can't translate the GC root.
The so-called GC root we can understand as a heap of memory objects, usually including but not limited to the following:
- class loader loaded by the system class systems class. For example, classes in Rt.jar in the Java Runtime environment, such as classes in the java.util.* package.
- Threads running in thread
- Local/global variables in JNI, user-defined JNI code, or internal JVM.
- Busy Monitor calls either the Wait () or notify () method, or the synchronized (synchronized) thing. Can be understood as a synchronization monitor.
- The Java local instance is also the object that is created in the method that runs the thread's stack.
Live Object/Trash
If the object is quoted , it is called Live (Live), and conversely, if the object reference is unreachable , it is called dead (Dead), also can be called garbage (garbage ).
This reference can be reached and unreachable , as opposed to GC root:
GC-ROOTS2, Java Memory Management mechanism 2.1 about JVM
When we look at our Java version, you'll find:
$ java -versionjava version "1.8.0_74"Java(TM) SE Runtime Environment (build 1.8.0_74-b02)Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)
There's something about a hotspot VM, so what's this? What does it matter with the JVM?
In this brief, so that the wording:
- JVM, Java Virtual machine, can be simply understood as a technical idea, virtual technology concept.
- The HotSpot VM is an implementation of the JVM that includes the server and desktop application editions, which are now maintained and published by Oracle.
The Java version of Sun (Oracle) We currently use (which should be more than 1.3) is a built-in hotspot VM implementation. So the next analysis is based on the hotspot VM, but it's also referred to as the JVM.
2.2 JVM Memory Area
The JVM uses a generational memory management approach that divides the heap into three generations of---generation, the older generation, and the long-lasting generation.
Hotspot Heap Structure
Young Generation
- Cenozoic.
- All new objects.
- Memory management for this zone uses minor garbage collection (small GC).
- Further into Eden Space, Survivor 0 and Survivor 13 parts.
Old Generation
- Elderly area.
- The "old" object in the Cenozoic that performs small-granularity GC survival.
- Memory management for this zone uses major garbage collection (large GC).
Permanent Generation
- Persistent generations.
- Contains class/method information for the app, as well as class and method information for the JRE library.
The small GC performs very frequently and is extremely fast.
A large GC is typically 10 times times slower than a small GC.
The size GC emits a "Stop the World" event, which means that the program is interrupted until the GC is complete. That's why we say that frequent GC can cause user-perceived lag in the elimination of app optimization.
3. Process of GC
Knowing a few areas of memory heap, let's look at how the garbage collector uses these areas to manage memory and recycle garbage.
1. Create a new object
Whenever we create an object using new, this object is assigned to the next generation Eden region:
Object allocation
2. When the Eden area is full
When the Eden Zone memory is allocated, the small GC program is triggered:
Eden Filling
objects that are referenced are moved to the Survivor (survivor) area-S0, and then empty the Eden area, where objects that refer to unreachable are deleted directly, and memory is recycled, as follows:
Aged
3. Eden is full again
When the Eden Zone is allocated again, the small GC executes, the referenced objects are moved to the Survivor (survivor) area, and objects that refer to unreachable are removed from the garbage collection following Eden's emptying.
It is important to note that this time the referenced object was moved to the survivor area of S1 .
Also, the S0 region executes a small GC, moving objects that are also referenced to the S1 area, and age +1. Then empty the S0 and reclaim the objects in which the reference is not reached .
At this point, all objects that are referenced are in the S1 area, and the objects in the S1 area have different ages. As follows:
Next filling
When Eden was third full, the roles of S0 and S1 were exchanged:
S0s1
In this cycle.
4. When the target age of the survivor area reaches the "old Age line"
On top of the cycle, the age of the survivor area will continue to grow, and when some of these objects reach the "old age line", such as the age of 8, they will be "promoted" to the old age zone .
Old aged
So 1~4 steps Repeat, the general flow is this
GC Flow
Anly_jun
Links: Https://www.jianshu.com/p/5db05db4f5ab
Source: Pinterest
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.
Android Memory Optimizer 1 understanding Java GC Garbage Collection mechanism 3