应显式使用ThreadPoolExecutor替代Executors.newFixedThreadPool(n)，指定有界队列（如ArrayBlockingQueue）、合理拒绝策略（如CallerRunsPolicy）、自定义ThreadFactory（命名+非守护）及shutdown钩子，避免OOM与资源泄漏。
直接用 ThreadPoolExecutor 替换 Executors.newFixedThreadPool(n)，核心是补全被工厂方法隐藏的关键控制项——尤其是拒绝策略、队列类型和线程工厂，避免默认陷阱。
必须显式指定拒绝策略，别依赖默认的 AbortPolicy
newFixedThreadPool 底层用的是无界队列 + AbortPolicy，但队列实际会无限增长，导致 OOM；而手动构造时若不设拒绝策略，也会沿用 AbortPolicy，任务被丢弃还不报错。应根据业务选择更稳妥的策略：
- CallerRunsPolicy：适合可接受轻微阻塞调用方的场景，让提交线程自己执行任务，自然降速
- DiscardOldestPolicy：适合实时性要求高、旧任务可丢弃的场景（如监控上报）
- 自定义策略记录日志或触发告警，便于问题追溯
用有界队列替代 LinkedBlockingQueue，主动控制积压上限
newFixedThreadPool 默认使用无界 LinkedBlockingQueue，这是最隐蔽的风险点。手动声明时必须换成有界队列，并合理设置容量：
- 选
ArrayBlockingQueue（公平/非公平可选），容量建议设为corePoolSize × 2 ~ × 4，兼顾缓冲与可控性 - 避免用
SynchronousQueue（除非你明确需要纯传递、零缓冲），它会让所有任务都直奔线程创建，容易触发最大线程数膨胀 - 队列满 + 线程数达 maximumPoolSize 时，才会真正触发拒绝策略——这才是你想要的背压机制
传入自定义 ThreadFactory，统一命名+关闭守护线程
默认线程名是 pool-N-thread-M，排查问题困难；且默认线程非守护，可能阻碍 JVM 正常退出。替换时务必提供：
- 有意义的前缀，比如
"order-processor-pool"，方便日志和 jstack 识别 - 设置
setDaemon(false)（非守护），确保主线程结束时线程池能被正确 shutdown - 可选：添加
UncaughtExceptionHandler捕获未处理异常，防止静默失败
初始化后务必暴露 shutdown 钩子，避免资源泄漏
工厂方法返回的 ExecutorService 往往被当成“即用即弃”，但手动构造的实例需主动管理生命周期：
- 在 Spring Bean 中用
@PreDestroy调用shutdown()或shutdownNow() - 非 Spring 环境，在应用关闭流程中显式调用，例如注册 JVM Shutdown Hook
- 避免只声明不管理，否则线程长期存活，GC 不回收，内存和句柄持续占用
替换不是简单改构造函数，而是把原来被封装掉的决策显性化、可配置化、可观察化。每处替换后，建议加一行注释说明队列容量、拒绝策略和线程命名规则，方便后续维护。
