JVM线程资源耗尽通常源于线程池配置失当、阻塞型任务占比过高或死锁，核心解法是分层治理：先隔离线程池避免相互挤占，再为不同任务匹配显式队列与拒绝策略，配合JVM层线程栈分析与参数调优，最后在代码层面化解阻塞源。
线程池配置：堵住资源耗尽的第一道闸门
为什么默认线程池会拖垮你的服务
很多Java服务直接使用Executors.newFixedThreadPool()或newCachedThreadPool()，这类快捷方法在真实业务场景下问题很明显。FixedThreadPool使用无界队列LinkedBlockingQueue，当任务积压速度超过处理速度，队列无限膨胀，内存先于线程被打爆。CachedThreadPool使用SynchronousQueue，只要任务到达就必须有线程接单，瞬时并发上来，线程数直接冲到几百上千，CPU上下文切换开销陡增。
某支付网关团队曾遇到核心服务RT从50ms飙升到8秒,排查后才发现是newCachedThreadPool在促销流量下创建了超过400个线程，而该机器只有4核，行业共识认为：无界队列和无限线程数，本质是拿稳定性换吞吐，分布式环境下尤其危险。
手写线程池的参数怎么定
先看一个兼顾通用性和可落地性的配置样例：
ThreadPoolExecutor pool = new ThreadPoolExecutor(
8, // corePoolSize 核心线程
16, // maximumPoolSize 最大线程
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(1000), // 有界队列，长度根据任务吞吐估算
new ThreadFactoryBuilder().setNameFormat("pay-async-%d").build(),
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：谁提交谁执行
);
参数没有放之四海皆准的公式,但有几个判断维度可以参考。
- 核心线程数：CPU密集型业务设为
CPU核数+1，IO密集型按CPU核数 2起步，再结合压测逐步上调。 - 队列长度：根据任务提交峰值速率乘以任务平均耗时估算缓冲量，比如每秒峰值提交500个任务，单个任务IO耗时200ms，那队列至少需要容纳
500 0.2 = 100个任务。 - 拒绝策略：
AbortException直接抛异常适合对失败敏感的任务；DiscardOldest适合允许丢弃旧任务的实时性场景；CallerRuns把压力回推给调用方，天然限流。 - 线程工厂必须自定义，给线程一个有业务含义的名字（如
order-scan-worker），线上排查时通过jstack一眼找到对应线程组，没有名字的线程在问题定位时等于盲人摸象。
多个线程池隔离，别让一个业务拖垮全局
把积压任务、慢调用、批量任务全部丢进同一个线程池，一旦某个接口出现线程阻塞，所有业务一起遭殃。隔离的核心是按业务域拆分线程池，池与池之间物理隔离，拒绝策略独立配置
。
比如一个电商中台,可以把库存查询、订单写入、外部API回调拆成三个线程池，库存查询是高频低耗时，核心线程可以大一些；外部API回调依赖第三方，随时可能变慢，队列就要短，拒绝策略用CallerRuns防止回调丢失，这样即使外部API回调线程池被打满，库存查询不受影响。
JVM层调优：让线程活得更顺畅
线程栈大小与元空间，别忽略的内存开销
每个线程默认会分配1MB的线程栈（-Xss参数控制），注意这是虚拟内存映射，但GC扫描和栈深度都会受实际使用影响，如果业务里递归较深或方法调用层级复杂，默认1MB足够；但线程总数大的服务，比如500个线程，光栈空间就占500MB虚拟地址空间，32位系统需要留意，用-Xss256k或-Xss512k可以降低单线程内存占用，不过需要压测验证深度调用场景不会栈溢出。
更常见的坑是元空间（Metaspace），每个线程都持有类元数据的引用，当线程反复创建（比如每次请求都new Thread），类加载器无法回收，元空间持续上涨，最终触发OutOfMemoryError: Metaspace，线上服务建议加上-XX:MaxMetaspaceSize=512m给元空间封顶，同时排查是否有动态生成类的框架（CGLIB、反射代理）在泄漏。
从全局视角看：线程数有多少才合理
一个容易被忽略的指标是JVM活动线程数与CPU核数的比值，经验上，纯计算型服务活动线程数维持在CPU核数的1-2倍比较合理；IO密集型服务可以到CPU核数的5-10倍，但这依赖IO等待时间占比，如果线程数常年是CPU核数的20倍以上，大概率有阻塞问题，而不是配置问题。
怎么查JVM里当前线程数？jstack <pid> | grep "java.lang.Thread.State" | awk '{print $2}' | sort | uniq -c可以按线程状态统计数量，如果BLOCKED或WAITING线程占比相当大，就要往锁竞争方向查，而不是继续加线程。
代码层面：把阻塞源掐死在源头
锁竞争：线程资源的头号杀手
Java的synchronized和ReentrantLock如果在热点路径上竞争激烈，线程会从RUNNABLE转成BLOCKED或WAITING，这些线程占着线程池名额却不干活，用jstack多次抓取线程栈，如果多次看到同一个线程停在同一个锁的park或enter代码行，基本可以判定锁竞争。
优化手段按优先级排序：
- 缩小锁粒度：按订单号或用户ID分段加锁，而不是锁全局Map。
- 读写锁分离：读多写少的场景用
ReentrantReadWriteLock或StampedLock，读读不互斥。 - 无锁化：用
ConcurrentHashMap的computeIfAbsent代替普通Map加锁，用LongAdder代替
synchronized
- 减少锁持有时间：把IO操作移出临界区，锁内只做状态变更。
阻塞IO操作：把线程池当成垃圾桶
很多团队把线程池当作“万能加速器”，把远程HTTP调用、数据库查询、Redis操作全丢进去，以为这样就提升了并发。线程池不会让慢IO变快，只会让慢IO占满线程名额，数据库慢查询30秒，对应的线程就在WAITING状态挂30秒，期间无法执行其他任务。
统计数据显示,相当一部分Java服务线程数高企的根因，是线程池里跑着大量远程调用和DB操作。处理这类场景的正解是CompletableFuture异步编排+独立IO线程池，让IO等待不占用主业务线程。
CompletableFuture.supplyAsync(() -> rpcClient.query(orderId), ioPool)
.thenApply(result -> processResult(result))
.orTimeout(3, TimeUnit.SECONDS)
.exceptionally(ex -> fallback());
这段代码里,ioPool专门给RPC调用用，主业务线程池只负责CPU计算，两类线程互不干扰，超时控制用orTimeout兜底，防止第三方服务假死拖死整条链路。
内存与GC：间接扼杀线程的隐形凶手
GC线程本身不占业务线程池名额,但GC停顿会让业务线程集体暂停。GC频繁导致的STW（Stop-The-World）时间累积，会让任务处理速度急剧下降，进而引发任务积压更多积压任务又申请更多线程，形成恶性循环，排查时可以结合jstat -gcutil <pid> 1000观察GC频率和耗时，如果Full GC频繁，优先解决对象分配和内存泄漏问题，而不是调大线程池。
如何正确排查线程池问题
分步骤定位：从异常现象到根因
线程耗尽的表现通常是RejectedExecutionException、接口超时率上升、CPU飙高或频繁GC，排查路径建议按以下四步走：
- 抓线程快照：连续抓3-5次
jstack，每次间隔5-10秒，观察哪些线程长时间停留在WAITING或BLOCKED状态，长时间停在LockSupport.park说明在等锁或队列，停在socketRead说明在等IO。 - 查线程池活跃度：通过
ThreadPoolExecutor的getActiveCount()、getQueue().size()、getTaskCount()三个指标评估池子的压力，Active持续接近maximumPoolSize且队列非空，说明池子不够用。 - 看GC日志：
-Xlog:gc打开GC日志，检查是否因GC停顿导致线程处理变慢。 - 压测复现：用JMeter或Gatling对疑似接口做阶梯加压，观察线程数、RT、QPS的关系曲线。
遇到RejectedExecutionException怎么办
如果确认拒绝原因是队列满+线程数达到上限，优先评估任务特性是否需要调整参数；如果参数调整后仍然拒绝，那说明系统容量确实到了上限
，此时需要考虑限流降级，比如用Semaphore控制进入业务方法的并发数，或者用Sentinel做流控，架构层面则要拆分服务，把不同负载的任务拆到独立服务中，而不是在同一个JVM里抢资源。
线程数持续飙升：CPU与内存的极限博弈
有个容易被忽视的细节：即使线程池配置合理，代码里直接new Thread或使用Timer（内部单线程）也会绕过线程池管理，搜索代码库里的new Thread(和Timer，全部替换为受控的线程池或ScheduledExecutorService，每个new Thread都是游离在线程池之外的野线程，它们不排队、不设上限、没有拒绝策略，出现故障时连dump日志都难以定位归属。
北京一个技术团队分享过案例：某服务线程数每48小时涨一倍，排查发现是某个定时任务用Executors.newSingleThreadScheduledExecutor每5分钟启动一批new Thread，老任务因为一个未关闭的HTTP连接池迟迟不退出，线程越堆越多，最终在凌晨触发了OutOfMemoryError，修复方式是统一改用核心线程数为1、有界队列的ScheduledThreadPoolExecutor，并为线程设置空闲回收时间（allowCoreThreadTimeOut(true)）。
问答模块
为什么运维同学给了很多CPU核数，Java线程表现反而差了？
这种情况通常不是核数问题,而是线程阻塞在远程IO或锁上，CPU核数高只对纯计算有帮助，IO等待不受CPU核数影响，先拿jstack看看线程状态分布，如果WAITING占比超过40%，大概率是上游依赖慢或者锁竞争激烈，加核数只会让更多线程排队等锁。
Tomcat线程池参数和JVM线程池可以共用一套标准吗？
不建议共用,Tomcat的工作线程池处理的是HTTP请求生命周期，请求量波动大且有超时兜底，核心线程数通常设为CPU核数，最大线程数设为CPU核数的2-4倍并启用acceptCount做TCP队列缓冲，业务专用线程池服务于特定任务类型，参数必须结合任务耗时的P99、提交速率、依赖稳定性单独测算，两者混用容易让Tomcat线程占满后，业务线程池反而饿死，上海某金融团队曾把两类线程池共用一套参数，压测时HTTP线程抢占了大部分CPU，核心交易线程池大面积超时。
Java服务线程池应该设置多少核心线程才能既省资源又扛得住流量？
没有固定数字,但可以用QPS峰值和单任务耗时反推，先测出单个任务在目标并发下的平均耗时T，公式参考：核心线程 ≈ QPS峰值 × T，再在这个基础上乘以一个冗余系数（比如1.2-1.5），同时用有界队列做缓冲，最大线程数是核心线程的1.5-2倍，最终仍要通过压测验证：在核心线程数不变的情况下逐步提高QPS，观察RT出现拐点的位置，省资源的本质是让每个线程尽量满负荷跑，而不是压线程数上限线程空转等待IO的时间也是成本。