Java线程池本身不直接导致内存泄漏，但因线程复用机制与ThreadLocal、未关闭资源、静态引用等配合不当而成为高发场景；必须显式调用remove()清理ThreadLocal，禁用Executors工厂方法，严格管控队列容量与线程数，并确保线程池正确关闭。
Java 中线程池本身不会直接导致内存泄漏，但它是内存泄漏的高发场景——根本原因在于线程复用机制与 ThreadLocal、未关闭资源、静态引用等配合不当。关键不是“线程池有没有泄漏”，而是“你在它上面放了什么、怎么放、又怎么收”。
必须显式清理 ThreadLocal，不能依赖自动回收
线程池中线程长期存活，而 ThreadLocal 的 value 是强引用，key（即 ThreadLocal 实例）却是弱引用。一旦 ThreadLocal 对象被 GC（比如 static 引用被置为 null 或类卸载），key 变成 null，但 value 仍牢牢挂在 ThreadLocalMap 里，形成“脏项”。空闲线程不执行 get/set/remove 就不会触发探测清理，这些 value 就永远卡在堆里。
- 所有自定义的
ThreadLocal（尤其是存用户上下文、大 Map、IO 缓冲区等）必须在任务结束时调用remove()，不能用set(null)替代 - 推荐统一兜底：继承
ThreadPoolExecutor，重写afterExecute(Runnable r, Throwable t)，在里面对每个已知 ThreadLocal 调用remove() - 业务代码仍需套
try-finally：哪怕只读取一次，也建议get()后紧跟remove()，尤其 Web 请求这类短生命周期场景 - 声明一律用
private static final，便于集中管理；同时提供封装好的clear()工具方法
禁止使用 Executors 工厂方法，严控队列与线程边界
无界队列或无限线程数不是性能优化，是 OOM 前奏。任务对象（含请求体、DTO、SQL 参数等）持续堆积在内存中，比 ThreadLocal 泄漏更隐蔽、更猛烈。
- 禁用
Executors.newFixedThreadPool()等——它们底层用LinkedBlockingQueue(Integer.MAX_VALUE)，等于默许任务无限积压 - 手动构造线程池：选用
ArrayBlockingQueue并指定合理容量（如 256），让队列大小“看得见、可监控” - 核心线程数、最大线程数、队列容量三者需匹配；例如 8 核心线程 + 256 队列，意味着最多缓冲 256 个待执行任务，超限即触发拒绝策略
- 拒绝策略优先选
CallerRunsPolicy：由提交线程自己执行，天然实现背压，防止上游无节制推送
确保线程池自身被正确关闭
线程池未关闭，不仅造成线程资源滞留，还会让其中所有 ThreadLocal、缓存、连接等“悬停”在内存中，持续占用空间，甚至阻塞 JVM 正常退出。
立即学习“Java免费学习笔记（深入）”；
- 服务停机时必须调用
shutdown()，再配合awaitTermination()等待任务完成，不能只 shutdown 就结束 - 典型安全模式：先
shutdown()，等待 30 秒；超时后调shutdownNow()，再等 5 秒；仍未终止则记录告警 - 更可靠的方式是让线程池实现
AutoCloseable，或交由 Spring 的@PreDestroy/destroyMethod统一管理，避免手动遗漏 - 特别注意：Tomcat/Jetty 等 Web 容器中，线程池若未随应用上下文销毁，其内部持有的 RequestContextHolder、事务上下文等也会持续泄漏
警惕其他常见泄漏源与线程池联动
ThreadLocal 和队列只是冰山一角，很多泄漏是多个因素叠加的结果。
- 数据库连接、文件流、网络 Socket 等资源，若在任务中打开却未关闭，会随线程复用越积越多——务必用
try-with-resources或显式close() - 静态集合类（如
static Map<String, Object>）若作为缓存使用，且未设过期或清除机制，会在每个线程处理请求时不断 put，最终撑爆堆内存 - 监听器、回调函数、Lambda 表达式若捕获了外部大对象或 Activity/Context（Android 场景），也会因线程复用而长期持引用
- 虚拟线程虽轻量，但若在其内持有 JDBC 连接或未关闭的流，同样会泄漏——资源释放逻辑与平台线程一致，不可放松
