让我来帮你拆解这个问题的核心原因，以及如何调整代码实现你想要的“故障时消息回退队列”的需求：

为什么消息会丢失？ #

你遇到的问题本质是IBM MQ JMS客户端对CLIENT_ACKNOWLEDGE模式的特殊处理，加上你的异常捕获逻辑导致消息被错误确认：

1. CLIENT_ACKNOWLEDGE的监听器行为差异
   按照JMS规范，CLIENT_ACKNOWLEDGE确实要求手动调用message.acknowledge()来确认消息，但IBM MQ的JMS客户端针对消息监听器（MessageListener）场景做了特殊优化：如果onMessage方法正常返回（没有抛出任何RuntimeException），哪怕你没调用acknowledge()，MQ会自动将这条消息标记为已确认，直接从队列中移除。

2. 你的异常捕获逻辑“掩盖”了失败
   你在onMessage里捕获了所有Throwable，这意味着无论业务处理或数据库写入出现什么问题，onMessage方法都会平稳结束，不会向JMS容器抛出异常。此时MQ触发自动确认逻辑，把消息从队列中删掉，但你既没成功处理消息，也没把它存入故障数据库，最终就出现了“消息丢失”的情况——既不在原队列，也找不到踪迹。

怎么解决？ #

根据你的需求，推荐两种可靠的方案：

方案1：改用事务模式（最稳妥） #

放弃CLIENT_ACKNOWLEDGE，改用SESSION_TRANSACTED事务模式，把消息处理和确认绑定到事务中：

首先修改JMSContext的创建逻辑：

private JMSContext createJmsContext() throws JMSException { 
    JmsConnectionFactory cf; 
    JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER); 
    cf = ff.createConnectionFactory(); 
    // 保留你的所有连接配置（主机、端口、通道等）
    // 无需设置ACKNOWLEDGE_MODE，直接创建事务型上下文
    return cf.createContext(JMSContext.SESSION_TRANSACTED); 
}

然后调整监听器的处理逻辑：

consumer.setMessageListener(message -> { 
    JMSContext context = (JMSContext) message.getJMSContext();
    try { 
        // 执行你的业务逻辑
        // 尝试将处理结果存入数据库
        context.commit(); // 一切正常，提交事务（消息被确认）
    } catch (Throwable e) { 
        try { 
            // 业务处理失败，尝试写入专用故障数据库
            context.commit(); // 写入成功，提交事务
        } catch (Throwable dbError) { 
            // 数据库也故障了，回滚事务，消息自动返回队列
            context.rollback(); 
            sleep(60_000); // 暂停避免频繁重试
        } 
    } 
});

• 事务模式下，只有调用commit()才会真正确认消息；rollback()会直接把消息放回原队列（或根据MQ配置进入重试队列/死信队列）。
• 记得给队列配置合理的回退阈值（Backout Threshold）和死信队列（Dead Letter Queue），避免消息无限循环重试。

方案2：调整CLIENT_ACKNOWLEDGE的异常处理 #

如果坚持使用CLIENT_ACKNOWLEDGE，你需要让JMS容器感知到处理失败，触发消息回退：

consumer.setMessageListener(message -> { 
    boolean isProcessed = false;
    try { 
        // 业务逻辑处理
        // 尝试写入数据库
        message.acknowledge(); 
        isProcessed = true;
    } catch (Throwable e) { 
        try { 
            // 业务失败，写入故障数据库
            message.acknowledge(); 
            isProcessed = true;
        } catch (Throwable dbError) { 
            // 数据库也挂了，主动抛出RuntimeException让JMS容器处理
            throw new RuntimeException("Failed to process message and store error", dbError);
        } 
    } finally {
        if (!isProcessed) {
            // 兜底：确保未成功处理时抛出异常
            throw new RuntimeException("Message processing failed unexpectedly");
        }
    }
});

• 当处理失败且无法写入故障数据库时，主动抛出RuntimeException，JMS容器会识别到处理失败，不会自动确认消息，而是将消息放回队列。
• 这种方式依赖MQ对监听器异常的处理逻辑，不如事务模式稳定。

额外提醒 #

• 检查你的JMSContext生命周期：不要过早关闭上下文，否则未确认的消息可能被MQ误判为已处理。
• 配置MQ队列的重试策略：如果消息频繁回退，可设置重试次数，超过后转移到死信队列，避免阻塞正常业务。

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