Java使用有向图机制，通过GC自动检查内存中的对象（什么时候检查由虚拟机决定），如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收；另外，如果一组对象中只包含互相的引用，而没有来自它们外部的引用（例如有两个对象A和B互相持有引用，但没有任何外部对象持有指向A或B的引用），这仍然属于不可到达，同样会被GC回收。
Android中使用Handler造成内存泄露的原因
Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用（不然你怎么可能通过Handler来操作Activity中的View？）。而Handler通常会伴随着一个耗时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后Handler把图片更新到界面。然而，如果用户在网络请求过程中关闭了Activity，正常情况下，Activity不再被使用，它就有可能在GC检查时被回收掉，但由于这时线程尚未执行完，而该线程持有Handler的引用（不然它怎么发消息给Handler？），这个Handler又持有Activity的引用，就导致该Activity无法被回收（即内存泄露），直到网络请求结束（例如图片下载完毕）。另外，如果你执行了Handler的postDelayed()方法，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，那么在你设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致你的Activity被持有引用而无法被回收。
内存泄露的危害
只有一个，那就是虚拟机占用内存过高，导致OOM（内存溢出），程序出错。对于Android应用来说，就是你的用户打开一个Activity，使用完之后关闭它，内存泄露；又打开，又关闭，又泄露；几次之后，程序占用内存超过系统限制，FC。
使用Handler导致内存泄露的解决方法
方法一：通过程序逻辑来进行保护。
1.在关闭Activity的时候停掉你的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。
2.如果你的Handler是被delay的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行了。
方法二：将Handler声明为静态类。
静态类不持有外部类的对象，所以你的Activity可以随意被回收。代码如下：
static class MyHandler extends Handler {
@Override
public void handleMessage(Message msg) {
mImageView.setImageBitmap(mBitmap);
}
}但其实没这么简单。使用了以上代码之后，你会发现，由于Handler不再持有外部类对象的引用，导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用（WeakReference）：
static class MyHandler extends Handler {
WeakReference<Activity > mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference<Activity>(activity);
}
@Override
public void handleMessage(Message msg) {
final Activity activity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}将代码改为以上形式之后，就算完成了。
具体示例代码：
/**
*
* 实现的主要功能。
*
* @version 1.0.0
* @author Abay Zhuang <br/>
* Create at 2014-7-28
*/
public class HandlerActivity2 extends Activity {
private static final int MESSAGE_1 = 1;
private static final int MESSAGE_2 = 2;
private static final int MESSAGE_3 = 3;
private final Handler mHandler = new MyHandler(this);
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler.sendMessageDelayed(Message.obtain(), 60000);
// just finish this activity
finish();
}
public void todo() {
};
private static class MyHandler extends Handler {
private final WeakReference<HandlerActivity2> mActivity;
public MyHandler(HandlerActivity2 activity) {
mActivity = new WeakReference<HandlerActivity2>(activity);
}
@Override
public void handleMessage(Message msg) {
System.out.println(msg);
if (mActivity.get() == null) {
return;
}
mActivity.get().todo();
}
}上面这样就可以了吗？
当Activity finish后 handler对象还是在Message中排队。 还是会处理消息，这些处理有必要？
正常Activitiy finish后，已经没有必要对消息处理，那需要怎么做呢？
解决方案也很简单，在Activity onStop或者onDestroy的时候，取消掉该Handler对象的Message和Runnable。
通过查看Handler的API，它有几个方法：removeCallbacks(Runnable r)和removeMessages(int what)等。代码如下：
@Override
public void onDestroy() {
// If null, all callbacks and messages will be removed.
mHandler.removeCallbacksAndMessages(null);
}延伸：什么是WeakReference？
WeakReference弱引用，与强引用（即我们常说的引用）相对，它的特点是，GC在回收时会忽略掉弱引用，即就算有弱引用指向某对象，但只要该对象没有被强引用指向（实际上多数时候还要求没有软引用，但此处软引用的概念可以忽略），该对象就会在被GC检查到时回收掉。对于上面的代码，用户在关闭Activity之后，就算后台线程还没结束，但由于仅有一条来自Handler的弱引用指向Activity，所以GC仍然会在检查的时候把Activity回收掉。这样，内存泄露的问题就不会出现了。
Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task)，并且要避免可能的内存泄露。思考下面Activity的代码，在它启动的时候开启一个线程并循环执行任务。
1 /**
2 * 一个展示线程如何在配置变化中存活下来的例子（配置变化会导致创
3 * 建线程的Activity被销毁）。代码中的Activity泄露了，因为线程被实
4 * 例为一个匿名类实例，它隐式地持有外部Activity实例，因此阻止Activity
5 * 被回收。
6 */
7 public class MainActivity extends Activity {
8
9 @Override
10 protected void onCreate(Bundle savedInstanceState) {
11 super.onCreate(savedInstanceState);
12 exampleOne();
13 }
14
15 private void exampleOne() {
16 new Thread() {
17 @Override
18 public void run() {
19 while (true) {
20 SystemClock.sleep(1000);
21 }
22 }
23 }.start();
24 }
25 }
当配置发生变化（如横竖屏切换）时，会导致整个Activity被销毁并重新创建,很容易假定Android将会为我们清理和回收跟Activity相关的内存及它运行中的线程。然而,这并非如此。这两者都会导致内存泄露而且不会被回收, 后果是性能可能显著地下降。
怎么样让一个Activity泄露
如果你读过我前一篇关于Handler和内部类的文章，那么第一种内存泄露应该很容易理解。在Java中,非静态匿名类隐式地持有他们的外部类的引用。如果你不小心，保存这个引用可能导致Activity在可以被GC回收的时候被保存下来。Activity持有一个指向它们整个View继承树和它所持有的所有资源的引用，所以如果你泄露了一个，很多内存都会连带着被泄露。
配置发生变化只加剧了这个问题，它发出一个信号让Activity销毁并重新创建。比如，基于上面的代码进行10次横竖屏变化后，我们可以看到（使用Eclipse Memory Analyzer）由于那些隐式的引用，每一个Activity对象其实都留存在内存中:
每一次配置发生变化后，Android系统都会创建一个新的Activity并让旧的Activity可以被回收。然而，隐式持有旧Activity引用的线程，阻止他们被回收。所以每次泄露一个新的Activity，都会导致所有跟他们关联的资源都没有办法被回收。
解决方法也很简单，在我们确定了问题的根源，那么只要将线程定义为private static内部类，如下所示:
1 /**
2 * 这个例子通过将线程实例声明为private static型的内部 类，从而避免导致Activity泄
3 * 露，但是这个线程依旧会跨越配置变化存活下来。DVM有一个指向所有运行中线程的
4 * 引用（无论这些线程是否 可以被垃圾回收），而线程能存活多长时间以及什么时候可
5 * 以被回收跟Activity的生命周期没有任何关系。
6 * 活动线程会一直运行下去，直到系统将你的应用程序销毁。
7 */
8 public class MainActivity extends Activity {
9
10 @Override
11 protected void onCreate(Bundle savedInstanceState) {
12 super.onCreate(savedInstanceState);
13 exampleTwo();
14 }
15
16 private void exampleTwo() {
17 new MyThread().start();
18 }
19
20 private static class MyThread extends Thread {
21 @Override
22 public void run() {
23 while (true) {
24 SystemClock.sleep(1000);
25 }
26 }
27 }
28 }
新的线程不会隐式地持有Activity的引用，并且Activity在配置发生变化后都会变得可以被回收。
怎么使一个Thread泄露
第二个问题是每当创建了一个新Activity，就会导致一个thread泄露并且不会被回收。在Java中，thread是GC Root也就是说在系统中的Dalvik Virtual Machine (DVM)保存对所有活动 中线程的强引用，这就导致了这些线程留存下来继续运行并且不会达到可以被回收的条件。因此你必须要考虑怎样停止后台线程。下面是一个例子：
1 /**
2 * 跟例子2一样，除了这次我们实现了取消线程的机制，从而保证它不会泄露。
3 * onDestroy()常常被用来在Activity推出前取消线程。
4 */
5 public class MainActivity extends Activity {
6 private MyThread mThread;
7
8 @Override
9 protected void onCreate(Bundle savedInstanceState) {
10 super.onCreate(savedInstanceState);
11 exampleThree();
12 }
13
14 private void exampleThree() {
15 mThread = new MyThread();
16 mThread.start();
17 }
18
19 /**
20 * 静态内部类不会隐式地持有他们外部类的引用，所以Activity实例不会在配置变化
21 * 中被泄露
22 */
23 private static class MyThread extends Thread {
24 private boolean mRunning = false;
25
26 @Override
27 public void run() {
28 mRunning = true;
29 while (mRunning) {
30 SystemClock.sleep(1000);
31 }
32 }
33
34 public void close() {
35 mRunning = false;
36 }
37 }
38
39 @Override
40 protected void onDestroy() {
41 super.onDestroy();
42 mThread.close();
43 }
44 }
在上面的代码中，我们在onDestroy()中关闭线程保证了线程不会意外泄露。如果你想要在配置变化的时候保存线程的状态（而不是每次都要关闭并重新创建一个新的线程）。考虑使用可留存（在配置变化中不会被销毁）、没有UI的fragment来执行长时间任务。看看我的博客,叫做《用Fragment解决屏幕旋转（状态发生变化）状态不能保持的问题》，里面有一个例子说明实现这点。API Demo中也一个全面的例子。
总结
在Android中处理Activity生命周期与长时间运行的任务的关系可能很困难并且可能导致内存泄露。下面有一些值得考虑的通用建议：
优先使用静态内部类而不是非静态的。非静态内部类的每个实例都会有一个对它外部Activity实例的引用。当Activity可以被GC回收时，存储在非静态内部类中的外部Activity引用可能导致垃圾回收失败。如果你的静态内部类需要宿主Activity的引用来执行某些东西，你要将这个引用封装在一个WeakReference中，避免意外导致Activity泄露。
不要假定Java最后总会为你清理运行中的线程。在上面的例子中，很容易错误地认为用户退出Activity后，Activity就会被回收，任何跟这个Activity关联的线程也都将一并被回收。事实上不是这样的。Java线程会继续运行下去，直到他们被显式地关闭或者整个process被Android系统杀掉。因此，一定要记得记得为后台线程实现对应的取消策略，并且在Activity生命周期事件发生的时候使用合理的措施。
考虑你是否真的应该使用线程。Android Framework提供了很多旨在为开发者简化后台线程开发的类。比如，考虑使用Loader而不是线程当你需要配合Activity生命周期做一些短时间的异步后台任务查询类任务。考虑使用使用Service，然后向使用BrocastReceiver向UI反馈进度、结果。最后，记住本篇文章中一切关于线程的讨论也适用于AsyncTask（因为Asynctask类使用ExecutorService来执行它的任务）。然而，鉴于AsyncTask只应该用于短时间的操作（最多几秒钟，参照文档），它倒不至于会导致像Activity或线程泄露那么大的问题。
这篇文章中的源代码都可以从github下载。文章中的示例程序可以从Google play下载。