应手写 ThreadPoolExecutor 替代 Executors 工厂方法，因其无界队列易致 OOM、无限建线程引发内存与 CPU 飙升；需显式配置有界队列、合理线程数及拒绝策略，并规范异常处理与监控联动。
别用 Executors 工厂方法创建线程池来管大规模任务——它默认配置在高并发下极易触发 OOM 或 CPU 飙升。
为什么 newFixedThreadPool 会在线上崩掉
它背后是 ThreadPoolExecutor，但用了无界 LinkedBlockingQueue。一旦任务提交速度远超执行速度（比如批量导出、突发 HTTP 请求），队列会无限堆积，最终耗尽堆内存。这不是理论风险，而是线上真实发生的 OOM 场景。
- 核心线程数固定，但队列不设限 → 内存持续增长
- 没有拒绝策略（默认是
AbortPolicy，但只在队列满+线程数达上限时触发，而这里队列永不满） - 监控困难：
getQueue().size()可能高达几十万，但线程池状态仍是RUNNING
newCachedThreadPool 在流量尖峰时为何更危险
它用的是 SynchronousQueue + 核心线程数为 0 + 最大线程数 Integer.MAX_VALUE。这意味着：没空闲线程时，每个新任务都直接新建线程。短时间涌入 1000 个请求，就可能瞬间拉起 1000 个线程。
- 线程栈默认占用 1MB（64 位 JVM），1000 个线程 ≈ 1GB 栈内存，还没算业务对象
- CPU 上下文切换开销爆炸，吞吐反而断崖下跌
- 即使设置了
keepAliveTime = 60L，也救不了瞬时创建的雪崩
必须手写 ThreadPoolExecutor 的三个关键参数
用 new ThreadPoolExecutor(...) 替代所有 Executors.xxx 调用。重点配这三项：
-
corePoolSize：根据 CPU 密集型（≈ CPU 核数）或 I/O 密集型（通常 ×2～×4）预估，别拍脑袋填 10 -
workQueue：绝不用LinkedBlockingQueue；改用有界队列如new ArrayBlockingQueue(100)，明确容量上限 -
handler：必须显式指定拒绝策略，例如new ThreadPoolExecutor.CallerRunsPolicy()（让调用线程自己执行），避免丢任务又不报警
示例：new ThreadPoolExecutor(4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), r -> new Thread(r, "batch-worker-%d"), new ThreadPoolExecutor.CallerRunsPolicy())
submit() 和 execute() 的异常处理不能省
两者对异常的“可见性”完全不同：
-
execute(Runnable)中抛出未捕获异常 → 线程 silently die，仅靠Thread.setDefaultUncaughtExceptionHandler捕获，难定位 -
submit(Callable)的异常被包装进ExecutionException，必须调future.get()才抛出；漏掉这步，异常就永远沉底了 - 批量任务建议统一用
invokeAll()并遍历每个Future的get()，否则失败任务无声无息
真正的大规模场景里，线程池不是“建完就跑”，而是要和熔断、降级、指标上报联动——队列积压超阈值就得告警，拒绝率 > 1% 就该自动扩容或切流。这些细节，工厂方法根本没留钩子。
