前言
LeakCanary的源码分析，请参考以下文章，他们写的比我好，我这个只讲WeakReference与LeakCanary的关系
《java 源码系列 - 带你读懂 Reference 和 ReferenceQueue》
《LeakCanary原理分析》
疑问
对于LeakCanary的源码，或多或少的还是了解一点，但这次本着刨根问底的劲儿，就一行一行的捋捋，结果发现，下图中内存泄漏的判断逻辑，我咋个都想不通为什么？
1区代码执行gc过后,执行3区代码,如果弱引用的对象还可达,说明这个对象没有被回收。但是，对象没有被回收，为什么又从Set中移除这个key。再执行2区代码,无论如何Set中都不会再有这个key,结果都为false了还分分析个锤子....
我在这儿看了几个小时，最后才发现，我完全理解反了，因为我没有弄明白：
1：如果一个对象只被一个弱引用所关联，那么在gc的时候一定会被回收
2：构建一个弱引用（WeakReference）需要被引用的对象和一个弱引用队列（ReferenceQueue）
比如：
ReferenceQueue此时弱引用队列rq和弱引用wr只是产生了关联，wr.queue= rq ，没做任何操作，那这个wr是什么时候添加到rq中去的？为什么添加到rq中去了反而还要remove，remove了却又要判断contains？
原来这一切都是jvm gc和引用相关的知识，我们把上面的代码改一下：
ReferenceQueue这个结果肯定为false，因为堆中开辟内存存储new String(“3”)这个对象,栈中的引用String s 指向了堆中的对象new String(“3”)，所以对象new String(“3”)就不仅仅只被wr这个弱引用所引用，还有String s这个强引用。如果一个对象只被一个弱引用所关联，那么在gc的时候一定会被回收，反过来说，如果一个对象不仅被弱引用引用，还被强引用引用，那么gc肯定是无效的，除非你把强引用置空，s=null，取消s对对象new String("3")**的引用，那么gc的时候才wr才会被回收。
WeakReference有四个状态：
Active:一般来说，内存一开始被分配的状态都是 Active，
Pending: 大概是指快要被放进队列的对象，也就是马上要回收的对象，
Enqueued: 就是对象的内存已经被回收了，把这个对象放入到一个队列中，方便以后我们查询某个对象是否被回收，
Inactive: 就是最终的状态，不能再变为其它状态
注意第三个状态Enqueued，当这个弱引用被回收后，gc会把这个弱引用所指向的对象加入到引用队列中，也就是前面的rq，
所以有了LeakCanary的源码：
private boolean gone(KeyedWeakReference reference) {
return !retainedKeys.contains(reference.key);
}
private void removeWeaklyReachableReferences() {
// WeakReferences are enqueued as soon as the object to which they point to becomes weakly
// reachable. This is before finalization or garbage collection has actually happened.
KeyedWeakReference ref;
while ((ref = (KeyedWeakReference) queue.poll()) != null) {
retainedKeys.remove(ref.key);
}
}
当removeWeaklyReachableReferences()中while执行，ref如果不为空，说明gc已经把这个弱引用已经回收了（因为回收后才会被加到引用队列中），如果没有加进来，就说明ref没有被回收，ref是弱引用，他没被回收，说明ref所引用的对象，不仅被ref一个弱引用所引用，还有其他强引用所引用，这就是内存泄漏！
当然，queue中不为空，则retainedKeys.remove(ref.key);移除这个key，在判断boolean gone(KeyedWeakReference reference)时，已经移除为fasle，说明已经被回收了。
抓住一个重点：
queue中有这个引用，说明已经被回收了，回收后retainedKeys中就不会有这个key，如果把key和这个引用抽象的看为同一个东西，就是，queue有retainedKeys无，不泄露，queue无retainedKeys有，泄漏！