Java线程处于Park状态问题排查：无法同时运行超100线程

这问题我之前排查过类似的场景，咱们一步步来拆解成因，再对应找解决办法：

一、如何识别并发锁/等待的成因 #

1. 定位Condition绑定的锁资源
   从线程转储里找到parked线程的调用栈，往上回溯，找到创建这个ConditionObject的Lock（通常是ReentrantLock）实例。比如栈里会显示类似at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()，再往上看哪个业务代码调用了这个await方法，就能锁定是哪个共享资源的同步逻辑出了问题。
2. 检查任务依赖的有限资源
   线程数25以内正常、超过100就大量等待，大概率是你的任务依赖了某个容量有限的共享资源：比如数据库连接池（假设只有100个连接）、有界阻塞队列（容量100）、或者自定义的资源池（比如文件句柄、第三方API配额）。当线程数超过资源容量时，多余的线程就会阻塞在获取资源的步骤上，最终park在Condition上。
3. 分析Condition的await/signal逻辑
   看看业务代码里是不是用了生产者-消费者模式，或者类似的等待通知逻辑：
   • 是不是await()调用后，对应的signal()/signalAll()触发不及时？比如生产者生产数据的速度远慢于消费者线程的处理速度，导致大量消费者线程卡在await上。
   • 是不是只调用了signal()而不是signalAll()？如果多个线程在等同一个Condition，单次signal只能唤醒一个线程，剩下的还是会parked。
4. 排查任务间的依赖关系
   有没有任务之间存在同步依赖？比如某个任务必须等待另一个任务完成才能继续，而被依赖的任务数量有限（比如只有25个线程在处理前置任务），超过25后，后续任务就会陷入等待。

二、针对性的解决办法 #

1. 扩容或优化依赖的有限资源
   如果是资源瓶颈（比如数据库连接池太小），直接扩容对应的资源：比如把连接池容量调到200以上，或者优化资源复用逻辑（比如缩短连接持有时间、复用连接）。
2. 调整线程池参数适配资源能力
   固定大小200的线程池不一定适合你的场景：
   • 如果是CPU密集型任务，线程数建议设为CPU核心数+1，过多线程只会导致上下文切换开销；
   • 如果是IO密集型任务，但依赖的IO资源有限，线程池大小应该和资源容量匹配（比如资源只有100，线程池设为100左右），避免创建大量无意义的等待线程。
3. 修复Condition的使用逻辑
   • 如果是唤醒不及时，检查触发signal()/signalAll()的条件是否正确：比如生产者生产数据后必须立刻唤醒等待的消费者；
   • 当多个线程需要被唤醒时，优先用signalAll()而不是signal()，避免部分线程长期parked。
4. 引入限流机制
   在任务提交阶段就做限流，比如用Semaphore控制同时执行的任务数不超过资源上限，这样线程池里不会堆积大量等待的线程，也能避免资源过载。
5. 异步化重构任务逻辑
   如果任务里有不必要的同步等待，尝试用异步方式重构：比如用CompletableFuture把同步等待改成回调，减少线程阻塞的时间，提升线程利用率。

内容的提问来源于stack exchange，提问作者Jack BeNimble