ThreadLocal
Java当中的四种引用
强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4 种，这 4 种引用的强度依次减弱。
一，强引用
Java中默认声明的就是强引用，比如：
Object obj = new Object(); //只要obj还指向Object对象，Object对象就不会被回收
obj = null; //手动置null
只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足时，JVM也会直接抛出OutOfMemoryError(OOM)，不会去回收。如果想中断强引用与对象之间的联系，可以显示的将强引用赋值为null,JVM就可以适时的回收对象
二，软引用:java.lang.ref.SoftReference
软引用是用来描述一些非必需但仍有用的对象。在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。这种特性常常被用来实现缓存技术，比如网页缓存，图片缓存等。用java.lang.ref.SoftReference类来表示软引用。
下面以一个例子来进一步说明强引用和软引用的区别：
在运行下面的Java代码之前，需要先配置参数 -Xms2M -Xmx3M，将 JVM 的初始内存设为2M，最大可用内存为 3M。
首先先来测试一下强引用，在限制了 JVM 内存的前提下，下面的代码运行正常
public class TestOOM { public static void main(String[] args) { testStrongReference(); } private static void testStrongReference() { // 当 new byte为 1M 时，程序运行正常 byte[] buff = new byte[1024 * 1024 * 1]; } }
但是如果我们将
byte[] buff = new byte[1024 * 1024 * 1];
替换为创建一个大小为 2M 的字节数组
byte[] buff = new byte[1024 * 1024 * 2];
则内存不够使用，程序直接报错，强引用并不会被回收
接着来看一下软引用会有什么不一样，在下面的示例中连续创建了 10 个大小为 1M 的字节数组，并赋值给了软引用，然后循环遍历将这些对象打印出来。
public class TestOOM { private static List<Object> list = new ArrayList<>(); public static void main(String[] args) { testSoftReference(); } private static void testSoftReference() { for (int i = 0; i < 10; i++) { byte[] buff = new byte[1024 * 1024]; SoftReference<byte[]> sr = new SoftReference<>(buff); list.add(sr); } System.gc(); //主动通知垃圾回收 for(int i=0; i < list.size(); i++){ Object obj = ((SoftReference) list.get(i)).get(); System.out.println(obj); } } }
打印结果：
我们发现无论循环创建多少个软引用对象，打印结果总是只有最后一个对象被保留，其他的obj全都被置空回收了。
这里就说明了在内存不足的情况下，软引用将会被自动回收。
值得注意的一点 , 即使有 byte[] buff 引用指向对象, 且 buff 是一个strong reference, 但是 SoftReference sr 指向的对象仍然被回收了，这是因为Java的编译器发现了在之后的代码中, buff 已经没有被使用了, 所以自动进行了优化。
如果我们将上面示例稍微修改一下：
private static void testSoftReference() { byte[] buff = null; for (int i = 0; i < 10; i++) { buff = new byte[1024 * 1024]; SoftReference<byte[]> sr = new SoftReference<>(buff); list.add(sr); } System.gc(); //主动通知垃圾回收 for(int i=0; i < list.size(); i++){ Object obj = ((SoftReference) list.get(i)).get(); System.out.println(obj); } System.out.println("buff: " + buff.toString()); }
则 buff 会因为强引用的存在，而无法被垃圾回收，从而抛出OOM的错误。
如果一个对象惟一剩下的引用是软引用，那么该对象是软可及的（softly reachable）。垃圾收集器并不像其收集弱可及的对象一样尽量地收集软可及的对象，相反，它只在真正 “需要” 内存时才收集软可及的对象。
三，弱引用: java.lang.ref.WeakReference
弱引用的引用强度比软引用要更弱一些，无论内存是否足够，只要 JVM 开始进行垃圾回收，那些被弱引用关联的对象都会被回收。用 java.lang.ref.WeakReference 来表示弱引用。
我们以与软引用同样的方式来测试一下弱引用：
private static void testWeakReference() { for (int i = 0; i < 10; i++) { byte[] buff = new byte[1024 * 1024]; WeakReference<byte[]> sr = new WeakReference<>(buff); list.add(sr); } System.gc(); //主动通知垃圾回收 for(int i=0; i < list.size(); i++){ Object obj = ((WeakReference) list.get(i)).get(); System.out.println(obj); } }
打印结果：
可以发现所有被弱引用关联的对象都被垃圾回收了。
四，虚引用:PhantomReference
虚引用是最弱的一种引用关系，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，它随时可能会被回收，用 PhantomReference 类来表示，通过查看这个类的源码，发现它只有一个构造函数和一个 get() 方法，而且它的 get() 方法仅仅是返回一个null，也就是说将永远无法通过虚引用来获取对象，虚引用必须要和 ReferenceQueue 引用队列一起使用。
public class PhantomReference<T> extends Reference<T> { /** * Returns this reference object's referent. Because the referent of a * phantom reference is always inaccessible, this method always returns * <code>null</code>. * * @return <code>null</code> */ public T get() { return null; } public PhantomReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); } }
那么传入它的构造方法中的 ReferenceQueue 又是如何使用的呢？
引用队列（ReferenceQueue）
引用队列可以与软引用、弱引用以及虚引用一起配合使用，当垃圾回收器准备回收一个对象时，如果发现它还有引用，那么就会在回收对象之前，把这个引用加入到与之关联的引用队列中去。程序可以通过判断引用队列中是否已经加入了引用，来判断被引用的对象是否将要被垃圾回收，这样就可以在对象被回收之前采取一些必要的措施。
与软引用、弱引用不同，虚引用必须和引用队列一起使用。
ThreadLocal
从名字我们就可以看到ThreadLocal 叫做本地线程变量，意思是说，ThreadLocal 中填充的的是当前线程的变量，该变量对其他线程而言是封闭且隔离的，ThreadLocal 为变量在每个线程中创建了一个副本，这样每个线程都可以访问自己内部的副本变量。
从字面意思很容易理解，但是实际角度就没那么容易了，作为一个面试常问的点，使用场景也是很丰富。
- 1、在进行对象跨层传递的时候，使用ThreadLocal可以避免多次传递，打破层次间的约束。
- 2、线程间数据隔离
- 3、进行事务操作，用于存储线程事务信息。
- 4、数据库连接，
Session会话管理。
ThreadLocal源码分析
set方法
public void set(T value) { //首先获取当前线程对象 Thread t = Thread.currentThread(); //获取线程中变量 ThreadLocal.ThreadLocalMap ThreadLocalMap map = getMap(t); //如果不为空， if (map != null) map.set(this, value); else //如果为空，初始化该线程对象的map变量，其中key 为当前的threadlocal 变量 createMap(t, value); } //初始化线程内部变量 threadLocals ，key 为当前 threadlocal void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); } /** * Construct a new map initially containing (firstKey, firstValue). * ThreadLocalMaps are constructed lazily, so we only create * one when we have at least one entry to put in it. */ ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { table = new Entry[INITIAL_CAPACITY]; int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); } static class Entry extends WeakReference<ThreadLocal<?>> { /**将k指向了一个弱引用*/ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } }
汇总下，ThreadLocalMap 为 ThreadLocal 的一个静态内部类，里面定义了Entry 来保存数据。而且是继承的弱引用。在Entry内部使用ThreadLocal作为key，使用我们设置的value作为value。
对于每个线程内部有个ThreadLocal.ThreadLocalMap 变量，存取值的时候，也是从这个容器中来获取。
2.get方法
public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }
通过上面的分析，相信你对该方法已经有所理解了，首先获取当前线程，然后通过key threadlocal 获取 设置的value 。
4. ThreadLocal 内存泄漏问题
我们首先来看下，下面这个类：
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}注释说的很清楚了，Note that null keys (i.e. entry.get()* == null)
如果 key threadlocal 为 null 了，这个 entry 就可以清除了。
ThreadLocal是一个弱引用，当为null时，会被当成垃圾回收 。
重点来了，突然我们ThreadLocal是null了，也就是要被垃圾回收器回收了，但是此时我们的ThreadLocalMap（thread 的内部属性）生命周期和Thread的一样，它不会回收，这时候就出现了一个现象。那就是ThreadLocalMap的key没了，但是value还在，这就造成了内存泄漏。
解决办法：使用完ThreadLocal后，执行remove操作，避免出现内存溢出情况。
所以 如同 lock 的操作 最后要执行解锁操作一样，ThreadLocal使用完毕一定记得执行remove 方法，清除当前线程的数值。
如果不remove 当前线程对应的VALUE ,就会一直存在这个值。
使用了线程池，可以达到“线程复用”的效果。但是归还线程之前记得清除ThreadLocalMap，要不然再取出该线程的时候，ThreadLocal变量还会存在。这就不仅仅是内存泄露的问题了，整个业务逻辑都可能会出错。
.
浙公网安备 33010602011771号