ThreadLocal 内存泄露与最佳实践
几乎所有 Java 项目都在用 ThreadLocal 存储上下文信息，但很多人不知道它可能造成内存泄漏——而且是在你”原本以为不会”的场景下。
一、ThreadLocal 的设计初衷
- 1.1 线程隔离的数据存储——每个线程一份独立副本
- 1.2 典型使用场景——数据库连接、Session、事务上下文、链路追踪 TraceId
二、ThreadLocal 的底层结构
- 2.1 Thread → ThreadLocalMap → Entry（弱引用包装的 ThreadLocal 作为 key）
- 2.2 ThreadLocalMap 的数据结构——线性探测法解决哈希冲突
- 2.3 Entry 继承 WeakReference——key 是弱引用，value 是强引用
三、内存泄漏的成因
- 3.1 弱引用的 key 被 GC 回收后 key 变为 null
- 3.2 value 依然被 Entry 强引用——无法被回收
- 3.3 线程池中线程复用——Thread 生命周期很长
- 3.4 图解：Thread → ThreadLocalMap → Entry(null, value) → 泄漏对象
四、ThreadLocal 的清理机制
- 4.1
get()/set()时的启发式清理——expungeStaleEntry() - 4.2
remove()的显式清理——最可靠的方式 - 4.3 启发式清理的局限性——为什么不能完全依赖
五、JDK 8 vs JDK 9+ 的改进
- 5.1 JDK 8 中 ThreadLocal 的实现
- 5.2 JDK 9+ 的优化
六、实际案例
- 6.1 Spring 的
RequestContextHolder——基于 ThreadLocal 的请求上下文 - 6.2 链路追踪中 TraceId 的存储与传递
- 6.3 线程池中 ThreadLocal 的传递——InheritableThreadLocal 与 TransmittableThreadLocal
七、最佳实践
- 7.1 永远在 finally 块中调用
remove() - 7.2 声明为
static final - 7.3 使用阿里开源的 TransmittableThreadLocal 解决线程池传递问题
- 7.4 代码扫描规则——检测未 remove 的 ThreadLocal
八、总结
- ThreadLocal 的正确打开方式
- 排查 ThreadLocal 泄漏的工具与方法
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 谜思录！
相关推荐
2022-10-15
并发工具类对比与实践
一个接口需要调用 3 个微服务，串行 300ms。用 CompletableFuture 并行调用只需 120ms。 一、场景描述 1.1 商品详情页——需要商品信息、库存、评价、推荐 1.2 串行调用——逐个等待，时间累加 1.3 并行调用的收益——总时间 = max(每个调用的时间) 二、CountDownLatch 2.1 原理——计数器，主线程等待所有子任务完成 2.2 代码示例——3 个线程并行获取数据 2.3 缺点——无法获取返回值、只能使用一次 三、CyclicBarrier 3.1 原理——所有线程到达 barrier 后一起继续 3.2 与 Count...
2014-01-11
线程池参数配置指南
Executors.newFixedThreadPool() 阿里规范不让用，newCachedThreadPool() 可能导致 OOM。那么线程池到底该怎么配？本文从源码到生产实践，给出计算公式和配置模板。 一、线程池的 8 个参数 1.1 corePoolSize——核心线程数 1.2 maximumPoolSize——最大线程数 1.3 keepAliveTime——空闲线程存活时间 1.4 unit——时间单位 1.5 workQueue——工作队列 1.6 threadFactory——线程工厂 1.7 handler——拒绝策略 1.8 参数之间的协作关系——任务提交后...
2023-04-15
海量数据分页方案对比
LIMIT 1000000, 20 需要扫描 100 万行再丢弃，这就是 OFFSET 分页越往后越慢的根本原因。 一、OFFSET 分页的问题 1.1 原理——LIMIT offset, count → 扫描 offset + count 行 1.2 offset=0：扫描 20 行 1.3 offset=1000000：扫描 1000020 行 1.4 为什么不能跳过前面的行——B+Tree 有序但非跳跃 二、方案 1：游标分页（推荐） 2.1 原理——WHERE id > last_id ORDER BY id LIMIT 20 2.2 使用最后一条...
2018-09-29
幂等方案设计
用户点了两次支付按钮，扣了两次钱。幂等设计是金融级系统的基本功。 一、幂等的定义与重要性 1.1 幂等的数学定义——f(f(x)) = f(x) 1.2 程序中——同一个操作执行一次和执行多次的结果相同 1.3 哪些场景需要幂等——支付、下单、消息消费、接口重试 二、接口层幂等——Token 机制 2.1 客户端先获取 Token——GET /token 返回唯一 ID 2.2 提交时带上 Token——POST /order + token 2.3 服务端校验 Token——Redis DEL 原子操作 2.4 Token 的过期时间设计 三、数据库层幂等 3.1 唯一索引——...
2020-10-17
库存扣减并发安全
库存扣减是高并发场景下最容易出错的地方。数据库行锁、Redis Decr、Lua 脚本、事务消息，四种方案孰优孰劣？ 一、库存扣减的核心挑战 1.1 超卖——库存变成负数 1.2 少卖——库存有剩余但无法下单 1.3 热点商品——大量请求竞争同一行数据 1.4 扣减与支付的时序 二、方案 1：数据库行锁 2.1 UPDATE stock SET num = num - ? WHERE id = ? AND num >= ? 2.2 行锁的排队效果——天然串行化 2.3 热点商品性能——TPS 受限于行锁 2.4 优化——拆行为多行 三、方案 2：Redis Decr 3.1...
2023-09-16
单元测试覆盖率推进策略
“没时间写测试” → 线上频繁出问题 → 更没时间写测试。如何打破这个恶性循环？ 一、为什么单元测试覆盖率低 1.1 历史债务——老代码没有测试 1.2 赶进度——测试被忽视 1.3 写测试难——依赖太多无法 Mock 二、覆盖率目标设定 2.1 不要追求 100%——80% 是合理的上限 2.2 核心链路优先——支付、下单等高价值链路 2.3 工具类优先——纯函数容易测试 三、增量策略 3.1 新增代码——覆盖率不低于 80%（CI 卡点） 3.2 修改代码——补充修改部分的测试 3.3 存量代码——按优先级逐步补充 3.4 JaCoCo 覆盖率报告集成 四、让测试更好写 4...