直接 new Thread() 会拖垮系统，因每创建一个线程需分配1MB栈内存、触发内核调度、带来创建/销毁开销，高并发下易导致OOM、上下文切换爆炸和延迟飙升；线程池是Java并发基础设施，应避免Executors工厂方法的陷阱，优先使用显式配置的ThreadPoolExecutor。
为什么直接 new Thread() 会拖垮系统
每创建一个 Thread 对象，JVM 就要分配栈内存（默认 1MB）、触发内核线程调度、经历创建/销毁开销。高并发下频繁新建线程会导致：OOM（堆外内存耗尽）、CPU 上下文切换爆炸、响应延迟飙升。线程池不是“可选优化”，而是 Java 并发的基础设施。
Executors 工厂方法的坑必须避开
Executors 提供的静态方法看似方便，但多数在生产环境是危险的：
-
Executors.newFixedThreadPool(n)：底层用的是无界LinkedBlockingQueue，任务持续堆积会吃光堆内存 -
Executors.newCachedThreadPool()：最大线程数为Integer.MAX_VALUE，突发流量可能瞬间创建数千线程，直接把机器压垮 -
Executors.newSingleThreadExecutor()：单线程，无法利用多核，且未暴露ThreadPoolExecutor的可调参数
正确做法是直接构造 ThreadPoolExecutor，明确控制核心线程数、最大线程数、队列容量和拒绝策略：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // corePoolSize
8, // maximumPoolSize
60L, // keepAliveTime
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100), // 有界队列，防内存溢出
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝时由提交线程自己执行
);如何设置 corePoolSize 和 maximumPoolSize
没有银弹公式，但有可落地的判断逻辑：
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型任务（如加解密、图像处理）：
corePoolSize ≈ CPU 核数（Runtime.getRuntime().availableProcessors()），maximumPoolSize通常不放大，避免上下文切换损耗 - I/O 密集型任务（如数据库查询、HTTP 调用）：
corePoolSize可设为2 × CPU 核数或更高，因为线程常阻塞在 I/O，需要更多线程维持吞吐 - 混合型任务：先按 I/O 密集估算，再通过压测观察 CPU 使用率和 GC 频率，动态调整
注意：corePoolSize 是长期存活的线程数；maximumPoolSize 只有在队列满且当前线程数 maximumPoolSize 时才会创建新线程——这个“扩容”行为本身就有成本，别指望它扛住突发流量。
拒绝策略不是兜底，而是业务决策点
当线程池饱和（队列满 + 线程数达上限）时，第 101 个任务不会排队等待，而是触发拒绝策略。四种内置策略含义截然不同：
-
AbortPolicy（默认）：抛RejectedExecutionException，适合能主动重试或降级的场景 -
CallerRunsPolicy：由submit()所在线程同步执行该任务，会降低提交速度，但能自然抑制上游流量 -
DiscardPolicy：静默丢弃，适合日志、埋点等非关键任务 -
DiscardOldestPolicy：丢弃队列头任务，腾出位置提交当前任务——可能破坏任务时序，慎用
真正关键的是：**拒绝发生时，你的监控是否告警？业务是否记录了丢弃量？下游是否感知到失败？** 把拒绝当成异常来处理，而不是配置完就不管。
线程池不是配置一次就能躺平的组件。队列类型、拒绝策略、线程工厂命名、拒绝后是否重试、是否集成 Micrometer 暴露活跃线程数/队列长度——这些细节漏掉任何一个，都可能让压测数据漂亮，上线后第一波流量就出问题。
