核心是切断锁争用路径而非压线程数：预热/禁用扩容避免mainLock征用；换SynchronousQueue或ConcurrentLinkedQueue降队列锁；计数用LongAdder、拒绝策略异步化；入口限流+有界队列防Worker爆发。
Java处理高并发下线程池瞬时创建大量Worker引发的锁竞争，核心不是“压住线程数”，而是切断锁争用路径——尤其要避开ThreadPoolExecutor内部对mainLock（全局可重入锁）的高频征用。当突发流量触发线程扩容（比如从 corePoolSize 快速涨到 maximumPoolSize），多个线程同时调用addWorker()，就会在该锁上排队，形成热点瓶颈。
避免mainLock成为争用焦点
ThreadPoolExecutor 的线程创建、状态变更、任务队列操作等关键路径都受 mainLock 保护。瞬时大量 Worker 创建会集中冲击这把锁。解决思路是：让线程创建行为尽量不依赖它。
- 预热线程池：在流量高峰前，主动调用
prestartAllCoreThreads()或prestartCoreThread()，使核心线程就位，避免请求来临时才抢锁建线程； - 禁用动态扩容：将
corePoolSize == maximumPoolSize，线程数恒定，彻底消除扩容阶段的锁竞争； - 改用无锁/低锁替代方案：例如使用
ForkJoinPool.commonPool()处理 CPU 密集型短任务（其 work-stealing 机制天然规避中心锁），或接入自适应线程池（如 Spring Cloud 的 DynamicThreadPool），它通过异步采样+延迟更新策略，绕开同步锁做线程数调整。
替换高争用队列实现
默认的 LinkedBlockingQueue 虽线程安全，但 put() 和 take() 共享一把锁（即使用了双锁分离，仍存在锁边界）。瞬时大量任务提交会导致队列头/尾锁争用加剧。
- 读多写少场景：选用
ConcurrentLinkedQueue（无锁、CAS 实现），适合非阻塞、允许瞬时丢弃或降级的场景； - 需阻塞语义但要求高吞吐：用
SynchronousQueue+Direct handoff模式，任务不入队，直接移交空闲线程，完全规避队列锁； - 若必须用有界队列：优先选
ArrayBlockingQueue（单锁但数组结构缓存友好），而非LinkedBlockingQueue（链表+双锁，GC 和缓存行失效更严重）。
用原子化结构替代共享状态锁
很多自定义线程池监控、拒绝策略、任务计数逻辑，习惯用 synchronized 或 ReentrantLock 保护共享变量（如总执行数、失败数），这会在高并发下成为新热点。
立即学习“Java免费学习笔记（深入）”；
- 计数类指标统一用
LongAdder或DoubleAdder：它们采用分段累加+最终合并策略，比AtomicLong在高并发下性能高出数倍； - 拒绝策略避免同步日志：不要在
RejectedExecutionHandler中直接写同步文件或调用慢速 RPC，改用异步日志框架（如 Log4j2 AsyncLogger）或内存缓冲后批量落盘； - 线程工厂注入唯一标识：用
ThreadLocalRandom或原子递增 ID 生成线程名，避免多线程争用同一字符串拼接锁。
从源头控制Worker爆发节奏
瞬时大量 Worker 往往是下游响应变慢、任务积压倒逼线程池“病急乱投医”扩容所致，并非真实需要那么多并发线程。
- 设置合理 keepAliveTime（建议 ≥ 60 秒）：避免线程刚建好又销毁，反复触发锁；
- 用有界队列 + 拒绝策略兜底：例如
AbortPolicy配合熔断（Sentinel/Hystrix），让上游快速失败，而不是堆积任务、倒逼扩容； - 引入平滑限流：在入口层（如网关）用令牌桶或漏桶压制瞬时流量，使线程池接收节奏可控，从根本上减少 Worker 爆发需求。
