虽然VM接管了内存分配和回收，但是人类在解决问题的同时也会重新创造出一些新的问题，所以问题永远都解决不了，就产生各种稀奇古怪的就业机会了（跑题跑不停）。
无论各种VM用什么算法管理内存， 造成内存泄漏的主要原因都是VM认为那些其实可以回收的内存没有被回收，比如各种数据集合中的垃圾数据，各种类静态成员占用永远不会被使用的对象。
1.数据放在各种数据集合中，但是这些数据缺不在使用，这种状况是泄漏的一大原因。
2.设置类的静态成员，然而确不会再使用了。
用leakcanary 检查对象泄漏
leakcanary工作机制:
leakcanary 分成两部分，一部分是带检测程序，在这部分里面嵌入监控对象refWatcher.watch(obj);这部分会产生一个hprof文件。
在android4.0之后，framework有ActivityLifecycleCallbacks机制，在Application的某个地方注册一个ActivityLifecycleCallbacks，然后在Activity的所谓几大生命周期都会回调这个对象的相关函数。如果不是android4.0之后，还是要手动refWatcher.watch(activity)添加监控
另外一部分是在另外的一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用HAHA 解析hprof这个文件。
集合中数据泄漏:
public class LeakActivity extends Activity {
static LinkedList list=new LinkedList<>();}然后再某个地方将数据放入到list中，back回来，当产生hprof文件的时候，就会有泄漏信息可以查询到。同样的方式可以导致activity对象不能回收，产生所谓的泄漏。
不过个人觉得leakcanary并不是一个理想的内存检测工具，它需要在代码中维护监测对象，对实际代码影响太大，维护很麻烦。
看到许多介绍memory monitor这个工具的，可惜我的电脑太差，跑不起android studio ,这个工具似乎没有像leakcanary 这般伤害代码的，可是现在我还不知到这如何使个工具脱离android stuido 运行。 不过看介绍这个工具似乎不能确定内存泄漏点（那些对象没有被回收）。
allocation tracker 这个工具能够观察到所有分配过对象的信息（对象大小，在哪个函数、那个线程分配的），但是不能观察到到底是哪个到目前是没有被回收的。
有人说heap view是一个好工具，这个工具只能观察到某段时间内，内存整体情况，这是个用来把握App整体内存使用的工具，heap view 其实和memory monitor是同一类工具，只不过memory monitor 用图形表达出来了。
查找了许多介绍，在内存泄漏方面还是leakcanary 和allocation tracker配合着使用最好，leakcanary 能够确定对象是否还存活，allocation tracker确定对象分配位置。
