我们首先要明白，对象和引用有什么联系？
当我们使用Object o = new Object()这样的代码去创建对象时，是使用new关键字在堆中分配了一个Object类型的对象。并且在线程栈中有一个引用o(或者称为指针)，是指向了刚刚我们创建出来的对象的，也就是下图这样的结构。
image.png
1. 从Thread类内部说起去谈ThreadLocal的原理
Thread类内部，有一个ThreadLocalMap字段。
image.png
而ThreadLocalMap内部实际上是维护了一个Entry[]的table。
image.png
从上图中我们也可以看到，Entry继承了弱引用类WeakReference类，并且在构造函数中调用的是super(k)，而k的类型是ThreadLocal，相当于就是Entry维护的是一个弱引用的key(类型为ThreadLocal)和一个强引用的value。
当我们使用下面这两行代码去创建ThreadLocal对象并完成初始化时
ThreadLocal<String> threadLocal = new ThreadLocal<>();
threadLocal.set("1");
线程栈中的threadLocal引用使用强引用的方式(new一个对象肯定是强引用)指向了堆中的ThreadLocal对象，这个毋庸置疑。
image.png
我们从上图中可以发现，在将值进行set入到ThreadLocalMap时，Entry的key是this(刚刚我们使用new ThreadLocal()创建出来的对象)，value是我们设置的值，也就是说ThreadLocalMap中的Entry中的key是以弱引用的方式去指向我们创建出来的ThreadLocal对象的。
最终形成如下这样的结构图
image.png
为什么Entry的key是强引用会产生内存泄露？
我们做一个假设：假设Entry的key是以强引用的方式指向堆中ThreadLocal对象，但是我们执行了如下代码
threadLocal = null;
最终，Entry的key还是强引用，会指向我们创建的ThreadLocal对象，但是，我们已经无法访问到ThreadLocal对象了这片内存区域了呀！这样，就形成了一片内存被占用了，但是我们无法访问到，也就是所谓"内存泄露"。
单独使用key作为弱引用就可以解决内存泄露问题吗？
我们可以知道，如果Entry的key是弱引用，当我们使用threadLocal = null手动置空)，那么当GC到来时，Entry的key指向的ThreadLocal对象一定会被回收，因为只剩一条弱引用了！(note：如果不进行置空，我们threadlLocal引用还强引用的方式去指向了ThreadLocal对象呢，绝对不能回收)
但是value呢？value可是强引用啊！你虽然把Entry中的key指向的内存区域回收了，但是value也没办法访问了啊！那不是也会造成内存泄露？
因此ThreadLocal设计的get、set、remove等方法，都会唤起对Entry[]进行启发式清扫，如果检测到key为空，那么就把value也给清除掉了。
启发式清扫是否完全内存泄露解决问题？
我们假设一种情况，一个线程池中的线程7*24的工作，ThreadLocal用完了，将threadLocal引用置空，GC到来时，key肯定被干掉了，但是value一直没被干掉(很长时间没有调用get、set等方法)，最终就导致越来越多的value堆积，长期以往，就有可能造成OOM。
另外一方面，ThreadLocal设计的启发式清扫，从效率的考虑，设计成为一个时间复杂度为O(logn)的清扫，既然不是全表的清扫，那么就可能导致，某次调用get/set操作时，并不能及时对Entry[]中全部的Entry进行清扫，每次只能清理一部分。
因此，在我们使用完ThreadLocal时，记得调用remove方法，将该Entry的value也去进行清除掉。
2.线程之间的传值-InheritableThreadLocal
我们都知道ThreadLocal是线程本地，数据只能在线程内部共享，那么有没有办法将ThreadLocal的数据传输给别的线程呢？JDK中其实为我们提供了InheritableThreadLocal这样一个组件。
我们首先来看Thread类的构造方法：
image.png
我们可以看到当new一个线程时，会以currentThread作为父线程，并将父线程的inheritableThreadLocals拷贝到new出来的线程当中，子线程就可以访问父线程的数据了。
image.png
我们首先可以看到的是，InheritableThreadLocal继承于ThreadLocal，并且绝大多数的方法都使用ThreadLocal的，因此我们在使用上，和ThreadLocal是没有任何区别的。
image.png
当我们使用如下的代码时，新创建的线程中s拿不到数据，返回的是null。
ThreadLocal<String> threadLocal = new ThreadLocal<>();
threadLocal.set("1");
new Thread(() -> {
String s = threadLocal.get();
System.out.println(s);
}).start();
当我们使用如下的代码时，新创建的线程中，s就可以获取到父线程设置进去的数据1。
ThreadLocal<String> threadLocal = new InheritableThreadLocal<>();
threadLocal.set("1");
new Thread(() -> {
String s = threadLocal.get();
System.out.println(s);
}).start();
问题：如果子线程中修改了ThreadLocal中的值，父线程可以感知到吗？
我们使用如下的代码去进行测试：
ThreadLocal<String> threadLocal = new InheritableThreadLocal<>();
threadLocal.set("1");
new Thread(() -> {
threadLocal.set("2");
}).start();
TimeUnit.SECONDS.sleep(1);
String s = threadLocal.get();
System.out.println(s);
最终输出的结果是1，也就是说，子线程修改了数据，父线程并不能获取到，也就是说，数据的传输是单方向的，仅仅是copy一份数据，而不是父线程子线程去进行共享。
我们来看createInheritedMap方法(ThreadLocal的构造方法)其实就可以发现，它只是将ThreadLocal中的值拿出来，设置到新的Entry当中去，并不是共享ThreadLocalMap或者是Entry。(如果共享，又会涉及到线程安全的问题了)
image.png
但是InheritableThreadLocal只能用在父子线程之间传值，那么不是父子线程的方式呢？比如我们有一个任务要丢给线程池去执行，就肯定不是父子线程，自然是不能用InheritableThreadLocal。
有没有别的线程之间传值的方式？
其实很简单嘛，要传递的时候，我们也把值拿出来，进行保存，再传给子线程不就完事了吗，最直接的方式。
ThreadLocal<String> threadLocal = new ThreadLocal<>();
threadLocal.set("wanna");
String str = threadLocal.get();
new Thread(()->{
System.out.println(str);
}).start();
上面的这种方式在只传递一个简单值时应该是效率最高的方式了，没毛病。但是我们要传输多个对象时，就比较繁琐了，挨个获取挨个设置，并且代码也不是那么好看。
保存值的另外一种方式就是另外创建一个临时对象来保存，临时对象，自然可以是lambda表达式。
public static class ContextHolder {
private static ThreadLocal<Object> data1 = new ThreadLocal<>();
private static ThreadLocal<Object> data2 = new ThreadLocal<>();
public static Object getData1() {
return data1.get();
}
public static void setData1(Object o) {
data1.set(o);
}
public static Object getData2() {
return data2.get();
}
public static void setData2(Object o) {
data2.set(o);
}
}
public static Supplier<Object> contextAsSupplier() {
// 获取当前线程的data，保存到Supplier中
Object data1 = ContextHolder.getData1();
Object data2 = ContextHolder.getData2();
return () -> {
ContextHolder.setData1(data1);
ContextHolder.setData2(data2);
return null;
};
}
我们设计一个ContextHolder如上面的代码所示
使用方式如下：
ContextHolder.setData1(1);
ContextHolder.setData2(2);
Supplier<Object> supplier = contextAsSupplier();
new Thread(() -> {
Object o = supplier.get(); // 调用supplier.get是为了，将data设置到ContextHolder中去
System.out.println(ContextHolder.getData1());
System.out.println(ContextHolder.getData2());
}).start();
在父线程调用了contextAsSupplier方法时，就已经将data1和data2设置到Supplier这个lambda表达式中了。
在子线程中调用Supplier.get方法，就回调了lambda表达式中的代码，将保存的data1和data2数据都设置到子线程的ContextHolder之中去。我们执行上述的代码，可以发现，我们保存的data1和data2都能在子线程中去进行获取。
假如我们把创建的线程，改为交给线程池去执行呢？将测试代码改成如下：
ContextHolder.setData1(1);
ContextHolder.setData2(2);
Supplier<Object> supplier = contextAsSupplier();
CompletableFuture.runAsync(() -> {
Object o = supplier.get(); // 调用supplier.get是为了，将data设置到ContextHolder中去
System.out.println(ContextHolder.getData1());
System.out.println(ContextHolder.getData2());
});
我们发现，也可以获取到主线程设置的data1和data2。也就实现了线程之间的传值。
我们要做的，其实就是将之前线程的ThreadLocal的值去进行保存到一个对象当中，再回调一个方法去将保存的值，重新写入到新的线程的ThreadLocal当中去，关键就是这个回调是一定要执行，你采用何种方式去进行回调其实都可以。
比如你可以构建下面这样的一个临时类，来存放对象，调用invoke方法来执行回调，将数据进行转移，关键一定要保存对象，并回调，其实本质上差不多。
public static class Context {
private Object data1;
private Object data2;
public Context() {
this.data1 = ContextHolder.getData1();
this.data2 = ContextHolder.getData2();
}
public void invoke() {
ContextHolder.setData1(data1);
ContextHolder.setData2(data2);
}
}
为什么这里要采用Supplier呢？其实我们需要的只是一个参数为空，返回值为void的函数接口，但是又要新写一个类，多难受，不如直接使用Supplier，不用它的返回值不就完了，当然也可以直接使用Consumer，不用它的参数也行。另外一种原因是，你可以在Supplier中返回一些需要的业务数据，将返回值充分利用上。
实际上这种ContextHolder的写法是来自于开源框架OpenFeign，下面是OpenFeign的一段原文源码。
image.png
网友评论