Java 高并发多线程 “ThreadLocal” 面试清单（含超通俗生活案例与深度理解）
一、请解释下 ThreadLocal 是什么？
核心定义：ThreadLocal 全称“线程本地变量”，它的核心作用是为每个访问它的线程，单独创建一份变量的“专属副本”。简单来说，多个线程同时操作同一个 ThreadLocal 变量时，每个线程实际操作的都是自己手里的副本，不会影响其他线程的副本，最终实现“线程隔离”，从根源上避免了线程安全问题。
原创生活例子：可以类比公司里每个员工的“工位专属抽屉”——假设公司为每个员工配置了带电子锁的抽屉（ThreadLocal 变量的载体），每个抽屉都绑定员工的工牌（ThreadLocal 对象），只有用自己的工牌才能打开。员工 A（线程 A）上班时，会把自己的项目文档、笔记本（变量值）放进抽屉；员工 B（线程 B）也会把自己的资料放进自己的抽屉。不管是存东西还是取东西，员工只能操作自己的抽屉：员工 A 看不到员工 B 抽屉里的内容，也不会误把自己的资料放进别人的抽屉。就算两个员工同时使用“抽屉”功能，也不会出现“资料混乱”的情况，这就是 ThreadLocal 实现的“线程隔离”效果。
深入思考：很多开发者会把 ThreadLocal 和 synchronized 混淆，其实两者解决线程安全的思路完全不同——synchronized 是“让多个线程排队使用同一个资源”，比如多个员工抢着用一台公共打印机，需要排队等待；而 ThreadLocal 是“给每个线程分配独立的资源”，比如每个员工都有自己的私人打印机，不用排队。另外要注意，ThreadLocal 不是用来“共享数据”的，而是用来“避免数据共享”的，它最适合的场景是“线程内需要重复使用某个数据，但又不想和其他线程共享”。比如一个线程从启动到结束，需要多次用到某个业务 ID（如订单 ID、任务 ID），如果每次都通过方法参数传递，代码会很冗余，用 ThreadLocal 存一次，后续随时取就很方便。
二、你在工作中实际用过 ThreadLocal 吗？具体场景是什么？
核心场景：我在生鲜电商项目的“订单履约全流程”中用过 ThreadLocal，主要用来传递“订单上下文信息”，解决跨模块参数传递冗余的问题，同时避免方法参数过多导致的代码混乱。
原创生活例子：生鲜电商的订单流程涉及多个模块协作：用户下单后，订单请求会先到“订单校验模块”（验证用户是否实名认证、地址是否合规），再到“库存扣减模块”（锁定对应商品的库存），最后到“物流调度模块”（分配配送员、生成配送单）。这三个模块都需要用到订单的关键信息，比如订单 ID（用于关联数据）、用户收货地址（用于物流分配）、商品规格（比如“5斤装有机草莓”，用于库存匹配）。
如果不用 ThreadLocal，我需要在每个模块的方法里都添加这些参数：比如“订单校验模块”的 checkOrder 方法执行完后，要把订单 ID、收货地址等信息作为返回值，传给“库存扣减模块”的 deductStock 方法；deductStock 执行完后，又要把这些信息传给“物流调度模块”的 assignCourier 方法。这就像快递员送快递时，每次到仓库取货、到小区配送，都要反复给总部打电话要订单信息，不仅效率低，还容易因为口误传错信息（比如把“3单元”说成“5单元”）。
后来用 ThreadLocal 优化后，流程变得简洁：在“订单校验模块”（流程起点），系统解析用户下单请求后，把订单 ID、收货地址、商品规格封装成“订单上下文对象”，用 threadLocal.set(context) 存进去。后续“库存扣减模块”需要订单 ID 锁定库存时，不用等上一个模块传参，直接调用 threadLocal.get().getOrderId() 就能拿到；“物流调度模块”需要收货地址分配配送员时，也是直接从 ThreadLocal 里取。这就像快递员出门前，总部把订单信息打印成“配送小票”（ThreadLocal 里的副本）交给快递员，后面不管是取货还是配送，快递员直接看自己的小票就行，不用再反复联系总部，代码冗余减少了，传参错误的概率也降低了。
深入思考：ThreadLocal 还适合“分布式追踪”场景，比如在微服务调用中，每个请求会生成一个唯一的 traceId，用 ThreadLocal 存起来后，从网关到服务 A、服务 B，再到数据库，每次日志打印都能带上这个 traceId，后续排查问题时，通过 traceId 就能串联起整个请求的链路。但要注意线程复用的问题：如果项目用了线程池（比如 Tomcat 的线程池、Spring 的异步线程池），线程会被多个请求复用，如果上一个请求用完 ThreadLocal 没清理，下一个请求复用这个线程时，就可能拿到上一个请求的 traceId，导致日志链路混乱。所以一定要在请求结束后（比如网关的过滤器后置方法、Spring 的拦截器 afterCompletion 方法）调用 threadLocal.remove() 清理数据，避免“数据串用”。
三、ThreadLocal 的实现原理是什么？
核心逻辑：ThreadLocal 本身不存储任何数据，它的底层依赖 Thread 类里的一个成员变量——ThreadLocalMap。简单来说，每个线程（Thread 对象）都自带一个“专属容器”（ThreadLocalMap），当线程通过 ThreadLocal 存值时，实际是把“ThreadLocal 对象作为 key”“变量值作为 value”，存到自己的 ThreadLocalMap 里；取值时，也是用 ThreadLocal 作为 key，从自己的 ThreadLocalMap 里找对应的 value。因为每个线程的 ThreadLocalMap 是独立的，所以实现了线程隔离。
原创生活例子：可以类比“小区的智能快递柜系统”——整个小区（JVM）里住着很多住户（线程），每个住户在入住时，物业会分配一个专属的快递柜（ThreadLocalMap），快递柜的电子锁只认住户的专属门禁卡（ThreadLocal 对象）。当快递员（代码）要给住户送快递（存变量）时，会先通过住户的身份信息（Thread.currentThread()）找到对应的快递柜，再用住户的门禁卡（ThreadLocal）打开柜子，把快递（value）放进去。住户（线程）取快递时，也是用自己的门禁卡（ThreadLocal）打开自己的快递柜，取出里面的快递。
这里有两个关键细节要注意：第一，每个住户的快递柜是独立的，住户 A 的门禁卡打不开住户 B 的快递柜，确保了“数据隔离”；第二，门禁卡（ThreadLocal）本身不装快递，它只是“打开快递柜的工具”，真正存快递的是住户自己的快递柜（ThreadLocalMap）。
关键细节拆解：
1. Thread 和 ThreadLocalMap 的关联：在 Java 源码中，Thread 类有一个成员变量 threadLocals，类型是 ThreadLocal.ThreadLocalMap，默认值为 null。只有当线程第一次调用 ThreadLocal 的 set 或 get 方法时，才会初始化这个 threadLocals（创建 ThreadLocalMap 对象）。这就像住户入住后，不会马上有快递柜，直到第一次有快递要存，物业才会激活快递柜的使用权限。
2. ThreadLocalMap 的核心结构：ThreadLocalMap 是 ThreadLocal 的内部类，它本质是一个“Entry 类型的数组”——每个 Entry 是一个键值对，key 是 ThreadLocal 的弱引用，value 是线程要存的变量副本。可以理解为，住户的快递柜（ThreadLocalMap）里有多个小格子（Entry），每个格子对应一个“门禁卡+快递”的组合：比如一个住户可能有两把门禁卡（两个 ThreadLocal 对象），一把用来存“生鲜快递”（比如订单上下文），另一把用来存“账单信息”（比如用户支付记录），后续用对应的门禁卡就能打开对应的格子。
3. ThreadLocal 的角色定位：ThreadLocal 就像“快递柜的门禁卡”，它的唯一作用是帮线程找到自己 ThreadLocalMap 里的对应 Entry。如果没有 ThreadLocal 这个 key，线程就不知道从自己的 ThreadLocalMap 里找哪个格子的快递，就像没有门禁卡，住户不知道开哪个快递柜格子一样。
深入思考：实际开发中，有的开发者会误以为“一个 ThreadLocal 只能存一个值”，其实不是——一个 ThreadLocal 对应 ThreadLocalMap 里的一个 Entry（一个格子），如果需要存多个值，可以创建多个 ThreadLocal 对象，比如 ThreadLocal<OrderContext> 存订单上下文，ThreadLocal<UserInfo> 存用户信息，它们会作为不同的 key，对应 ThreadLocalMap 里的不同 Entry，互不干扰。另外要注意，ThreadLocal 是线程安全的吗？答案是“相对安全”——因为每个线程操作的是自己的 ThreadLocalMap，不会修改其他线程的 map，所以在“线程隔离”的场景下是安全的，但如果多个线程共享一个 ThreadLocal 对象，且通过它操作共享资源（比如静态 ThreadLocal 存了一个共享的集合），还是会有线程安全问题，这点需要避免。
四、ThreadLocal 为什么会出现内存泄露？怎么解决？
核心原因：内存泄露的根源是 ThreadLocalMap 的 key（ThreadLocal 的弱引用）和 value（变量副本）的生命周期不匹配。当 ThreadLocal 对象被垃圾回收（GC）后，key 会变成 null，但 value 还留在 ThreadLocalMap 里；如果此时线程没有结束（比如线程池里的线程被复用），ThreadLocalMap 会一直持有 value 的强引用，导致 value 无法被 GC 回收，最终占用内存，形成内存泄露。
原创生活例子：可以类比“长租公寓的行李存放问题”——假设你租了一间长租公寓（线程池里的线程，生命周期长，会被复用），公寓里有一个带锁的储物柜（ThreadLocalMap），你把行李箱（value）放进储物柜，用一把钥匙（ThreadLocal 对象）锁上。后来你不小心把钥匙弄丢了（ThreadLocal 对象被 GC 回收），虽然你还住在公寓里（线程没销毁），但因为没有钥匙，你没法打开储物柜拿出行李箱；更麻烦的是，公寓管理员（JVM）不知道这个储物柜里的行李箱是你的，也没法清理，导致这个行李箱一直占着储物柜的空间（内存）。如果后面有新租客（复用这个线程）住进来，打开储物柜可能会看到你的行李箱（数据串用），还会让这个行李箱占用的空间一直得不到释放。
为什么 key 要设计成弱引用？：很多人会疑惑，既然弱引用会导致 key 被 GC 回收，为什么不把 key 设计成强引用？其实这是为了避免另一种更严重的内存泄露——如果 key 是强引用，当 ThreadLocal 对象不再被使用（比如代码里没有地方引用它了），但因为 ThreadLocalMap 的 key 还强引用着它，ThreadLocal 对象无法被 GC 回收，导致 ThreadLocal 对象本身内存泄露。用弱引用的话，至少 ThreadLocal 对象能被 GC 回收，只留下 value 的泄露问题，后续只要清理 value 就能解决，相当于“两害相权取其轻”。
解决办法：核心原则是“使用完 ThreadLocal 后，必须手动清理 value”，具体有两种常见且可靠的方式：
1. 在 finally 块中调用 remove() 方法：这是最推荐的方式，因为 finally 块无论代码是否抛出异常，都会执行，能保证 value 一定被清理。比如在生鲜电商的订单流程中，不管订单处理成功（正常履约）还是失败（库存不足、地址无效），都要在 finally 里调用 threadLocal.remove()，把订单上下文从 ThreadLocalMap 里删掉，就像快递员送完单，不管有没有送成功，都要把小票扔掉，避免下一单用错信息。
2. 在线程池的任务生命周期钩子中清理：如果项目用了线程池（比如 Spring 的 ThreadPoolTaskExecutor），线程会被复用，可以通过线程池的“任务执行后钩子”清理 ThreadLocal。比如重写 ThreadPoolTaskExecutor 的 afterExecute 方法，在每个任务执行完后，调用 threadLocal.remove()。这样不管任务是否抛出异常，都能确保 ThreadLocal 里的数据被清理，避免后续任务复用线程时拿到旧数据。
深入思考：在实际项目中，内存泄露最容易出现在“线程池+ThreadLocal”的场景。比如一个 Tomcat 服务器的线程池，每个线程处理 hundreds 甚至 thousands 次 HTTP 请求，如果每次请求用完 ThreadLocal 不清理，线程的 ThreadLocalMap 里会积累大量无用的 value，最终导致内存溢出（OOM）。曾经在项目中遇到过这样的问题：测试环境压测时，Tomcat 运行一段时间后报 OOM，通过内存快照分析发现，大量 ThreadLocalMap$Entry 对象没有被回收，最终定位到是拦截器里用了 ThreadLocal 但没在 afterCompletion 方法里清理，加上线程池复用，导致 value 不断积累。后来在拦截器的后置方法里加了 remove()，问题就解决了。所以一定要养成“用 ThreadLocal 就加清理逻辑”的习惯，不要依赖 JVM 的 GC 自动清理。
五、你了解 ThreadLocalMap 的结构吗？
核心结构：ThreadLocalMap 虽然名字里有“Map”，但它并没有实现 Java 中的 Map 接口，而是 ThreadLocal 的一个内部类，本质是一个“Entry 类型的数组”，每个 Entry 存储“ThreadLocal 的弱引用（key）”和“变量值（value）”，同时通过特殊的哈希算法（用黄金分割数作为哈希增量）保证 key 的分布均匀，减少冲突。
原创生活例子：可以类比“学校的学生专属储物柜区”——整个储物柜区是一排整齐的金属柜子（Entry 数组），每个柜子有一个唯一的编号（数组下标，从 0 开始），每个柜子里放着“学生的校园卡（key，ThreadLocal 的弱引用）”和“学生的物品（value，变量副本）”。学校给学生分配储物柜时，不是随机分配，而是用一个特殊的规则：第一个学生分配到 0 号柜，第二个学生分配到 0 + 0x61c88647（十六进制数，对应十进制的 1640531527）计算出的编号，第三个学生再在此基础上加 0x61c88647，以此类推。这样做的好处是，学生的储物柜会均匀分布在整个储物柜区，不会都挤在某一片区域（比如不会出现 0、1、2 号柜都被占用，而后面的柜子都空着的情况），后续学生找柜子时，也不容易遇到“自己的柜子被别人占了”的冲突。
关键细节拆解：
1. Entry 数组的本质：ThreadLocalMap 里有一个 private 成员变量 table，类型是 Entry[]，这就是存储数据的核心容器。Entry 类继承了 WeakReference<ThreadLocal<?>>，所以它的 key 是 ThreadLocal 的弱引用，value 是 Object 类型（存储变量的副本）。可以理解为，每个 Entry 就是一个“带弱引用 key 的键值对”——就像学生储物柜里，校园卡（key）是弱引用：如果学生毕业了（ThreadLocal 被 GC 回收），校园卡会被学校回收，但柜子里的物品（value）还在，需要学生手动清理（调用 remove()）。
2. 哈希增量：0x61c88647 的作用：ThreadLocal 类里有一个静态常量 HASH_INCREMENT = 0x61c88647，这个值是“斐波那契数”（也叫黄金分割数）。每次创建一个 ThreadLocal 对象，都会给它分配一个 threadLocalHashCode，计算方式是“上一个 ThreadLocal 的 hashCode + 0x61c88647”。为什么要用这个数？因为黄金分割数的特性是，它能让 threadLocalHashCode 在 Entry 数组中分布得非常均匀——当数组长度是 2 的幂（ThreadLocalMap 的数组长度默认是 16，且每次扩容都是 2 倍）时，用 threadLocalHashCode & (table.length - 1) 计算下标时，能最大限度减少不同 ThreadLocal 的下标重复，就像学校用黄金分割数分配储物柜，学生的柜子不会扎堆，冲突概率极低。
3. 初始容量和负载因子：ThreadLocalMap 的初始数组长度是 16（和 HashMap 一致），负载因子是 2/3——当 Entry 的数量达到数组长度的 2/3 时，就会触发“清理过期 Entry”或“扩容”逻辑。比如数组长度是 16，当 Entry 数量达到 10（16*2/3≈10.66，取整数 10）时，系统会先清理过期的 Entry（key 为 null 的 Entry）；如果清理后 Entry 数量还是超过 10，就会触发扩容。这和 HashMap 的负载因子 0.75 不同，ThreadLocalMap 的负载因子更低，是为了更早触发清理，减少冲突，因为它没有链表/红黑树来处理大量冲突。
深入思考：ThreadLocalMap 的结构设计非常贴合它的使用场景——因为 ThreadLocal 通常是每个线程用少数几个（比如存订单上下文、用户信息，一般 1-2 个），所以 Entry 数组不需要太大，而且用黄金分割数保证分布均匀，能进一步减少冲突。相比 HashMap 要处理大量键值对（可能成百上千个），ThreadLocalMap 的结构更简单、更轻量，没有链表或红黑树的复杂结构，内存开销更小，查询和存储效率更高。实际开发中，很少会遇到 ThreadLocalMap 因结构问题导致的性能瓶颈，更多的问题出在“忘记清理 value”导致的内存泄露，这一点需要重点关注。
六、ThreadLocalMap 是怎么解决哈希冲突的？和 HashMap 有什么区别？
核心方案：ThreadLocalMap 用“开放定址法”（具体是“线性探测”）解决哈希冲突，而不是 HashMap 用的“链地址法”（链表+红黑树）。开放定址法的核心逻辑是：当通过哈希计算得到的数组下标被占用（冲突）时，就依次往后查找下一个空的下标，直到找到空位置为止；取值时，也从哈希计算的下标开始，依次往后比对 key，直到找到匹配的 key 或遇到空位置。
原创生活例子：可以类比“食堂打饭窗口排队”——假设食堂有 10 个打饭窗口（Entry 数组，下标 0-9），每个窗口只能同时给一个人打饭（每个下标只能存一个 Entry）。你（ThreadLocal 对象）通过学号计算，本该去 3 号窗口打饭（哈希计算的下标是 3），但到了之后发现 3 号窗口有人正在打饭（冲突了）。这时候你不会在 3 号窗口后面排队（不是链地址法），而是直接走到 4 号窗口看看；如果 4 号窗口也有人，就继续走到 5 号，直到找到一个没人的窗口（空的 Entry），然后在这个窗口打饭（存 Entry）。后面你要再去打饭（取值）时，还是先走到 3 号窗口，发现里面的人不是你（key 不匹配），就继续往后找，直到找到你之前打饭的窗口（比如 7 号，key 匹配），然后取餐。
和 HashMap 的核心区别：
1. 解决冲突的方式不同：这是最本质的区别。HashMap 用链地址法——如果某个下标冲突，就把新的 Entry 加到该下标的链表后面，当链表长度超过 8 时，会转成红黑树（提高查询效率）。比如食堂 3 号窗口有人，后面来的人都在 3 号窗口后面排队，队伍长了就分成两队（红黑树），依次打饭；而 ThreadLocalMap 用线性探测的开放定址法，冲突了就往后找空窗口，不会排队。
2. 结构复杂度不同：HashMap 因为用链地址法，需要维护链表或红黑树的结构，代码逻辑更复杂，内存开销也更大（每个 Entry 要存下一个节点的引用）；ThreadLocalMap 只有 Entry 数组，结构简单，没有额外的链表/红黑树开销，内存更轻量，适合存储少量键值对。
3. 适用场景不同：HashMap 适合存储大量键值对（比如缓存大量用户数据、存储配置信息），因为链地址法处理冲突的效率高，就算冲突多，链表/红黑树也能保证查询效率（时间复杂度 O(log n)）；ThreadLocalMap 适合存储少量键值对（每个线程一般用 1-2 个 ThreadLocal），冲突概率低，线性探测的效率足够高（时间复杂度接近 O(1)），而且结构简单，更符合“轻量存储”的需求。
深入思考：为什么 ThreadLocalMap 不用链地址法？因为它的使用场景决定了冲突概率很低——每个线程的 ThreadLocal 数量很少（通常 1-2 个），而且用黄金分割数的哈希增量保证了 key 的分布均匀，冲突本来就少，用线性探测足够应对。如果用链地址法，反而会增加结构复杂度和内存开销（比如每个 Entry 要存 next 引用），得不偿失。而 HashMap 要处理大量键值对，冲突概率高，必须用链地址法才能保证效率。这也说明，技术选择没有绝对的“好”与“坏”，只有“是否适合当前场景”。实际开发中，不需要纠结两种方式的优劣，重点是理解它们的设计思路，以及在不同场景下的适用范围。
七、ThreadLocalMap 的扩容机制了解吗？
核心流程：ThreadLocalMap 的扩容不是简单的“数组翻倍”，而是分三步：先清理过期 Entry → 判断清理后是否需要扩容 → 若需要，扩容为原数组的 2 倍，并重新哈希所有有效 Entry 到新数组。整个过程的核心是“先清理再扩容”，尽量利用清理出的空间，避免不必要的扩容，节省内存。
原创生活例子：可以类比“超市零食货架的补货和扩容”——假设超市有一排零食货架（Entry 数组），共 16 层（初始容量 16），超市规定：当货架上的零食（Entry）数量达到 10 层（负载因子 2/3，162/3≈10.66，取整数 10）时，就要启动“货架整理流程”：
第一步，清理过期零食（清理过期 Entry）：店员会遍历整个货架，把过期的薯片、饼干（key 为 null 的 Entry）全部扔掉，同时把后面的零食往前挪，比如把 8 号层的零食移到 5 号空层，避免货架有空缺导致顾客找不到零食；
第二步，判断是否需要扩容：清理完后，店员会数一下剩下的零食数量，如果数量超过 7 层（阈值的 3/4，103/4=7.5，取整数 7），说明当前货架不够用了，需要扩容；如果数量少于 7 层，说明清理出的空间足够，不用扩容；
第三步，扩容并重新摆放零食（resize 方法）：如果需要扩容，超市会加一排 16 层的新货架，变成 32 层（原数组的 2 倍）。店员会把原来货架上的有效零食（没过期的）按新的规则（重新哈希）摆到新货架上——比如原来在 3 号层的薯片，现在会计算新的位置（比如 7 号层），原来在 5 号层的饼干，会移到 12 号层，确保零食分布均匀，方便顾客拿取。
关键步骤拆解：
1. 触发扩容的条件：当调用 ThreadLocal 的 set 方法时，系统会先计算当前 Entry 的数量（sz），然后执行“启发式清理”（cleanSomeSlots 方法，随机清理部分过期 Entry）。如果清理后没有删除任何 Entry，且 sz 达到了扩容阈值（table.length * 2/3），就会触发 rehash() 方法，开始扩容流程。比如数组长度 16，阈值 10，当 sz=10，且清理后 sz 还是 10，就会进入 rehash()。
2. 清理过期 Entry（expungeStaleEntries 方法）：rehash() 方法首先会调用 expungeStaleEntries()，遍历整个 Entry 数组，清理所有“key 为 null”的 Entry。清理时，不仅会把 value 设为 null（让 GC 能回收），还会把该位置的 Entry 设为 null，同时重新哈希该位置后面的有效 Entry，避免出现“空位置隔断”导致后续查找失败。比如清理了 5 号位置的过期 Entry 后，会检查 6 号、7 号位置的 Entry，如果它们的哈希下标不是当前位置，就重新计算正确位置，移过去，确保数组紧凑。
3. 判断扩容的阈值：清理完后，系统会判断当前 Entry 的数量（size）是否大于等于“threshold - threshold/4”（也就是阈值的 3/4）。比如阈值是 10，10-10/4=7.5，取整数 7，如果 size≥8，就会触发 resize() 方法（真正的扩容）；如果 size<8，说明清理后空间足够，不用扩容，直接结束流程。这一步的目的是“尽量利用清理出的空间，减少扩容次数”——很多时候，清理过期 Entry 后，空间就够了，不用浪费内存扩容。
4. 扩容和重新哈希（resize 方法）：扩容后的新数组长度是原数组的 2 倍（比如原长度 16，新长度 32），系统会创建一个新的 Entry 数组（newTab）。接下来遍历原数组（oldTab），对每个有效 Entry（key 不为 null），重新计算它在 newTab 中的下标（用 key.threadLocalHashCode & (newTab.length - 1)），然后用线性探测法找到空位置，把 Entry 存进去。遍历完成后，把 ThreadLocalMap 的 table 指向 newTab，同时更新阈值（newTab.length * 2/3），扩容完成。
深入思考：ThreadLocalMap 的扩容机制有两个很聪明的设计：一是“先清理再扩容”，通过清理过期 Entry 释放空间，避免不必要的扩容——在线程池场景下，线程复用会积累很多过期 Entry，清理后往往不需要扩容，能节省大量内存；二是“扩容后重新哈希”，因为新数组长度是 2 的倍，重新哈希能保证 Entry 分布更均匀，减少后续的冲突概率。相比 HashMap 扩容时“直接把链表拆分到两个下标”，ThreadLocalMap 的重新哈希更彻底，但因为它的 Entry 数量少，效率影响不大。实际开发中，很少需要关注扩容的细节，只要记住“用完 ThreadLocal 要清理”，就能减少扩容的频率，提升性能。
八、父子线程怎么共享 ThreadLocal 中的数据？为什么普通 ThreadLocal 不行？
核心方案：普通 ThreadLocal 无法实现父子线程共享数据，需要用 InheritableThreadLocal 类（ThreadLocal 的子类），它的核心作用是“在子线程创建时，把父线程的 inheritableThreadLocals（专门存储可继承变量的 map）复制给子线程”，从而实现父子线程数据共享。
原创生活例子：可以类比“爸爸带孩子去游乐园”——假设爸爸（父线程）要带孩子（子线程）去游乐园，出门前爸爸买了一张“亲子套票”（父线程用 InheritableThreadLocal 存的数据），这张套票爸爸和孩子都能用。当爸爸带着孩子到游乐园门口（子线程初始化）时，游乐园工作人员会根据爸爸的套票，复制一张一模一样的套票给孩子（子线程的 inheritableThreadLocals 复制父线程的），这样孩子进园时，不用再单独买票，直接用复制的套票就能入园。如果用普通 ThreadLocal，就像爸爸买了一张“单人票”（父线程的 threadLocals 存的数据），这张票只能爸爸自己用，孩子没有票，进不了园，也就是子线程拿不到父线程的数据。
为什么普通 ThreadLocal 不行？：因为普通 ThreadLocal 存储的数据在父线程的 threadLocals 里，而 threadLocals 是 Thread 类的成员变量，每个线程的 threadLocals 是独立的——子线程创建时，JVM 不会复制父线程的 threadLocals 到子线程。就像爸爸的“单人票”存在自己的钱包（threadLocals）里，孩子有自己的钱包（子线程的 threadLocals），爸爸不会把自己钱包里的票放进孩子的钱包，所以孩子拿不到。
InheritableThreadLocal 的实现原理：
1. Thread 类的额外变量：Thread 类除了 threadLocals，还有一个成员变量 inheritableThreadLocals，类型也是 ThreadLocal.ThreadLocalMap，专门用来存储 InheritableThreadLocal 的数据。可以理解为，每个线程有两个“钱包”：一个装自己的私人钱（threadLocals，普通 ThreadLocal 数据），一个装要给孩子的“共享钱”（inheritableThreadLocals，InheritableThreadLocal 数据）。
2. 子线程初始化时的复制逻辑：当通过 new Thread() 创建子线程时，会调用 Thread 的 init() 方法。在 init() 方法里，如果父线程的 inheritableThreadLocals 不为 null，并且 inheritThreadLocals 标志为 true（默认是 true），就会调用 ThreadLocal.createInheritedMap(parent.inheritableThreadLocals)，创建一个新的 ThreadLocalMap，把父线程 inheritableThreadLocals 里的 Entry 复制到子线程的 inheritableThreadLocals 里。这就像孩子的“共享钱包”（子线程的 inheritableThreadLocals）在创建时，会把爸爸“共享钱包”里的亲子套票（父线程的 inheritableThreadLocals 数据）复制一份进去。
3. 数据读写的逻辑：InheritableThreadLocal 重写了 ThreadLocal 的 getMap(Thread t) 和 createMap(Thread t, T firstValue) 方法——getMap 方法返回线程的 inheritableThreadLocals，createMap 方法初始化线程的 inheritableThreadLocals。所以当用 InheritableThreadLocal 存值时，数据会存到 inheritableThreadLocals 里；取值时，会从 inheritableThreadLocals 里取，而不是 threadLocals。
深入思考：InheritableThreadLocal 有一个明显的局限性——“复制只发生在子线程创建时”。如果子线程创建后，父线程再修改 InheritableThreadLocal 的值，子线程拿不到新值。比如爸爸把复制票给孩子后，又在游乐园门口买了一张“棉花糖券”（父线程后续修改 InheritableThreadLocal 的值），孩子手里的复制票里没有棉花糖券，因为复制只在“进园前”（子线程创建时）发生。如果实际项目中需要“父子线程实时同步数据”，InheritableThreadLocal 就不够用了，需要结合其他方案，比如用“线程安全的容器（如 ConcurrentHashMap）+ 监听器”，让父子线程都访问同一个容器，父线程修改后，子线程能实时读取到新值。另外，在线程池场景下，子线程是从线程池里获取的（不是新创建的），InheritableThreadLocal 的复制逻辑不会触发，这时候需要手动传递数据，比如在提交任务时，把父线程的数据作为参数传给子线程的任务，避免数据无法共享。