threadpoolexecutor手动配置需坚持“有界队列+明确拒绝策略+动态回收”原则：选用arrayblockingqueue等有界队列防oom，弃用默认无界队列；拒绝策略优选callerrunspolicy或自定义兜底逻辑；启用allowcorethreadtimeout(true)实现低峰期资源回收。
直接用 ThreadPoolExecutor 手动配置 + 合理的设计模式，就能把线程池从“黑盒忙等”变成“可观察、可调控、可兜底”的生产级组件。关键不是堆参数，而是让每个环节有明确职责和响应逻辑。
核心思路：用有界队列 + 明确拒绝策略替代无界堆积
Executors 的问题本质是“默认不做约束”——LinkedBlockingQueue() 默认容量是 Integer.MAX_VALUE，任务来了就塞，不管线程是否忙、内存是否扛得住。手动创建时必须打破这个惯性：
- 选 ArrayBlockingQueue 或 LinkedBlockingQueue(固定容量)，比如
new ArrayBlockingQueue(200)，硬性卡住缓冲上限； - 拒绝策略不用默认的
AbortPolicy（直接抛异常中断流程），改用CallerRunsPolicy（由提交线程自己执行）或自定义策略（如落库重试、发告警、降级返回）； - 搭配
allowCoreThreadTimeOut(true)，让核心线程在低谷期也能回收，避免资源常驻浪费。
组合模板模式：统一构建 + 场景化适配
不同业务对线程池的要求差异很大，硬编码一堆 new ThreadPoolExecutor 不可持续。用模板模式封装共性，暴露可变点：
- 定义抽象基类
BaseThreadPoolBuilder，封装 workQueue、threadFactory、handler 等通用配置； - 子类如
IoIntensivePoolBuilder设置core = CPU×2、max = CPU×4、keepAlive = 120s； - 子类如
CpuIntensivePoolBuilder则设core = CPU+1、max = core、keepAlive = 30s，并禁用非核心线程； - 所有构建器最终调用同一套
build()方法，确保日志命名、异常处理器、监控埋点一致。
嵌入观察者模式：实时感知线程池状态
线程池不能只管“跑”，还要让人知道它“跑得怎么样”。通过定时采集关键指标，触发观察者行为：
- 每 30 秒检查
getActiveCount()、getQueue().size()、getCompletedTaskCount()； - 当队列使用率 > 80% 持续 2 分钟，自动触发告警并记录堆栈（
executor.getQueue().peek()可辅助定位慢任务）； - 结合 Micrometer 或 Prometheus，暴露
thread_pool_active_threads、thread_pool_queue_size等指标，接入 Grafana 看板； - 拒绝任务时，不只是打日志，同步发布
TaskRejectEvent事件，由监听器做补偿（如写入延迟队列、推送企业微信）。
配合责任链模式：任务提交前做轻量预检
很多 OOM 其实源于任务本身不合理（如传入超大对象、未设超时）。在线程池外加一层“守门人”：
- 实现
TaskPreprocessor接口，链式串联：大小校验 → 超时包装 → MDC 上下文透传 → 限流令牌检查； - 提交任务时不直调
submit(runnable)，而是走taskChain.process(task)； - 某环校验失败（如序列化后 > 1MB），立即拒绝，不进队列、不占线程，避免污染整个池；
- 该链可按业务模块开关，例如支付任务开全链，日志异步任务只开上下文透传。
