个人简介：荡不羁，一生所爱。Java耕耘者（微信公众号ID：Java耕耘者），欢迎关注。可获得2000G详细的2020面试题的资料
引用
Object o = new Object();
这个o，我们可以称之为对象引用，而new Object()我们可以称之为在内存中产生了一个对象实例。
当写下 o=null时，只是表示o不再指向堆中object的对象实例，不代表这个对象实例不存在了。
强引用
一直活着：类似“Object obj=new Object（）”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象实例。
软引用
有一次活的机会：软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象实例列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。
弱引用
回收就会死亡：被弱引用关联的对象实例只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象实例。在JDK 1.2之后，提供了WeakReference类来实现弱引用。
虚引用
也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象实例是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象实例被收集器回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。
上图中的Map是ThreadLocalMap。ThreadLocalMap关键属性：
static class ThreadLocalMap { /** * 这里entry继承了WeakReference<ThreadLocal<?>>。 * entry也是Key-Value的数据格式。key是ThreadLocal对象的弱引用。value是实际存储的值 */ static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } } /** * The initial capacity -- MUST be a power of two. */ private static final int INITIAL_CAPACITY = 16; /** * 可能会有多个threadlocal对象，存储在table数组中。 * */ private Entry[] table; /** * The number of entries in the table. */ private int size = 0; /** * The next size value at which to resize. */ private int threshold; // Default to 0}
ThreadLocalMap 实际存储在Thread对象中。每个Thread 维护一个 ThreadLocalMap 映射表，这个映射表的 key 是 ThreadLocal实例本身，value 是真正需要存储的 Object。
public class Thread implements Runnable { ThreadLocal.ThreadLocalMap threadLocals = null;}
通过set方法，来简单看一下存储数据的过程。
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { map.set(this, value); } else { createMap(t, value); } }ThreadLocalMap getMap(Thread t) { return t.threadLocals;//这个threadLocals是Thread对象中的属性 }
ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从 ThreadLocalMap 获取 value。值得注意的是图中的虚线，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。
ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。
总的来说就是，ThreadLocal里面使用了一个存在弱引用的map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例。这个Map的确使用了弱引用，不过弱引用只是针对key。每个key都弱引用指向threadlocal。当把threadlocal实例置为null以后，没有任何强引用指向threadlocal实例，所以threadlocal将会被gc回收。
但是，我们的value却不能回收，而这块value永远不会被访问到了，所以存在着内存泄露。因为存在一条从current thread连接过来的强引用。只有当前thread结束以后，current thread就不会存在栈中，强引用断开，Current Thread、Map value将全部被GC回收。最好的做法是将调用threadlocal的remove方法，这也是等会后边要说的。
其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。这一点在上一节中也讲到过！
但是这些被动的预防措施并不能保证不会内存泄漏：
（1）使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致内存泄漏。（2）分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏，因为这块内存一直存在。
为什么使用弱引用，OOM是否是弱引用的锅？
1、从表面上看内存泄漏的根源在于使用了弱引用。网上的文章大多着重分析ThreadLocal使用了弱引用会导致内存泄漏，但是另一个问题也同样值得思考：为什么使用弱引用而不是强引用？
我们先来看看官方文档的说法：
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.为了应对非常大和长时间的用途，哈希表使用弱引用的 key。
下面我们分两种情况讨论：
（1）key 使用强引用：引用的ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。
（2）key 使用弱引用：引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。value在下一次ThreadLocalMap调用set、get、remove的时候会被清除。
比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set、get、remove的时候会被清除。
因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除对应key就会导致内存泄漏，而不是因为弱引用。
ThreadLocal 最佳实践
1、综合上面的分析，我们可以理解ThreadLocal内存泄漏的前因后果，那么怎么避免内存泄漏呢？
答案就是：每次使用完ThreadLocal，都调用它的remove()方法，清除数据。
在使用线程池的情况下，没有及时清理ThreadLocal，不仅是内存泄漏的问题，更严重的是可能导致业务逻辑出现问题。所以，使用ThreadLocal就跟加锁完要解锁一样，用完就清理。
注意：
并不是所有使用ThreadLocal的地方，都在最后remove（），他们的生命周期可能是需要和项目的生存周期一样长的，所以要进行恰当的选择，以免出现业务逻辑错误！但首先应该保证的是ThreadLocal中保存的数据大小不是很大！
ThreadLocal内存泄漏代码展示
不使用ThreadLocal
下面这段程序创建了一个有5个线程的线程池。每个线程致性都申请5M大小的堆空间。
public class MyThreadLocalOOM1 { public static final Integer SIZE = 500; static ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 5, 1, TimeUnit.MINUTES, new LinkedBlockingDeque<>()); static class LocalVariable {//总共有5M private byte[] locla = new byte[1024 * 1024 * 5]; } public static void main(String[] args) { try { for (int i = 0; i < SIZE; i++) { executor.execute(() -> { new LocalVariable(); System.out.println("开始执行"); }); Thread.sleep(100); } } catch (InterruptedException e) { e.printStackTrace(); } }}
使用JDK自带的VisualVM来观察对内存占用情况，下图中锯齿状的蓝色区域是堆已经使用的空间大小，可以看到在0-70内，这是因为每个线程都会申请5M空间，过一小段时间后，就会触发一次youngGC, 内存就会释放。在19：30：36处我手动触发了一次GC ,可以看到堆空间基本都释放。说明LocalVariable全都释放，未发生内存泄漏。
使用ThreadLocal，但不remove
public class MyThreadLocalOOM2 { public static final Integer SIZE = 500; static ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 5, 1, TimeUnit.MINUTES, new LinkedBlockingDeque<>()); static class LocalVariable {//总共有5M private byte[] locla = new byte[1024 * 1024 * 5]; } static ThreadLocal<LocalVariable> local = new ThreadLocal<>(); public static void main(String[] args) { try { for (int i = 0; i < SIZE; i++) { executor.execute(() -> { local.set(new LocalVariable()); System.out.println("开始执行"); }); Thread.sleep(100); } local = null;//这里设置为null，依旧会造成内存泄漏 } catch (InterruptedException e) { e.printStackTrace(); } }}
上面代码中定义了static的ThreadLocal变量local, 但是当for循环致性完毕后，又将local设置为null。普通对象，此时就没有强引用了，当GC时就会被回收掉。但是通过下面图可以看到，即使for循环结束后手动触发了GC，堆内存空间依旧占用约25MB空间，正好是线程池中5个线程的LocalVariable对象的空间和。所以发生了内存泄漏。发生内存泄漏的原因见 ThreadLocal内存泄露原因分析[1]
使用Thread Local，且remove
public class MyThreadLocalOOM3 { public static final Integer SIZE = 500; static ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 5, 1, TimeUnit.MINUTES, new LinkedBlockingDeque<>()); static class LocalVariable {//总共有5M private byte[] locla = new byte[1024 * 1024 * 5]; } final static ThreadLocal<LocalVariable> local = new ThreadLocal<>(); public static void main(String[] args) { try { for (int i = 0; i < SIZE; i++) { executor.execute(() -> { local.set(new LocalVariable()); System.out.println("开始执行"); local.remove(); }); Thread.sleep(100); } } catch (InterruptedException e) { e.printStackTrace(); } }}
上面代码中，线程致性完成后，都调用了local.remove()来将threadLocal内的对象删除。下图中可以看到在手动触发GC后，对内存全部释放，未发生内存泄漏。
单线程演示内存泄漏
public class MyThreadLocalOOM4 { public static final Integer SIZE = 500; static class LocalVariable {//总共有50M private byte[] locla = new byte[1024 * 1024 * 50]; } static ThreadLocal<LocalVariable> local = new ThreadLocal<>(); static LocalVariable localVariable; public static void main(String[] args) throws InterruptedException { try { TimeUnit.SECONDS.sleep(2); localVariable = new LocalVariable(); local.set(new LocalVariable()); System.out.println("开始执行"); Thread.sleep(100); local = null; localVariable = null; } catch (InterruptedException e) { e.printStackTrace(); } while (true) { TimeUnit.SECONDS.sleep(1); } }}
从结果中可以看到，localVariable的50MB空间释放了，但是ThreadLocal中存放的50MB空间没有释放。
