Java线程池线程数不可能真正超过maximumPoolSize，这是ThreadPoolExecutor严格保证的不变量；所谓“超过”均源于混淆JVM总线程、多个线程池混用或第三方SDK私建线程池等误判。
Java线程池的线程数**不可能真正超过**maximumPoolSize——这不是漏洞，而是ThreadPoolExecutor设计上严格保证的不变量（invariant）。只要使用标准JDK实现且未篡改源码，getPoolSize()返回值永远不会大于maximumPoolSize。所谓“超过”现象，100%是误判或表象误导，根源在于对线程池运行机制、监控指标含义或任务来源的误解。
为什么你“看到”的线程数超过了maximumPoolSize
常见错觉来源有三类：
-
混淆了线程池线程与JVM总线程：用
jstack或top -H看到几百个线程，但其中大量是Netty EventLoop、Dubbo Client线程、定时调度线程、GC线程、甚至日志异步刷盘线程——它们和你的ThreadPoolExecutor无关。只应关注线程名匹配你自定义ThreadFactory前缀的线程。 -
多个线程池实例被混为一谈：一个应用常含多个线程池（如HTTP客户端、数据库连接池、业务异步池、定时任务池）。监控时若未按
ObjectName或自定义指标打标，容易把A池的活跃线程+ B池的队列等待线程+ C池的阻塞IO线程全算作“同一个池超限”。 -
第三方SDK偷偷创建了独立线程池：如短信SDK、消息队列客户端、对象存储SDK等，内部调用
Executors.newCachedThreadPool()或直接new ThreadPoolExecutor，且未暴露管理接口。这些“幽灵线程池”不受你主配置约束，却在堆栈中表现为pool-2-thread-xx，极易被误认为是你配置的池溢出。
如何确认是否真有线程池突破maximumPoolSize
不依赖肉眼数线程，用三步交叉验证：
- 查运行时真实参数：
executor.getCorePoolSize()、executor.getMaximumPoolSize()、executor.getPoolSize()——这三个值必须同时获取，且getPoolSize()≤getMaximumPoolSize()才合规。若发现getPoolSize()>getMaximumPoolSize()，说明该实例已被反射篡改或使用了非标准实现（极罕见）。 - 看JMX MBean属性：连接JConsole或VisualVM，定位到
java.util.concurrent.ThreadPoolExecutor对应的MBean，检查PoolSize、MaximumPoolSize、ActiveCount字段。JMX数据由JVM底层原子变量读取，可信度高于代码调用。 - 抓取线程堆栈并过滤：执行
jstack <pid> | grep -A 5 -B 5 "your-pool-name"，只提取你明确命名的线程（如order-async-pool-），统计其数量。忽略所有未命名、带netty、dubbo、lettuce、scheduled字样的线程。
真正危险的“伪超限”场景及修复
以下情况看似“线程爆满”，实则是配置或使用反模式，需立即干预：
立即学习“Java免费学习笔记（深入）”；
-
核心线程全部阻塞，队列持续堆积：例如核心线程执行同步HTTP调用，下游响应慢导致线程卡住。此时
getActiveCount() == corePoolSize，getQueue().size()飙升，但getPoolSize()不动——扩容根本没触发，因为队列还没满。修复：将阻塞操作改为异步+超时，或改用SynchronousQueue强制走扩容逻辑。 -
无界队列+低maximumPoolSize：如
new LinkedBlockingQueue()（容量=Integer.MAX_VALUE）搭配maximumPoolSize=4。任务永远进队列，永不触发扩容，最终OOM。修复：显式指定队列容量，如new LinkedBlockingQueue(200)，并配CallerRunsPolicy。 -
拒绝策略失效导致任务静默丢失：用
DiscardPolicy时，任务被丢弃却不记录日志，上游以为成功，实际下游没处理。监控上看“线程不多、队列不涨”，但业务数据缺失。修复：改用AbortPolicy并捕获RejectedExecutionException，或自定义策略写入告警日志。
源码级兜底验证（仅当高度怀疑JDK异常时）
翻阅ThreadPoolExecutor.java（JDK 8u292+ 或 JDK 17+）的addWorker()方法关键逻辑：
该判断在创建任何新线程前执行，且workerCountOf(c)是CAS读取的原子计数。只要JVM内存模型正常、无Unsafe绕过，此处不可能绕过限制。所谓“漏洞”，99.9%是监控方式错误或外部干扰所致。
