Understand why Java memory leaks

LeakCanary’s memory leak prompt usually contains three parts: The first part (the sInstance variable of the LeakSingle class) references the second part (the mContext variable of the LeakSingle class), causing the third part (instance of the MainActivity class) to leak.

Case 1 (Memory leak caused by static members)

public class App extends Application { private RefWatcher refWatcher; @Override public void onCreate() { super.onCreate(); refWatcher = LeakCanary.install(this); } public static RefWatcher getRefWatcher(Context context) { App application = (App) context.getApplicationContext(); return application.refWatcher; }}Copy the code

The inner class is static (gC-root, which will always be attached to the external class instance). Static and Application lifetime will result in holding the external class reference (the inner class implicitly has a member variable $0), even if the external class is null.

OutterClass

public class OutterClass { private String name; class Inner{ public void list(){ System.out.println("outter name is " + name); }}}Copy the code

TestActivity

Public Class TestActivity extends Activity {private static OutterClass.Inner Class; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); OutterClass outterClass = new OutterClass(); innerClass = outterClass.new Inner(); RefWatcher refWatcher = App.getRefWatcher(this); refWatcher.watch(outterClass); // Monitor object outterClass = null; }Copy the code

Case 2 (Memory leak caused by singleton pattern)

DownloadManager

public class DownloadManager { private static DownloadManager instance; private Task task ; public static DownloadManager getInstance(){ if (instance == null) { instance = new DownloadManager(); } return instance; } public Task newTask(){ this.task = new Task(); return task; }}Copy the code

Task

public class Task { private Call call; public Call newCall(){ this.call = new Call(); return call; }}Copy the code

Call

public class Call { public void execute(){ System.out.println("=========> execute call"); }}Copy the code

TestActivity

public class TestActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); RefWatcher refWatcher = App.getRefWatcher(this); Task task = DownloadManager.getInstance().newTask(); Call call = task.newCall(); call.execute(); refWatcher.watch(call); // Call = null; DownloadManager is a static singleton that references task, which references Call. The task cannot be recycled even if call is empty. To avoid memory leaks, disconnect GC_ROOT. }}Copy the code

Some logs are as follows: The current GC_ROOT is an instance of DownloadManager.

In com. Leakcanary. Demo: 1.0:1. * com In less. The demo. The Call from the leaked: * GC ROOT static com.less.demo.DownloadManager.instance * references com.less.demo.DownloadManager.task * references com.less.demo.Task.call * leaks com.less.demo.Call instanceCopy the code

Here are two more examples to illustrate the memory leakage problem caused by the above two methods.

Case 3 (Memory leak due to static variables)

public class TestActivity extends Activity { private static Context sContext; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); sContext = this; RefWatcher refWatcher = App.getRefWatcher(this); refWatcher.watch(this); // Monitor object}Copy the code

The following logs are displayed:

In com. Leakcanary. Demo: 1.0:1. Com. Less. The demo. The TestActivity has leaked. GC ROOT static com.less.demo.TestActivity.sContext leaks com.less.demo.TestActivity instanceCopy the code

It can be analyzed from this log that: When you declare static, the sContext lifetime is as long as the Application lifetime. The Activity exits the desktop, the Application still exists ->sContext still exists, When the GC tries to reclaim the Activity, it finds that the Activity is still connected to the sContext(gC-root), causing it to fail to reclaim and leak memory.

The above code is modified as follows.

public class TestActivity extends Activity { private static View sView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); sView = new View(this); RefWatcher refWatcher = App.getRefWatcher(this); refWatcher.watch(this); }}Copy the code

The log is as follows:

In com. Leakcanary. Demo: 1.0:1. Com. Less. The demo. The TestActivity has leaked. GC ROOT static com.less.demo.TestActivity.sView references android.view.View.mContext leaks com.less.demo.TestActivity instanceCopy the code

Case 4 (memory leak caused by singleton pattern) DownloadManager

public class DownloadManager { private static DownloadManager instance; private List mListeners = new ArrayList<>(); public interface DownloadListener { void done(); } public static DownloadManager getInstance(){ if (instance == null) { instance = new DownloadManager(); } return instance; } public void register(DownloadListener downloadListener){ if (! mListeners.contains(downloadListener)) { mListeners.add(downloadListener); } } public void unregister(DownloadListener downloadListener){ if (mListeners.contains(downloadListener)) { mListeners.remove(downloadListener); }}}Copy the code

TestActivity

public class DownloadManager { private static DownloadManager instance; private List mListeners = new ArrayList<>(); public interface DownloadListener { void done(); } public static DownloadManager getInstance(){ if (instance == null) { instance = new DownloadManager(); } return instance; } public void register(DownloadListener downloadListener){ if (! mListeners.contains(downloadListener)) { mListeners.add(downloadListener); } } public void unregister(DownloadListener downloadListener){ if (mListeners.contains(downloadListener)) { mListeners.remove(downloadListener); } } } TestActivity public class TestActivity extends Activity implements DownloadManager.DownloadListener{ @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); DownloadManager.getInstance().register(this); RefWatcher refWatcher = App.getRefWatcher(this); refWatcher.watch(this); } @Override protected void onDestroy() { super.onDestroy(); / / forget to unregister. / / DownloadManager getInstance (). The unregister (this); } @Override public void done() { System.out.println("done!" ); }}Copy the code

In com. Leakcanary. Demo: 1.0:1. * com In less. The demo. The TestActivity has leaked. * GC ROOT static com.less.demo.DownloadManager.instance * references com.less.demo.DownloadManager.mListeners * references java.util.ArrayList.array * references array java.lang.Object[].[0] * leaks com.less.demo.TestActivity instanceCopy the code

Memory leaks caused by handlers are something most of us have probably done. Note the comments in the following code that a non-static inner class holds an external class reference, but holding does not necessarily mean leaking, but rather depending on who lives longer in gc. After testing (1) there is no memory leak.

Message. target = Handler; message.target = Handler; handler.post(message); This in turn pushes the message into a MessageQueue, which polls messages in a Looper thread, and sometimes the message is still old enough to be reused. If there are still messages unprocessed or being processed when the Activity exits, a memory leak will occur because Message references handler, which in turn references the Activity.

public class TestActivity extends Activity { private Handler handler = new Handler() { @Override public void handleMessage(Message msg) { super.handleMessage(msg); System.out.println("===== handle message ===="); }}; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); / / (1) does not lead to memory leaks handler. SendEmptyMessageDelayed (x123 0, 0); // (2) will result in a memory leak, non-static inner classes (including anonymous inner classes such as this Handler anonymous inner class) will reference the outer class object this (such as Activity) // When it uses postDelayed, If the Activity finishes and the handler still references the Activity, it will leak memory because the handler will continue to be held by main Looper for some time. Still exists in reference. Handler. SendEmptyMessageDelayed (0 x123, 12000); } @Override protected void onDestroy() { super.onDestroy(); RefWatcher refWatcher = App.getRefWatcher(this); refWatcher.watch(this); }}Copy the code

com.less.demo.TestActivity has leaked:
* GC ROOT android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mH
* references com.android.internal.view.IInputConnectionWrapper$MyHandler.mQueue
* references android.os.MessageQueue.mMessages
* references android.os.Message.target , matching exclusion field android.os.Message#target
* references com.less.demo.TestActivity$1.this$0 (anonymous subclass of android.os.Handler)
* leaks com.less.demo.TestActivity instanceCopy the code

Knowing how this works, you can avoid memory leaks even if you write code that is prone to memory leaks. The above code in onDestroy () function call mHandler. RemoveCallbacksAndMessages (null); Remove all messages and all runnables from the message queue when the Activity exits.

1. If some singletons need to use a Context object, it is recommended to use the Application Context rather than the Activity Context. Otherwise, memory leaks may occur. The life cycle of a singleton is the same as that of an Application, so that the Application and the singleton are destroyed together.

2. Static inner classes are preferred over non-static ones, because non-static inner classes holding external class references can cause garbage collection to fail. If your static inner class needs a reference to the host Activity to perform something, you’ll want to wrap the reference in a WeakReference to avoid accidental leaks of the Activity, and the object associated with the WeakReference will only survive until the next garbage collection occurs. When the garbage collector works, objects associated only with weak references are reclaimed, regardless of whether or not there is currently enough memory, indicating that the object itself is no longer useful.

public class TestActivity extends Activity { private MyHandler myHandler = new MyHandler(this); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_test); } static class MyHandler extends Handler { private WeakReference mWeakReference; public MyHandler(Activity activity){ mWeakReference = new WeakReference(activity); } @Override public void handleMessage(Message msg) { super.handleMessage(msg); Toast.makeText(mWeakReference.get(), "xxxx", Toast.LENGTH_LONG).show(); Log.d("xx", mWeakReference.get().getPackageName()); } } @Override protected void onDestroy() { super.onDestroy(); RefWatcher refWatcher = App.getRefWatcher(this); refWatcher.watch(this); }}Copy the code