ThreadLocal 原理与实践：线程隔离、内存泄漏与使用边界

ThreadLocal 原理与实践线程隔离、内存泄漏与使用边界目录线程私有变量Thread 的内部结构ThreadLocalMapset、get 和 remove 的过程内存泄漏与数据污染实战场景使用边界小结多线程操作共享变量时通常需要考虑加锁、原子操作和可见性问题。但有些数据从一开始就不需要在线程之间共享例如当前登录用户、事务连接、请求编号。它们只在当前线程的调用链中使用让每个线程保存自己的数据反而更合适。ThreadLocal 就是为这种场景准备的。线程私有变量ThreadLocal 为每个线程保存一份独立的数据。同一个 ThreadLocal 对象可以被多个线程访问但每个线程通过它读写的都是自己的值。ThreadLocalStringuserContextnewThreadLocal();// 线程 AnewThread(()-{userContext.set(张三);System.out.println(userContext.get());// 张三}).start();// 线程 BnewThread(()-{userContext.set(李四);System.out.println(userContext.get());// 李四}).start();两个线程使用的是同一个userContext线程 A 写入“张三”线程 B 写入“李四”最后读取到的却是各自设置的内容。可以把每个线程想象成一名员工每名员工都有自己的抽屉。ThreadLocal 不是抽屉本身而是打开某个格子的钥匙。不同员工使用同一把钥匙打开的是自己抽屉里的对应位置因此不会读到别人的数据。这种隔离并不是 ThreadLocal 在内部复制了多份对象。数据真正存放的位置在 Thread 中。Thread 的内部结构在java.lang.Thread中可以找到这样一个字段publicclassThreadimplementsRunnable{ThreadLocal.ThreadLocalMapthreadLocalsnull;}每个 Thread 对象都可以持有一个ThreadLocalMap。调用ThreadLocal.set()时数据会写入当前线程的 Map而不是保存在 ThreadLocal 对象中。结构大致如下ThreadLocalx可以同时出现在两个 Map 中但它们属于不同的线程关联的 value 也就互不影响。从这个结构可以看出ThreadLocal 更像一个访问入口Thread 持有 ThreadLocalMapThreadLocal 作为 Map 的 key业务数据作为 Entry 的 value线程隔离来自每个 Thread 独立持有的 Map而不是 ThreadLocal 本身有什么隔离能力。ThreadLocalMapThreadLocalMap 是 ThreadLocal 内部专门设计的数据结构。它没有直接使用 HashMap实现方式也有一些不同。Entry 结构staticclassEntryextendsWeakReferenceThreadLocal?{Objectvalue;Entry(ThreadLocal?key,Objectvalue){super(key);this.valuevalue;}}Entry 继承自WeakReferenceThreadLocal?因此 key也就是 ThreadLocal 对象是一个弱引用。value 则仍然是普通的强引用。如果外部不再持有某个 ThreadLocal下一次 GC 时这个 ThreadLocal 对象可以被回收。对应 Entry 的 key 随后会变成 null这种 key 已经为 null 的 Entry在 ThreadLocalMap 中被称为失效 Entry。开放定址法ThreadLocalMap 内部使用 Entry 数组保存数据。发生哈希冲突时它不会像 HashMap 那样使用链表或红黑树而是继续向后查找可用位置这种方式叫开放定址法。假设一个新的 ThreadLocal 计算后应该放在下标 2但下标 2 已经被占用ThreadLocalMap 就会继续检查下标 3、4直到找到合适的位置。每个 ThreadLocal 对象在创建时都会生成一个threadLocalHashCodeprivatefinalintthreadLocalHashCodenextHashCode();privatestaticintnextHashCode(){returnnextHashCode.getAndAdd(HASH_INCREMENT);}privatestaticfinalintHASH_INCREMENT0x61c88647;HASH_INCREMENT是一个与黄金分割相关的增量。连续创建多个 ThreadLocal 时生成的哈希值能够较均匀地分布在长度为 2 的幂次方的数组中从而减少相邻冲突。ThreadLocalMap 的初始容量是 16负载阈值约为容量的三分之二。达到阈值后它不会立即扩容而是先尝试清理已经失效的 Entry。清理之后空间仍然不足才会把数组扩展为原来的两倍。set、get 和 remove 的过程set以 JDK 17 中的实现为例set()的主要流程如下publicvoidset(Tvalue){ThreadtThread.currentThread();ThreadLocalMapmapgetMap(t);if(map!null){map.set(this,value);}else{createMap(t,value);}}首先取得当前线程然后读取它的 ThreadLocalMap。如果 Map 已经存在就以当前 ThreadLocal 为 key 写入数据如果还不存在则先创建一个 MapvoidcreateMap(Threadt,TfirstValue){t.threadLocalsnewThreadLocalMap(this,firstValue);}ThreadLocalMap.set()的内部处理可以简化为由于使用了开放定址法清理失效 Entry 不只是把某个数组位置设为 null还要重新整理后面的探测区间否则可能破坏已有元素的查找路径。getget()的流程与set()类似publicTget(){ThreadtThread.currentThread();ThreadLocalMapmapgetMap(t);if(map!null){ThreadLocalMap.Entryemap.getEntry(this);if(e!null){SuppressWarnings(unchecked)Tresult(T)e.value;returnresult;}}returnsetInitialValue();}它先取得当前线程的 ThreadLocalMap再使用当前 ThreadLocal 对象查找 Entry。ThreadLocalMap 会先检查哈希值对应的位置。如果该位置不是目标 Entry就沿着数组继续向后查找。在这个过程中遇到 key 为 null 的 Entry也会顺便进行清理。如果没有找到对应值get()会调用setInitialValue()初始化数据。ThreadLocal 默认的初始值是 null也可以通过withInitial()指定ThreadLocalLongstartTimeThreadLocal.withInitial(System::currentTimeMillis);第一次调用get()时初始化方法的结果会被写入当前线程的 ThreadLocalMap。之后再次调用get()直接返回已经保存的值。removeremove()用于删除当前线程中与该 ThreadLocal 对应的 Entrypublicvoidremove(){ThreadLocalMapmgetMap(Thread.currentThread());if(m!null){m.remove(this);}}删除之后Entry 中的 key 和 value 都不再由 ThreadLocalMap 持有。对于线程池中的线程这一步尤其重要因为线程执行完一个任务后通常不会销毁而是继续处理其他任务。内存泄漏与数据污染ThreadLocal 的内存问题经常被简单描述为“弱引用导致内存泄漏”。这个说法并不准确。弱引用允许 ThreadLocal 对象在失去外部强引用后被 GC 回收真正可能滞留的是 Entry 中被强引用的 value。publicvoiddoSomething(){ThreadLocalUseruserLocalnewThreadLocal();userLocal.set(newUser(张三));}方法执行结束后局部变量userLocal消失。如果没有其他强引用指向这个 ThreadLocalGC 可以回收它此时 value 仍然被 Entry 强引用不能立即回收。ThreadLocalMap 会在执行set()、get()和remove()的过程中清理失效 Entry因此这些数据不一定会永久存在。但这种清理是被动触发的。如果线程长期存活后续又没有进行能够触发清理的操作value 就可能在内存中停留很长时间。为什么 key 使用弱引用如果 Entry 对 ThreadLocal 使用强引用即使业务代码已经不再使用这个 ThreadLocal只要线程仍然存活ThreadLocal 对象及其 value 就始终无法回收。弱引用至少解除了 Map 对 ThreadLocal 生命周期的强绑定使已经失去外部引用的 ThreadLocal 可以被回收。它不能代替主动清理但能避免问题进一步扩大。线程池中的两类问题线程池里的线程会被重复使用ThreadLocal 数据也会跟着线程保留下来。如果任务结束时没有清理通常会出现两类问题。第一类是对象滞留。如果任务不断创建新的 ThreadLocal写入数据后又丢失对它们的引用ThreadLocalMap 中就可能出现越来越多 key 为 null、value 仍然存在的失效 Entry。executor.execute(()-{ThreadLocalbyte[]localnewThreadLocal();local.set(newbyte[1024*1024]);});这些 Entry 可能在后续操作中被清理但不能依赖这种被动清理保证数据及时释放。第二类是数据污染。如果多个任务共用同一个 ThreadLocal重复调用set()通常会覆盖原来的 value并不会每次新增 Entry。但上一个任务留下的值可能被下一个复用该线程的任务读取。相比单纯的内存占用请求之间串用用户信息往往更加危险。在 finally 中清理ThreadLocal 的生命周期应当与一次业务操作保持一致。设置完成后使用finally清理privatestaticfinalThreadLocalUserUSER_CONTEXTnewThreadLocal();try{USER_CONTEXT.set(currentUser);doBusiness();}finally{USER_CONTEXT.remove();}不能只在正常执行结束时调用remove()。如果业务代码抛出异常普通的清理语句可能不会执行放在finally中才能保证当前线程恢复到干净状态。实战场景数据库事务中的资源绑定Spring 事务管理需要保证同一事务中的数据库操作使用同一个连接。事务开始后Spring 会把数据库连接等资源绑定到当前线程。Service 调用 DAODAO 再调用 JDBC只要这些操作仍在同一个线程中就可以取得相同的事务资源。Spring 中负责这项工作的类是TransactionSynchronizationManager。其内部维护了类似下面的结构privatestaticfinalThreadLocalMapObject,ObjectresourcesnewNamedThreadLocal(Transactional resources);实际保存的不是单独一个数据库连接而是资源工厂与资源对象之间的映射。事务完成后Spring 会解除资源绑定并进行清理。ThreadLocal 在这里减少了连接对象在各层方法之间显式传递的需要。不过这种机制也意味着事务上下文默认依赖当前线程。把任务切换到另一个线程后原线程中的事务资源不会自动跟过去。用户请求上下文Web 请求进入系统后用户信息可能会被 Controller、Service、日志组件等多个位置使用。可以在拦截器中解析用户再将其写入 ThreadLocalpublicfinalclassUserContext{privatestaticfinalThreadLocalUserCURRENT_USERnewThreadLocal();privateUserContext(){}publicstaticvoidsetUser(Useruser){CURRENT_USER.set(user);}publicstaticUsergetUser(){returnCURRENT_USER.get();}publicstaticvoidclear(){CURRENT_USER.remove();}}拦截器负责设置和清理publicclassAuthInterceptorimplementsHandlerInterceptor{OverridepublicbooleanpreHandle(HttpServletRequestrequest,HttpServletResponseresponse,Objecthandler){UseruserextractUser(request);UserContext.setUser(user);returntrue;}OverridepublicvoidafterCompletion(HttpServletRequestrequest,HttpServletResponseresponse,Objecthandler,Exceptionex){UserContext.clear();}}请求开始时写入请求结束时删除业务代码在同一线程中可以随时获取当前用户。不过还要考虑异步请求。如果业务处理中切换了线程新的线程不会自动拥有原线程的 ThreadLocal 数据此时需要显式传递上下文或者使用框架提供的上下文传播机制。为非线程安全对象保存独立实例SimpleDateFormat内部包含可变状态多线程共享同一个实例可能产生错误结果。过去常见的一种处理方式是使用 ThreadLocal 为每个线程保存单独的实例privatestaticfinalThreadLocalSimpleDateFormatDATE_FORMATThreadLocal.withInitial(()-newSimpleDateFormat(yyyy-MM-dd));StringtodayDATE_FORMAT.get().format(newDate());线程之间不共享SimpleDateFormat因此不需要围绕格式化操作加锁。不过在现代 Java 项目中更直接的做法是使用java.time包中的DateTimeFormatter。它本身是线程安全的不需要借助 ThreadLocalprivatestaticfinalDateTimeFormatterDATE_FORMATTERDateTimeFormatter.ofPattern(yyyy-MM-dd);ThreadLocal 能绕开线程安全问题但如果已经存在设计良好的线程安全实现优先使用后者。使用边界ThreadLocal 适合保存与当前线程生命周期相关的上下文但不适合代替正常的数据传递方式。首先它不能直接用于跨线程传值。在线程池、CompletableFuture和异步任务中代码可能切换到另一个线程原线程保存的数据不会自动出现在线程池的工作线程中。InheritableThreadLocal可以在线程创建时把父线程的值传给子线程但它不适合直接解决线程池中的上下文传递问题。线程池中的线程通常早已创建完成不会在每次提交任务时重新继承调用方的数据。其次不要把体积很大的对象放进 ThreadLocal。ThreadLocal 中的数据会跟随线程存活线程池中的线程又可能长期不销毁大对象因此更容易长时间占用内存。如果一项数据只需要在两三个相邻方法之间传递直接使用方法参数通常更清晰。ThreadLocal 隐藏了数据来源使用过多会增加代码理解和测试难度。它也不适合解决共享计数、线程通信等问题。多个线程需要共同修改一个计数器时应考虑AtomicInteger、LongAdder或锁线程之间需要传递数据时可以使用并发队列、Future 等工具。小结ThreadLocal 没有把数据保存在自己内部。它以自身作为 key把 value 写入当前线程持有的 ThreadLocalMap。每个线程拥有独立的 Map因此同一个 ThreadLocal 在不同线程中可以对应不同的值。Entry 对 ThreadLocal 使用弱引用让失去外部引用的 ThreadLocal 能够被 GC 回收但 value 仍然需要及时清理。在线程池环境中未清理的数据既可能造成对象长期滞留也可能被后续任务错误读取。ThreadLocal 适合处理同一线程内的上下文传递。确定要使用时应当明确数据的设置位置、读取范围和清理时机并在finally中调用remove()。