ThreadLocal的设计思考

问题的提出

• 在Java多线程中，共享变量的读写非常容易出现不可预测的行为，因此对共享变量的访问控制非常重要。因此在多线程编程时，为了保证线程安全，需要进行额外的同步措施。比如典型的操作就是加锁。除了加锁外，另一种常用的方法是使用ThreadLocal , 这种用法在框架中非常普遍。
• ThreadLocal可以理解为线程本地变量。多个线程对同一个变量如何不互相影响，那么只有对自身独有的变量访问（独占内存）时才是线程安全的，因此，ThreadLocal 为变量在每个线程中都创建了一个副本，该副本只能被当前线程访问，多线程之间是隔离的，变量不能在多线程之间共享。这样每个线程修改变量副本时，不会对其他线程产生影响。

常规做法

• 多线程访问 ThreadLocal 变量时都会有自己独立的实例副本，要维护线程与变量的对应关系，一种普遍的思维就是在 ThreadLocal 中维护一个映射表 Map 用于记录线程与实例之间的映射关系，也就是有一层总控的协调在里面。
• 但是，如果存在总控进行协调，那么在新增线程和销毁线程时都需要更新 Map 中的映射关系时，就会在总控这里产生多线程并发修改，那么就又产生了额外的操作来保证 Map 是线程安全的。如果是在高并发的场景并发修改 Map 需要加锁，会明显降低性能。

JDK的实现

• JDK的 ThreadLocal 提供了一种新的思路，从 Thread 的视角来看，在 Thread 中维护一个 Map用于记录 ThreadLocal 与实例之间的映射关系，这样在同一个线程内，Map 就不需要加锁了。

• 从 Thread 代码定义看出：Thread类依赖了ThreadLocal.ThreadLocalMap；

public class Thread implements Runnable {/* ThreadLocal values pertaining to this thread. This map is maintained* by the ThreadLocal class. */ThreadLocal.ThreadLocalMap threadLocals = null;
} 

• 从 ThreadLocal 的代码来看：
  1. 它的get/set都是从线程取到对应的ThreadLocal.ThreadLocalMap；代码仅以get示例。
  2. 它定义的ThreadLocalMap的 Entry 继承了WeakReference，Entry的key是弱引用，value是强引用。这样设计获得了另外一个好处：防止内存泄漏。在 JVM 垃圾回收时，只要发现了弱引用的对象，不管内存是否充足，都会被回收。如果key是强引用，当ThreadLocal不再使用时，ThreadLocalMap中还是存在对ThreadLocal的强引用，那么GC是无法回收的，从而造成内存泄漏。

public class ThreadLocal<T> {/*** Returns the value in the current thread's copy of this* thread-local variable.  If the variable has no value for the* current thread, it is first initialized to the value returned* by an invocation of the {@link #initialValue} method.** @return the current thread's value of this thread-local*/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();}ThreadLocalMap getMap(Thread t) {return t.threadLocals;}static class ThreadLocalMap {/*** 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;}}}
}

• Entry的key设计成了弱引用，但是当ThreadLocal不再使用被 GC 回收后，ThreadLocalMap 中可能出现 Entry的key为null，那么Entry的value一直会强引用数据而得不到释放，只能等待线程销毁。
• 如何避免ThreadLocalMap内存泄漏? ThreadLocal做了如下的保护措施，在执行 ThreadLocal.set()/get()方法时，ThreadLocal会调用expungeStaleEntry方法清除 ThreadLocalMap 中key为null的 Entry 对象，让它还能够被 GC 回收。
  • expungeStaleEntry方法会遍历ThreadLocalMap的散列表，从当前节点开始向后遍历数组，将过期的条目（即key为null的条目）清理掉，并将这些条目的位置设置为null。如果遇到未过期的数据，则重新计算其位置并重新分配，确保数据尽可能靠近正确的位置，以减少冲突和查找时间‌。

编程习惯

在编程时，还需要注意：

• 当线程中某个ThreadLocal对象不再使用时，立即调用remove()方法删除Entry对象。
• 如果是在异常的场景中，应在finally代码块中进行清理，保持良好的异常处理意识。

学得经验

• 除了集中控制并发外，可以将竞争的数据分散出去。
• 解决方案的自洽性，增加了线程自身的数据副本，需要保证生命周期的一致性，这里的设计尽最大可能的保证了GC的可执行。