毒丸消息是内容非法、格式错误或触发永久性业务异常的消息，如json解析失败、关键字段缺失等；其处理核心是隔离、可控退出与可追溯，需在入口轻量校验、外层try-catch捕获throwable、自动转入带元数据的dlq，并配置超时、熔断与监控。
毒丸消息（Poison Message）是指内容非法、格式错误或触发永久性业务异常的消息，比如 JSON 解析失败、关键字段缺失、ID 为 null 却被强转 Long 等。这类消息一旦被消费者拉取，常规重试只会反复失败，最终导致线程卡死、消费停滞，甚至拖垮整个消费者实例。Java 消息队列中处理它，核心不是“拦住”，而是“隔离 + 可控退出 + 可追溯”。
识别并快速标记毒丸消息
不能等异常层层抛到线程顶层才处理。要在业务逻辑入口做轻量校验：
- 收到消息后，先做基础结构检查：是否为空、是否能反序列化成预期对象（用 try-catch 包裹 Jackson/Gson 的 parse）、关键字段是否存在且非空
- 避免在反序列化前就调用业务方法（如直接 msg.getBody().toString() 再 parse），防止 NPE 或 ClassCastException 提前炸掉线程
- 对已知高风险类型（如老版本遗留消息、第三方推送的不规范 payload）加白名单或 schema 校验钩子
消费线程不崩溃的关键：不抛出未捕获异常
绝大多数 MQ 客户端（如 KafkaConsumer、RocketMQ DefaultMQPushConsumer、RabbitMQ Channel）要求 consume 方法必须返回明确状态（如 CONSUME_SUCCESS / RECONSUME_LATER）。若业务代码抛出未捕获异常，框架可能静默吞掉或直接终止该线程。
- 务必在 consume 方法最外层用 try-catch 包住全部业务逻辑，捕获 Throwable（不只是 Exception）
- 对确认失败的消息，不要简单 return null 或 throw new RuntimeException("xxx")，而要按 SDK 规范返回重试/跳过/死信标识
- 例如 RocketMQ 中：catch 到毒丸后，记录日志 + 发送到 DLQ Topic + 返回 CONSUME_SUCCESS（避免重复投递）
自动转入死信队列（DLQ）并留痕
DLQ 不是可选功能，而是生产环境的必需基建。它让毒丸脱离主链路，同时保留上下文供排查：
- 配置消费者端自动转发：如 Kafka 可结合 Spring Kafka 的 DefaultAfterRollbackProcessor，设置 maxFailures 后发往 dlq-topic；RocketMQ 支持 setMaxReconsumeTimes(16) + 自动投递到 %RETRY% 重试组，再由运维脚本将超限消息导出到 DLQ Topic
- 转发时补全元数据：把原始 topic、offset、timestamp、消费失败堆栈、消息体摘要（如前 200 字符）一并写入 DLQ，避免“只知失败、不知为何”
- DLQ 本身也要有监控：堆积量突增、消费延迟超过阈值，立刻告警，说明主流程可能批量产生毒丸
兜底防护：消费线程生命周期可控
即使毒丸漏过前几层，也不能让单个线程 hang 死或 OOM：
- 给每个 consume 调用加超时控制，例如用 CompletableFuture.orTimeout(3, TimeUnit.SECONDS)，超时则主动中断并标记为可疑消息
- 消费者实例启动时注册 JVM Shutdown Hook，确保进程退出前尝试提交 offset 或刷新 DLQ 缓存
- 避免在 consume 方法里做阻塞 I/O（如同步调用 HTTP 接口、读大文件），必须做则套上熔断器（如 Hystrix / Resilience4j）和超时
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
