java线程池拒绝任务时可通过自定义rejectedexecutionhandler将任务序列化后存入mq实现降级保活，需设计可序列化任务包装器、mq持久化策略、消费端还原执行及幂等处理，并集成验证可靠性。
<p>Java 线程池无法直接执行新任务时（如队列满 + 线程数达最大），会触发拒绝策略。默认策略（如 AbortPolicy）直接抛异常，但生产环境常需“降级保活”——把被拒任务暂存到消息队列（MQ），后续异步重试或补偿处理。这需要自定义 <code>RejectedExecutionHandler</code>，并确保任务可序列化、MQ 可靠写入。</p> <h3>实现可序列化的任务包装器</h3> <p>线程池拒绝的是 <code>Runnable</code> 或 <code>Callable</code>，它们通常不满足跨进程传输要求。需封装成可序列化对象，包含原始逻辑、参数、执行上下文等：</p>
- 定义一个
SerializableTask类，实现Serializable，字段包括：任务类型标识、JSON 序列化后的参数、时间戳、重试次数、唯一 traceId； - 避免直接持有不可序列化对象（如 Spring Bean、Connection、ThreadLocal 变量），所有依赖应在消费端重新获取；
- 推荐使用 Jackson 的
ObjectMapper将业务参数转为 JSON 字符串存入字段，而非直接序列化整个 Runnable 实例（易引发 ClassNotFind 或 transient 问题）。
编写 MQ 持久化拒绝策略
继承 RejectedExecutionHandler，在 rejectedExecution 方法中完成 MQ 发送：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 构造
SerializableTask实例，填充任务元信息和参数快照； - 调用 MQ 客户端（如 RocketMQ 的
DefaultMQProducer.send()、RabbitMQ 的Channel.basicPublish()）发送消息； - 必须做异常兜底：若 MQ 不可用，写本地磁盘文件（如日志+时间戳命名的 JSON 文件）或内存队列（带定时刷盘），防止任务丢失；
- 建议设置超时（如 2s）和重试（最多 2 次），避免阻塞线程池的拒绝流程。
MQ 消费端任务还原与执行
独立服务监听 MQ，反序列化并还原任务逻辑：
- 消费到消息后，解析
SerializableTask，根据 type 字段路由到对应处理器（如OrderCreateHandler）； - 从 JSON 参数重建业务对象，调用实际业务方法；
- 执行成功则 ACK；失败时记录错误日志，按策略重投（如延迟重试、进死信队列）；
- 注意幂等性：用 traceId 或业务唯一键做去重，防止 MQ 重复投递导致重复执行。
集成到线程池并验证可靠性
将自定义策略注入 ThreadPoolExecutor，并配合合理参数使用：
- 创建线程池时传入：
new ThreadPoolExecutor(core, max, keepAlive, unit, queue, threadFactory, new MqBackupPolicy())； - 队列建议用有界队列（如
ArrayBlockingQueue），避免内存无限增长；容量需结合 QPS 和平均耗时估算； - 压测验证：模拟高并发打满队列+线程池，检查 MQ 是否收到对应数量消息、消费端是否正确执行、异常场景下是否有落盘备份；
- 监控关键指标：拒绝任务数、MQ 发送成功率、消费延迟、死信队列堆积量。
不复杂但容易忽略细节：任务设计要轻量可序列化、MQ 写入要有超时和降级、消费端必须保障幂等与重试。这样既守住线程池稳定性，又不让业务请求真正丢失。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
