A brief analysis of Android's garbage collection and memory leaks

The Android system runs on the Java virtual machine. As an embedded device, the memory is often very limited. Understanding Android's garbage collection mechanism can effectively prevent memory leaks or OOM problems. This article is an introductory article that will briefly discuss the principles of garbage collection and memory leaks, and will not discuss the underlying mechanism of the Dalvik virtual machine or native-level issues.

1. Basics

Before analyzing garbage collection, we need to review the basics of Java and discrete mathematics.

• Instantiation: An object is an instance of a class. The process of creating an object is also called instantiation of a class. Objects are created using classes as templates. For example, if we say Car car = new Car();, we have created an instance of Car (Create new class instance of Car).
• Reference: The instantiation of some objects requires other object instances. For example, the instantiation of ImageView requires the Context object, which means that ImageView holds a reference to Context.
• Directed graph: A graph with directed lines on each edge is called a directed graph. Garbage collection in Java uses directed graphs for memory management. The direction of the arrow indicates the reference relationship. For example, B ← A means that B needs A and B references A.
• Reachable: In a directed graph D={S,R}, for Si, Sj belonging to S, if there is any path from Si to Sj, then Si is said to be reachable to Sj. In other words, when the arrow between B ← A is broken, it is called unreachable, and A cannot reach B at this time.
• Shallow heap vs. retained heap
  • Shallow heap represents the memory consumed by the current object
  • Retained heap represents the total memory consumed by the current object plus the memory it references

Google I/O 2011: Memory management for Android Apps

The orange Object in the figure above is the starting point of the directed graph. Its Shallow heap is 100, and its Retained heap is 100 + 300 = 400.

2. What is Garbage Collection

Java GC (Garbage Collection) mechanism is one of the main differences between Java and C++/C. As a Java developer, you generally do not need to write special memory recovery and garbage cleaning code, and you do not need to be as nervous about memory leaks and overflows as C programmers. This is because there is an automatic memory management and garbage cleaning mechanism in the Java virtual machine. In general, this mechanism marks the memory in the virtual machine and determines which memory needs to be recycled. According to a certain recycling strategy, the memory is automatically recycled, and the memory space in the virtual machine is guaranteed to be never stopped (Nerver Stop) to prevent memory leaks and overflows.

3. When is garbage collection needed?

For GC, when the programmer creates an object, GC starts to monitor the address, size and usage of the object. Usually GC uses a directed graph to record and manage all objects in the heap, and in this way determines which objects are "reachable" and which objects are "unreachable". When an object is unreachable, that is, when the object is no longer referenced, it will be garbage collected.

There are many documents on the Internet that introduce the reachable relationship. As shown in the figure, in the sixth line, o2 changes its pointing direction, and Obj2 no longer references main, that is, they are unreachable, and Obj2 may be recycled in the next GC.

developerWorks Java technology

4. What is a memory leak?

When you no longer need an instance, but the object is still referenced, preventing it from being garbage collected (Prevent from being bargage collected). This situation is called a memory leak.

Below, we will use the translation of How to Leak a Context: Handlers & Inner Classes as an example to introduce a memory leak.

Look at the following code

 public class SampleActivity extends Activity { 
 
  private final Handler mLeakyHandler = new Handler() { @Override
 public void handleMessage(Message msg) { // ...
 }
 }
 }

When you finish typing this code, the IDE should remind you

 In Android, Handler classes should be static   or leaks might occur.

How did it leak?

1. When you start an application, it automatically creates a Looper object in the main thread to handle the message in the Handler. Looper implements a simple message queue and processes Message objects one by one in a loop. Most Application framework events (such as Activity life cycle calls, button clicks, etc.) are in Message, which are processed one by one in the Looper's message queue. Note that Looper exists throughout the entire life cycle of the application.
2. When you create a new handler object, it will be assigned to the Looper's message queue. The Message sent to the message queue will keep a reference to the Handler, because when the message queue processes this message, it needs to use the [Handler#handleMessage(Message)](http://developer.android.com/reference/android/os/Handler.html#handleMessage(android.os.Message) method. (That is, as long as the Message is not processed, the Handler will always be referenced in the queue)
3. In Java, non-static inner classes and anonymous classes have strong references to their outer classes, except for static inner classes.

Reference relationship

Now, let's try running the following code

 public class SampleActivity extends Activity { 
 
  private final Handler mLeakyHandler = new Handler() { @Override
 public void handleMessage(Message msg) { // ...
 }
 } @Override
  protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Post a message and delay its execution for 10 minutes.
    mLeakyHandler.postDelayed(new Runnable() { @Override
 public void run() { /* ... */ }
    }, 1000 * 60 * 10); // Go back to the previous Activity.
 finish();
 }
 }

This program is very simple. We can imagine that it should start and then shut down instantly, but is it really shut down?

Anyone with a little common sense can see that it sends a Message that will run ten minutes later, which means that the Message will be kept referenced for 10 minutes, resulting in a memory leak of at least 10 minutes.

The final correct code is as follows

 ublic class SampleActivity extends Activity { 
 
 /**
 * Instances of   static   inner classes do not hold an implicit
   * reference to their outer class.
 */
  private static class MyHandler extends Handler {
    private final WeakReference<SampleActivity> mActivity; 
 
 public MyHandler(SampleActivity activity) {
      mActivity = new WeakReference<SampleActivity>(activity);
 } @Override
 public void handleMessage(Message msg) { SampleActivity activity = mActivity.get(); if (activity != null ) { // ...
 }
 }
  } private final MyHandler mHandler = new MyHandler(this); /**
   * Instances of anonymous classes do not hold an implicit
   * reference to their outer class when they are "static" .
 */
  private static final Runnable sRunnable = new Runnable() { @Override
 public void run() { /* ... */ }
 }; @Override
  protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Post a message and delay its execution for 10 minutes.
    mHandler.postDelayed(sRunnable, 1000 * 60 * 10); // Go back to the previous Activity.
 finish();
 }
 }

in conclusion

• GC determines whether an object instance is useful based on whether the directed graph is reachable.
• If an instance is no longer needed but is still referenced, this is called a memory leak.
• Anonymous classes/non-static inner classes will keep a reference to the Activity in which they are located. When using them, please note that their life cycle cannot exceed the Activity, otherwise you should use a static inner class
• Good at manually controlling the life cycle of other classes in the life cycle of Activity (such as onPause)

Finally, let me add a few words about iOS. In the latest versions of OC and Swift, iOS has introduced a new memory management system ARC (auto reference counting). When compiling C code, the compiler automatically adds code to release memory in a timely manner.

References

http://www.jianshu.com/p/22e73e80e950

http://www.ibm.com/developerworks/cn/java/l-JavaMemoryLeak/

http://stackoverflow.com/a/70358/4016014

http://blog.csdn.net/luoshengyang/article/details/8852432

http://developer.android.com/training/articles/perf-tips.html

https://techblog.badoo.com/blog/2014/08/28/android-handler-memory-leaks/