Java线程池内存开销由线程栈、任务队列、线程对象及关联结构共同决定；平台线程栈默认1MB，无界队列易致堆内存泄漏，虚拟线程可将栈开销降至0.5KB/个。
Java线程池的内存 footprint 并不只取决于线程数量，而是由线程栈、任务队列、线程对象本身及关联结构共同决定。尤其在高并发容器化部署中，未加约束的线程池极易成为内存泄漏或OOM的源头。
线程栈：平台线程的隐性开销主力
每个平台线程默认占用约1MB堆外内存（由 -Xss 控制），即使线程处于空闲状态，栈空间也不会释放。例如：
- 设置
corePoolSize=200的固定线程池 → 至少占用 200MB 堆外内存 - 若
maximumPoolSize=1000且突发流量触发扩容 → 瞬间新增 800MB 栈内存，极易突破容器 Cgroups 内存上限 - 线程工厂未自定义命名或未关闭守护线程属性，还可能干扰监控与诊断
任务队列：无界队列是内存失控常见诱因
使用 newCachedThreadPool() 或 newFixedThreadPool(n) 时，默认搭配的是无界 LinkedBlockingQueue，这会导致：
- 任务持续提交但消费缓慢时，待执行任务在堆内无限堆积
- 每个
Runnable或FutureTask对象含引用链（如闭包捕获的局部变量），易引发堆内存泄漏 - 建议改用有界队列（如
ArrayBlockingQueue），并配合拒绝策略（如AbortPolicy或自定义丢弃+告警逻辑）
线程对象与生命周期管理成本
线程实例本身虽小（约几百字节），但在高创建/销毁频率下仍不可忽视：
立即学习“Java免费学习笔记（深入）”；
-
newCachedThreadPool中线程空闲60秒后回收，但频繁创建会增加GC压力（尤其年轻代） - 未显式调用
shutdown()或shutdownNow()，导致线程池长期持有线程引用，阻碍JVM回收 - 线程局部变量（
ThreadLocal）若未清理，会在每个线程栈中驻留对象，造成“伪内存泄漏”
虚拟线程替代方案：大幅压缩 footprint 的新路径
JDK 21+ 支持虚拟线程，可从根本上缓解传统线程池的资源瓶颈：
- 单个虚拟线程栈仅占 ~0.5KB，10,000 个并发任务内存开销不足 5MB（对比平台线程的 10GB）
- 推荐搭配
Executors.newVirtualThreadPerTaskExecutor()，避免手动管理生命周期 - 务必配合结构化并发（
StructuredTaskScope）限制作用域，防止孤儿线程累积在堆中 - 注意适用边界：适用于 I/O 密集型场景，CPU 密集型任务仍应使用固定大小的平台线程池
