Spring JMSTemplate+ArtemisMQ批量发送报UncategorizedJmsException异常

我之前在做上万条规模的JMS批量推送时，碰到过和你完全一样的问题——系统平时运行毫无异常，一到批量任务就抛出这个UncategorizedJmsException，核心就是嵌套的java.lang.InterruptedException。结合踩坑经验，给你梳理下可能的原因和解决思路：

核心原因拆解 #

InterruptedException本质是线程被强制中断，在批量发送场景下，通常和资源耗尽、超时设置不合理或者发送逻辑低效有关，咱们逐个分析：

1. 线程池资源不足或超时设置过短 #

如果你的JMS发送依赖线程池（比如Spring的TaskExecutor或JMS客户端自带线程池），批量发送时线程被占满，后续任务等待超时就会触发中断：

• 检查JmsTemplate关联的线程池配置：核心线程数、最大线程数、等待队列长度是否能支撑10000条消息的发送需求。
• 调整线程池的keepAliveTime和任务等待超时时间，避免批量任务未完成就被强制中断。

2. JMS连接/会话超时 #

客户端与JMS Broker之间的连接或会话有超时限制，批量发送时持续占用资源超过阈值，会导致连接被断开，线程随之被中断：

• 查看JMS连接工厂的配置参数：比如connectionTimeout、sessionTimeout，适当调大这些值（比如从默认30秒改成5分钟），适配批量发送的时长。
• 建议使用CachedConnectionFactory复用连接和会话，减少频繁创建销毁资源的开销，降低超时概率。

3. 发送逻辑未复用资源（最常见的坑） #

很多人会在循环里每次调用jmsTemplate.send()，这会导致每次发送都创建新的会话和生产者，资源占用飙升，最终触发线程中断：

优化前的低效代码：

// 每次循环都创建新会话、生产者，资源浪费严重
for (int i = 0; i < 10000; i++) {
    jmsTemplate.send("target-queue", session -> session.createTextMessage("msg-" + i));
}

优化后的复用代码：

// 一次性创建会话和生产者，循环内复用
jmsTemplate.execute(session -> {
    MessageProducer producer = session.createProducer(session.createQueue("target-queue"));
    for (int i = 0; i < 10000; i++) {
        TextMessage msg = session.createTextMessage("msg-" + i);
        producer.send(msg);
    }
    producer.close();
    return null;
});

4. 外部中断信号 #

如果应用在批量发送过程中收到系统层面的中断信号（比如容器健康检查超时重启、运维手动发送中断指令），也会抛出这个异常。可以检查应用服务器/容器的日志，看是否有对应的中断记录。

额外排查建议 #

• 打印完整异常栈：找到InterruptedException的具体触发点，确认是JMS客户端线程还是应用自定义线程被中断。
• 监控系统资源：批量发送时观察CPU、内存、网络连接数，排查是否有资源耗尽的情况。
• 开启JMS DEBUG日志：跟踪每一次发送的连接、会话状态，看是否有异常关闭的迹象。

内容的提问来源于stack exchange，提问作者m.nguyencntt