不该直接 new thread() 而要用 threadpoolexecutor，因其避免频繁创建销毁线程的开销与 oom 风险，通过复用、限流、队列缓冲和拒绝策略保障稳定性；核心在于合理配置 corepoolsize、maximumpoolsize、workqueue 和 rejectedexecutionhandler 四个参数。
为什么不该直接 new Thread() 而要用 ThreadPoolExecutor
每次 new Thread() 都会创建操作系统线程，开销大、不可控，容易导致 OOM 或 CPU 上下文频繁切换。线程池复用线程、限制并发数、提供队列缓冲和拒绝策略，是生产环境的标配。
核心不是“怎么建”，而是“怎么配”——尤其 corePoolSize、maximumPoolSize、workQueue 和 RejectedExecutionHandler 四个参数组合决定行为边界：
-
corePoolSize不是“最小线程数”，而是“长期保留在池中不销毁的线程数”（除非allowCoreThreadTimeOut=true） -
workQueue用LinkedBlockingQueue容易掩盖问题：它默认无界，任务持续涌入时内存暴涨，最终OutOfMemoryError: Java heap space -
ArrayBlockingQueue更可控，但必须显式指定容量，否则运行时报IllegalArgumentException - 拒绝策略别只用默认的
AbortPolicy（抛RejectedExecutionException），根据场景选CallerRunsPolicy（让调用线程自己执行）或自定义逻辑
Executors 工具类的坑在哪
Executors 提供的静态方法看似方便，但多数封装隐藏了关键配置，不适合生产：
-
Executors.newFixedThreadPool(10)→ 底层用LinkedBlockingQueue（无界），高负载下内存失控 -
Executors.newCachedThreadPool()→corePoolSize=0，maximumPoolSize=MAX_VALUE，空闲 60 秒回收，但突发流量可能瞬间创建数千线程，打爆系统 -
Executors.newSingleThreadExecutor()→ 单线程 + 无界队列，一个任务卡住，后续全部阻塞，且无法监控/干预
正确做法：绕过 Executors，直接用 ThreadPoolExecutor 构造器，明确传入所有参数。
立即学习“Java免费学习笔记（深入）”；
如何设置合理的 corePoolSize 和 maximumPoolSize
没有银弹公式，但有可落地的判断路径：
- CPU 密集型任务（如加解密、数值计算）：
corePoolSize ≈ CPU 核数（可用Runtime.getRuntime().availableProcessors()获取），maximumPoolSize通常不放大，避免上下文切换损耗 - I/O 密集型任务（如 HTTP 调用、DB 查询）：
corePoolSize可设为2 × CPU 核数或更高，因为线程常阻塞；此时更依赖workQueue缓冲，maximumPoolSize视超时容忍度定（比如 50～200） - 混合型任务：先用
Arthas或JFR观察实际线程阻塞率和队列积压情况，再反推调整 - 永远不要把
maximumPoolSize设为Integer.MAX_VALUE—— 这等于放弃控制权
线程池关闭的两个关键动作不能少
应用停机或模块卸载时，仅调用 shutdown() 不够，必须配合等待逻辑，否则正在执行的任务可能被强制中断：
- 先调用
shutdown()：停止接收新任务，已提交任务继续执行 - 再调用
awaitTermination(long timeout, TimeUnit unit)等待完成，超时后视情况调用shutdownNow() -
shutdownNow()会尝试中断正在运行的线程（触发InterruptedException），但**不保证立即停止**——任务代码必须响应中断（检查Thread.interrupted()或捕获异常） - 常见错误：只调
shutdown()就结束，主线程退出，JVM 关闭，未完成任务丢失
真正难的不是创建线程池，而是让它在各种负载波动和生命周期边界下都行为可预期——参数不是设一次就完事，得结合监控（如 getActiveCount()、getQueue().size()）持续调优。
