核心是用好线程池弹性复用机制，需手动构造ThreadPoolExecutor并显式配置七参数，启用allowCoreThreadTimeOut与SynchronousQueue，按任务类型动态设定线程数，并拦截所有隐式线程创建路径。
核心是用好线程池的弹性复用机制，而不是靠“少建”或“不建”来规避问题。关键在于让线程真正活下来、稳下来、按需伸缩，同时堵住所有隐式创建线程的漏洞。
用 ThreadPoolExecutor 替代 Executors 工厂方法
Executors.newFixedThreadPool() 和 newCachedThreadPool() 看似方便，实则埋雷：
- FixedThreadPool 底层用的是无界 LinkedBlockingQueue，任务持续涌入时会无限堆积，最终 OOM；
- CachedThreadPool 的 maximumPoolSize 是 Integer.MAX_VALUE，高并发下线程数暴增，直接触发 “unable to create new native thread”；
- 两者都缺失对 workQueue 容量、拒绝策略、线程命名等关键控制点的显式定义。
应手动构造 ThreadPoolExecutor，明确指定全部七个参数，尤其要控制队列有界、线程数上限、拒绝策略可兜底。
设置合理的存活策略：keepAliveTime + allowCoreThreadTimeOut
默认情况下，corePoolSize 内的线程永不销毁，长期空闲也会占着 1MB 栈内存（-Xss 默认值），造成资源僵化。真正可控的弹性依赖两个联动配置：
立即学习“Java免费学习笔记（深入）”；
- keepAliveTime 设为 30–60 秒：非核心线程空闲超此时长即回收，该值建议略高于业务最长非阻塞等待（如 RPC 超时、DB 查询阈值）；
- allowCoreThreadTimeOut(true)：启用后，连核心线程也遵守 keepAliveTime，整个池具备收缩能力，避免低峰期线程“只增不减”；
- 搭配 workQueue = SynchronousQueue：不缓存任务，逼迫任务立即由空闲线程处理或触发扩容，防止队列掩盖线程滥用问题。
按任务类型精准设定线程数，杜绝盲目放大
线程数不是越大越好，错配反而加剧抖动：
- CPU 密集型任务：线程数 ≈ CPU 逻辑核心数（可用 Runtime.getRuntime().availableProcessors() 获取），过多线程只会引发频繁上下文切换；
- I/O 密集型任务：初始值可设为 CPU 核心数 × (1 + 平均等待时间 / 平均计算时间)，再通过压测（JMeter/Gatling）调优至吞吐量与响应时间最优平衡点；
- 避免固定写死数字，推荐结合运行时环境动态计算，例如 corePoolSize = Math.max(2, availableProcessors)。
拦截所有隐式线程创建路径
很多性能抖动并非来自主业务线程池，而是被忽略的“角落”：
- 禁止在 @Controller、@Service 方法内直接 new Thread() 或使用 Timer；
- 检查第三方 SDK（如某些老版本 Druid 连接池、Log4j 异步 Appender、旧版 OkHttp）是否自带未受管线程；
- HTTP 客户端、RPC 框架、定时任务调度器（如 Quartz）、消息监听容器（如 KafkaListener）都应配置独立、有监控的线程池，而非共用 common-pool；
- 借助 Arthas 或 jstack 定期 dump 线程栈，统计线程名分布，识别未命名或命名混乱的线程来源。
不复杂但容易忽略
