防任务丢失关键在于“接得住、记得住、兜得牢”，需选对拒绝策略（如callerrunspolicy）、配好有界队列、加可追溯兜底机制；监控须覆盖队列使用率、拒绝数等动态指标；支持参数热更新与平滑缩容。
要防任务丢失，关键不是堆大参数，而是让线程池在过载时仍能“接得住、记得住、兜得牢”。核心落在三点：选对拒绝策略、配好有界队列、加一层可追溯的兜底机制。
用 CallerRunsPolicy + 有界队列作为第一道防线
这是80%常规业务最稳妥的选择。当线程池满（核心线程跑满 + 队列填满 + 非核心线程达上限）时，CallerRunsPolicy 不丢任务、不抛异常，而是让提交任务的线程（比如 Tomcat 的请求线程）直接执行该任务。
- 必须搭配有界队列（如 ArrayBlockingQueue），容量建议按公式估算：队列容量 ≈ 核心线程数 × 平均任务耗时（秒）× 2，避免无界队列引发 OOM
- 注意调用线程执行不能太慢——单任务若超 500ms，会拖慢整个请求链路；可考虑拆分逻辑或标记为“非阻塞型任务”走另一通道
- 适用于注册、状态更新、日志上报等“宁可慢一点，也不能丢”的场景
监控指标必须覆盖运行时真实水位
只看“活跃线程数”或“队列大小”远远不够。真正反映风险的是动态负载关系：
- 重点采集：队列使用率（当前大小 / 容量）、拒绝任务累计数、任务平均执行耗时、线程空闲时长分布
- 暴露方式推荐 Spring Boot Actuator 自定义端点（如 /actuator/threadpool）+ Prometheus 打点，用 Gauge 实时反映队列水位，Counter 累计拒绝次数
- 设置告警阈值：例如队列使用率持续 >75% 且拒绝率 1 分钟内 >1%，就触发通知，而不是等线程池彻底打满才响应
自定义拒绝策略做最终兜底
当 CallerRunsPolicy 也无法缓解（比如调用线程本身已饱和），就需要把任务“暂存下来”，后续重试：
- 拒绝时将任务序列化后写入消息队列（如 RocketMQ/Kafka）或高可用数据库，附带唯一 ID 和时间戳
- 配套定时任务或监听器消费这些“被拒任务”，支持幂等校验与最大重试次数（如 3 次）
- 注意脱敏处理：入参摘要需过滤敏感字段，防止日志或存储泄露用户信息
参数必须支持运行时热更新
硬编码或 yml 静态配置无法应对突发流量。应接入 Nacos/Apollo：
- 监听 corePoolSize、maxPoolSize、queueCapacity 等变更，调用 setCorePoolSize() 等方法实时生效
- 更新前做合法性校验（如 max ≥ core、queueCapacity > 0），失败则自动回滚并记录 ERROR 日志
- 缩容要滞后平滑：流量回落 10 分钟后，再按每 5 分钟减 1 个线程（不低于 core 数），避免抖动
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
