应使用显式配置的 threadpoolexecutor 替代 new thread，合理设置 corepoolsize、maximumpoolsize、有界队列、keepalivetime 与 allowcorethreadtimeout，并统一管控框架隐式创建线程，配合拒绝策略与关键监控指标保障线程资源可控。
直接用 new Thread() 启动任务，每次都要分配栈内存（默认 1MB）、注册调度器、初始化 ThreadLocal、触发内核态切换——这些动作加起来不是“毫秒级”，而是实实在在拖慢系统、吃光内存、引发 CPU 抖动的根源。避免频繁创建销毁，核心就一条：**让线程活下来、复用起来、可控收缩**。
用 ThreadPoolExecutor 替代裸 new Thread
线程池不是“套个 Executors 工厂方法”就完事。必须显式构造 ThreadPoolExecutor，掌控关键参数：
- corePoolSize 设为业务稳定期所需的最小并发数（如 4～8），这部分线程默认常驻
- maximumPoolSize 要设合理上限（比如不超过 CPU 核数 × 2～4），防止突发流量拉爆线程数
-
workQueue 别用
LinkedBlockingQueue（无界=掩耳盗铃），优先选ArrayBlockingQueue或SynchronousQueue，让容量瓶颈暴露出来
启用弹性存活策略
默认 core 线程永不销毁，容易僵化占资源。真正可控的收缩靠两个联动配置：
- keepAliveTime = 30～60 秒：非核心线程空闲超时即回收；值要略高于你最长的非阻塞等待（如 RPC 超时）
- allowCoreThreadTimeOut(true)：开启后，连 core 线程也遵守 keepAliveTime，整个池可随负载自然伸缩
拦截所有隐式线程创建点
很多线程不是你主动 new 的，而是框架偷偷起的。必须全局管控：
- HTTP 请求处理中禁用每个请求起线程，统一走 Web 容器线程池或自定义业务池
- 定时任务（如 @Scheduled）不要在方法里 new Thread，改用
TaskScheduler配置专用池 - RPC 回调、消息监听器、异步日志等场景，全部注入受管线程池，不许裸调
start() - 用
jstack定期检查线程名，发现未命名或命名混乱的线程，立刻溯源整改
配合适当拒绝策略与监控
线程池不是万能保险丝，过载时必须有明确响应边界：
- 日志/埋点类任务用
DiscardPolicy（静默丢弃），避免阻塞主流程 - 关键业务任务可包装重试逻辑，或降级为同步执行（慎用
CallerRunsPolicy） - 监控指标必须包括：当前活跃线程数、队列积压量、拒绝任务数、GC 中 Eden 区存活率 —— 这些才是线程是否“雪崩”的真实信号
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
