The introduction

Next App optimization memory optimization (sequence), as a small part of the App optimization series memory optimization.

As memory related knowledge is relatively raw, memory optimization used in the related tools, there are also a lot of terms. A theoretical understanding of Java memory management, GC, Android memory management, Dalvik/ART and other knowledge can make us better use of these tools to analyze memory problems.

So let’s start with the theory and talk about GC.

1, what is a GC

GC stands for garbage collection. It can also be a Garbage Collector.

1.1 Garbage collector

Let’s start by explaining the Garbage Collector.

Memory management has always been a big problem in programming. In older languages, such as C++, memory management is explicit, meaning that the user requests memory usage and frees it himself. This is why there are destructors in addition to constructors in C++. We call the constructor when we create the object. The system calls the destructor when the object ends its scope. All we need to do is to free the memory address in the destructor.

Obviously, this explicit, programer-controlled way of freeing memory is prone to memory problems that can be forgotten or missed. Nor does it accord with the characteristics of lazy programmers.

Therefore, the Java language introduced automatic memory management mechanism, namely garbage collector. Most modern object-oriented languages also use automatic memory management mechanisms.

Automatic memory management recycling can solve most, but not all, memory problems, which is why we’re talking about memory leaks.

The responsibilities of the garbage collector

The garbage collector has three responsibilities:

  1. Allocate memory;
  2. Ensure that any referenced objects remain in memory;
  3. Reclaim memory for objects that cannot be found by reference relationships.

The general process of garbage collection

                                                      gc process

1.2 Related Concepts

Garbage Collection (GC)

There is a process in the garbage collector that does all of this, that looks up our object references and frees its memory, and that process is garbage Collection, also known as GC.

Heap and Stack

Just to be brief:

  • Heap memory is the memory that the Java runtime environment allocates to objects and JRE classes. Is the memory space of the application.
  • Stack memory is relative to Thread memory, and it holds short-term variable values from methods in the Thread, references to objects in the Heap, and so on.
  • Stack memory, as the name suggests, is stack-like, always last in, first out (LIFO).
  • We usually refer to GC for Heap memory. Because Stack memory is pretty much on demand.

                                                        heap&stack

GC Root

Literal translation of GC root, let’s not translate it. GC Root refers to an object outside of Heap memory, usually including but not limited to the following:

  • System Class Class loaded by the System Class Loader. For example, classes in rt.jar in the Java runtime environment, such as classes in java.util.* package.
  • Thread The running Thread
  • Local/global variables in JNI, user-defined JNI code, or within the JVM.
  • Busy Monitor Anything that calls wait() or notify(), or synchronized. Think of it as a synchronization monitor.
  • Java native instances that are still created by methods in the stack of running Thread.

Live objects/garbage

If the object is referentially reachable, it is called live, and if the object is referentially unreachable, it is dead, which can also be called garbage.

This reference is reachable and unreachable relative to GC Root:

                                                            gc-roots

2. Java memory management mechanism

2.1 about the JVM

When we usually look at our Java version, you’ll find:

$ java -version
java version "1.8.0 comes with _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)
Copy the code

There’s a HotSpot VM thing, so what is this? What does it have to do with the JVM?

In this brief, for the purpose of writing:

  • JVM, Java virtual machine, can be simply understood as a technical idea, virtual technology concept.
  • HotSpot VM is an implementation of the JVM, including server edition and desktop application edition, currently maintained and distributed by Oracle.

The Version of Java we currently use from Sun (Oracle) (1.3 or above) is built in with HotSpot VM implementation. So the rest of the analysis is based on HotSpot VM as well, but the JVM for short.

2.2 JVM memory area

The JVM uses generational memory management to divide the Heap into three generations – new generation, old generation, and persistent generation.

Hotspot heap structure

  • Young Generation

    • The new generation.
    • All objects of new.
    • Memory management for this region uses minor garbage collection(small GC).
    • It is further divided into Eden Space, Survivor 0 and Survivor 1.

  • Old Generation

    • Area of the elderly.
    • Surviving “old” objects in the new generation that perform smaller-grained GC.
    • Memory management for this region uses major Garbage Collection (Large GC).

  • Permanent Generation

    • The last generation.
    • Contains the class/method information of the application and the class and method information of the JRE library.

Small GC executions are very frequent and extremely fast. A large GC is typically 10 times slower than a small GC. Both large and small GCS emit “Stop the World” events, which interrupt the program until the GC is complete. This is why frequent GC causes user perception of lag in App optimization to eliminate lag.

3. GC process

Having seen several areas of the memory Heap, let’s look at how the garbage collector uses these areas to manage memory and recycle garbage.

1. Create a new object

Each time we create an object using new, the object is assigned to the Eden region of the new generation:

                                                         object allocation

2. When Eden region is full when Eden region memory is allocated, the small GC program will be triggered:

                                                                Eden filling

The objects with reachable references will be moved to the Survivor region –S0, and then the Eden region will be emptied. In this case, the objects with unreachable references will be deleted and the memory will be reclaimed as follows:

                                                                    aged

3. When Eden is full again, after Eden is allocated again, the small GC will execute, and the objects with reachable references will be moved to the Survivor area, while the objects with unreachable references will be deleted and reclaimed after Eden is emptied.

Note that this time the object reachable by reference is moved to the survivor zone of S1. Also, the S0 region performs a small GC, moving objects that are still referentially reachable to S1 with age +1. Then empty S0 and reclaim objects that reference unreachable objects in it.

At this point, all objects reachable by reference are in S1, and objects in S1 have different ages. As follows:

                                                               next filling

When Eden is full for the third time, the roles of S0 and S1 are reversed:

                                                                  s0s1

And so on.

4. When the age of the Survivor zone reaches the “old line “, the age of the Survivor zone will continue to increase, and when some of them reach the” old line “, such as 8 years old, they will be “promoted” to the old zone.

                                                             old aged

So 1~4 steps repeat, the general process is like this

                                                             gc flow