我们常说的垃圾回收机制中会提到GC Roots这个词，也就是Java虚拟机中所有引用的根对象。我们都知道，垃圾回收器不会回收GC Roots以及那些被它们间接引用的对象。但是，对于GC Roots的定义却不是很清楚。它们都包括哪些对象呢？
经过查阅，了解JVM中GC Roots的大致分类,然后用自己的语言解释一下：
- Class 由System Class Loader/Boot Class Loader加载的类对象，这些对象不会被回收。需要注意的是其它的Class Loader实例加载的类对象不一定是GC root，除非这个类对象恰好是其它形式的GC root；
- Thread 线程，激活状态的线程；
- Stack Local 栈中的对象。每个线程都会分配一个栈，栈中的局部变量或者参数都是GC root，因为它们的引用随时可能被用到；
- JNI Local JNI中的局部变量和参数引用的对象；可能在JNI中定义的，也可能在虚拟机中定义
- JNI Global JNI中的全局变量引用的对象；同上
- Monitor Used 用于保证同步的对象，例如wait()，notify()中使用的对象、锁等。
- Held by JVM JVM持有的对象。JVM为了特殊用途保留的对象，它与JVM的具体实现有关。比如有System Class Loader, 一些Exceptions对象，和一些其它的Class Loader。对于这些类，JVM也没有过多的信息。
这里的参考资料有：
Yourkit
What are the roots?
了解过GC Roots之后，可以帮助我们定位内存泄漏。因为被GC roots直接或者间接引用的对象都不会被回收，所以我们要确保我们用的局部对象远离这些危险的类。下面根据GC root的分类分析一下几种内存泄漏的原因。
1. Class
应用运行过程中非动态加载的类都是通过dalvik.system.PathClassLoader的实例加载到虚拟机中的。这些类对象是GC root的一种，它们带来的静态变量永远不会被垃圾回收。因此，静态变量持有的“过期”对象将会造成内存泄漏。下面举几个例子。
单例：
public class AccountMananger {
private Context mContext;
private static AccountMananger instance = null;
public static AccountMananger getInstance(Context context) {
if (instance == null) {
synchronized (AccountManager.class) {
if (instance == null) {
instance = new AccountMananger(context);
}
}
}
return instance;
}
private AccountMananger(Context context) {
mContext = context;
}
}
上面这段代码就很危险，因为单例对象持有一个 Context。它可能是一个 Activity 也可能是一个 Service。Activity 对象包括大量的布局和资源文件， 一旦它被该单例持有，它所持有的资源在应用结束前都不会被释放。修改的方法很简单：
private AccountMananger(Context context) {
if (context != null) {
mContext = context.getApplicationContext();
}
}
传进来的Context用ApplicationContext就可以了。ApplicationContext对象在应用整个生命周期中有且只有一个对象。持有它的引用不会占用更多资源。
注册/反注册
public class AccountMananger extends Observable{
//单例的内容
}
public class MainActivity extends AppCompatActivity implements Observer {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
AccountMananger.getInstance(this).addObserver(this);
}
@Override
protected void onDestroy() {
super.onDestroy();
}
...
@Override
public void update(Observable observable, Object data) {
//todo Your logic
}
}
上面的代码也会导致内存泄漏，因为注册了监听模式却没有反注册。注册过的监听者都会间接的被单例对象持有，他们都不会被GC回收。修改方法：
@Override
protected void onDestroy() {
super.onDestroy();
AccountMananger.getInstance(this).deleteObserver(this);
}
所有的注册型的用法都要有反注册。编码的时候养成好习惯，像Activity,Fragment等类在生命周期对等的回调方法中，最好成对的添加代码。例如在onCreate()方法注册监听之后，马上在onDestroy()方法中反注册。
非静态内部类/匿名类 + 静态变量
public class MainActivity extends AppCompatActivity {
private static MyHandler handler = new MyHandler();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
public class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
}
}
非静态内部类会持有外部类的引用（所以它才可以直接访问外部类的成员变量）。上面代码中的静态handler变量间接持有了MainActivity对象。这样就造成了内存泄漏。
解决的方法就是将内部类中对外部类的调用改成public方法，然后将Handler改成静态内部类或者外部一个类。或者将将它放到弱引用中。
2. Thread
Runnable/AsyncTask
激活状态的线程是不会被GC回收的，所以它持有的对象也不会被回收。看下面的代码：
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
AsyncTasks asyncWork = new AsyncTasks(this);
ExecutorService defaultExecutor = Executors.newCachedThreadPool();
defaultExecutor.execute(asyncWork);
}
public static class AsyncTasks implements Runnable {
private Context context;
public AsyncTasks(Context context) {
this.context = context;
}
@Override
public void run() {
while (true) ;
//正常情况下，线程执行时间不会无限，但可能有5分钟，10分钟
}
}
}
线程中持有一个Activity对象，在这个线程活跃的时间内这个Activity对象都不会被释放。因此，其它线程中尽量不要持有Activity,Service等大对象。如果需要用到Context，尽量使用ApplicationContext。
隐藏的线程
比如说在一个Activity中实现一个电子钟：
public class MainActivity extends AppCompatActivity {
private TextView tvClock = null;
Timer clock = null;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
tvClock=findViewById(R.id.tv_clock);
TimerTask clockTask = new TimerTask() {
@Override
public void run() {
tvClock.setText(updateClockText());
}
};
clock = new Timer();
clock.schedule(clockTask, 0, 1000);
}
@Override
protected void onDestroy() {
super.onDestroy();
}
}
Timer的部分源码如下：
public class Timer {
private static final class TimerImpl extends Thread {
....
/**
* This method will be launched on separate thread for each Timer
* object.
*/
@Override
public void run() {
while (true) {
TimerTask task;
...
}
}
}
每一个Timer类都运行在一个独立的线程中。例子中我们的Timer对象的线程被设置为1000ms触发一次操作，永不结束。需要注意的是当前的引用关系Timer->TimerTask->Activity。所以当我们的Activity结束之后，还会被GC root间接持有。这个Activity每次被打开都会多一个对象在进程中，并且永远不会被回收。
解决办法就是在Activity的onDestroy方法中将Timer取消掉。
3. JNI Local & JNI Global
这类对象一般发生在参与Jni交互的类中。
比如说很多close()相关的类，InputStream,OutputStream,Cursor,SqliteDatabase等。这些对象不止被Java代码中的引用持有，也会被虚拟机中的底层代码持有。在将持有它们的引用设置为null之前，要先将他们close()掉。
还有一个特殊的类是Bitmap。在Android系统3.0之前，它的内存一部分在虚拟机中，一部分在虚拟机外。因此它的一部分内存不参与垃圾回收，需要我们主动调用recycler()才能回收。
动态链接库中的内存是用C/C++语言申请的，这些内存不受虚拟机的管辖。所以，so库中的数组，类等都有可能发生内存泄漏，使用的时候务必小心。
总结：
- 使用静态变量的时候要小心，尤其要注意
Activity/Service等大对象的传值。在单例模式中能用ApplicationContext的都用ApplicationContext，或者把聚合关系改成依赖关系，不在单例对象中持有Context引用； - 养成良好的代码习惯。注册/反注册要成对出现，
Activity和Service对象中避免使用非静态内部类/匿名内部类，除非十分清楚引用关系； - 使用多线程的时候留意线程存活时间。尽量将聚合关系改成依赖关系，减少线程对象持有大对象的时间；
- 在使用
xxxStream,SqlLiteDatabase,Cursor类的时候要注意释放资源。使用Timer,TimerTask的时候要记得取消任务。Bitmap在使用结束后要记得recycler()。
参考文章：
Android 内存泄漏总结
Android内存泄漏分析及调试