RabbitMQ消费者Lambda回调中GzipUtil.unzip方法未执行问题排查

以下是该问题的核心原因及对应排查方向：

• 消费线程异常被吞：RabbitMQ Java客户端的消费回调默认运行在ConsumerWorkService管理的独立线程池中，若你的try-catch仅捕获Exception类型，当解压逻辑触发Error类抛出（比如类加载上下文不一致导致的NoClassDefFoundError、解压大文件触发的OutOfMemoryError），这类异常不会被Exception捕获，会直接被线程池的默认未捕获异常处理器丢弃，表现为代码块无执行痕迹也无报错。你单独运行时用的是主线程类加载器，不存在上下文差异，所以能正常执行。
• 入参实际值与测试样本不一致：你打印的payloadString看起来和测试样本一致，但可能存在不可见空白字符、编码不匹配问题（比如消息体转字符串时用的字符集和测试时不一致），如果GzipUtil.unzip内部对不符合格式的入参做了静默返回处理（比如入参格式不对直接返回null无日志），就会看起来像方法未执行。
• 变量可见性问题：如果解压后的结果赋值给了Lambda外部的成员变量，未做可见性修饰的情况下，你在其他线程读取该变量时会拿到旧值，误以为解压逻辑没有运行。
• 自动ack导致线程提前销毁：若你配置了autoAck=true，消息推送到客户端后会立即确认，消费线程可能在解压逻辑执行完成前就被回收，导致代码执行中断无输出。

排查方案：

1. 将try-catch的捕获范围调整为Throwable，打印全量堆栈，确认是否有未捕获的错误抛出
2. 在GzipUtil.unzip方法入口添加日志打印，确认方法是否被实际调用
3. 打印payloadString的字节数组和测试样本的字节数组做对比，排除编码和不可见字符问题
4. 关闭autoAck改为手动ack，消费逻辑全部执行完成后再调用basicAck确认消息

内容的提问来源于stack exchange，提问作者sjantke