内存泄漏
是指该被GC垃圾回收的，由于有另外一个对象仍然在引用它，导致无法回收，造成内存泄漏，过多的内存泄漏会导致OOM。
不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄漏。我们已经知道了，如果某个对象，从根节点可到达，也就是存在从根节点到该对象的引用链，那么该对象是不会被 GC 回收的。如果说这个对象已经不会再被使用到了，是无用的，我们依然持有他的引用的话，就会造成内存泄漏，例如 一个长期在后台运行的线程持有 Activity 的引用，这个时 候 Activity 执行了 onDestroy 方法，那么这个 Activity 就是从根节点可到达并且无用的对象， 这个 Activity 对象就是泄漏的对象，给这个对象分配的内存将无法被回收。如果我们的java运行很久,而这种内存泄漏不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄漏仅仅限于它本身，而不会影响整个系统的。C/C++的内存泄漏就比较糟糕了，它的内存泄漏是系统级，即使该C/C++程序退出，它泄漏的内存也无法被系统回收，永远不可用了，除非重启机器。
Android的一个应用程序的内存泄漏对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。
android常见内存泄漏
1.Handler 引起的内存泄漏
我们知道，主线程的Looper对象不断从消息队列中取出消息，然后再交给Handler处理。如果在Activity中定义Handler对象，那么Handler肯定是持有Activty的引用。而每个Message对象是持有Handler的引用的（Message对象的target属性持有Handler引用），从而导致Message间接引用到了Activity。如果在Activty destroy之后，消息队列中还有Message对象，Activty是不会被回收的。当然了，如果消息正在准备（处于延时入队期间）放入到消息队列中也是一样的。
2.单例模式引起的内存泄漏
单例模式在Android开发中会经常用到，但是如果使用不当就会导致内存泄漏。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄漏。
3.非静态内部类创建静态实例引起的内存泄漏
静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后，它所持有的引用只有等到进程结束才会释放。在Android开发中，静态持有很多时候都有可能因为其使用的生命周期不一致而导致内存泄漏，所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的引用关系，并且尽量少地使用静态持有的变量，以避免发生内存泄漏。当然，我们也可以在适当的时候讲静态量重置为null，使其不再持有引用，这样也可以避免内存泄漏。
4.非静态匿名内部类引起的内存泄漏
非静态内部类、匿名内部类 都会持有外部类的一个引用，如果有一个静态变量引用了非静态内部类或者匿名内部类，导致非静态内部类或者匿名内部类的生命周期比外部类（Activity）长，就会导致外部类在该被回收的时候，无法被回收掉，引起内存泄漏, 除非外部类被卸载（JVM自带的类加载器所加载的类，在虚拟机的生命周期中，始终不会被卸载，除非使用自定义的类加载器，感兴趣的同学可以研究一下）。
5.注册/反注册未成对使用引起的内存泄漏
在andorid开发中，我们经常会在Activity的onCreate中注册广播接受器、EventBus等，如果忘记成对的使用反注册，可能会引起内存泄漏。开发过程中应该养成良好的相关，在onCreate或onResume中注册，要记得相应的在onDestroy或onPause中反注册。
6.资源对象没有关闭引起的内存泄漏
当我们打开资源时，一般都会使用缓存。比如读写文件资源、打开数据库资源、使用Bitmap资源等等。当我们不再使用时，应该关闭它们，使得缓存内存区域及时回收。虽然有些对象，如果我们不去关闭，它自己在finalize()函数中会自行关闭。但是这得等到GC回收时才关闭，这样会导致缓存驻留一段时间。如果我们频繁的打开资源，内存泄漏带来的影响就比较明显了。
7.集合对象没有及时清理引起的内存泄漏
我们通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。如果集合是static、不断的往里面添加东西、又忘记去清理，肯定会引起内存泄漏。
内存优化
1、Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable；
2、非静态内部类、非静态匿名内部类会自动持有外部类的引用，为避免内存泄露，可以考虑把内部类声明为静态的；
3、对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext；
4、广播接收器、EventBus等的使用过程中，注册/反注册应该成对使用；
5、不再使用的资源对象Cursor、File、Bitmap等要记住正确关闭；
6、集合里面的东西、有加入就应该对应有相应的删除
如何检查和分析内存泄漏
因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。
1、MAT是一款强大的内存分析工具，功能繁多而复杂。
2.使用 LeakCanary 检测Android 的内存泄漏。
内存泄漏防不胜防，通过LeakCanary工具，我们能在开发测试阶段发现绝大多数的内存泄漏。这个工具是开源的，使用也非常方便，而且能够相对准确定位出是哪里出现内存泄漏。
