ActiveMQ中Stomp client-individual ACK使用及死锁排查问询

我仔细梳理了你的架构设计、测试场景和死锁日志，咱们逐个解答你的疑问：

是的，vm连接池的使用确实是触发死锁的关键因素，但核心问题是ActiveMQ的线程锁顺序反转，连接池只是放大了这个问题的触发概率：

从死锁日志可以看到两个核心线程的锁竞争闭环：

• ActiveMQ Transport: tcp:///127.0.0.1:64896@25201（Stomp客户端的传输线程）：持有MutexTransport的ReentrantLock，同时等待PrefetchSubscription的对象锁（0x00000006c4dc0d90）
• ActiveMQ BrokerService[localhost] Task-2（Broker的任务线程）：持有PrefetchSubscription的对象锁，同时等待MutexTransport的ReentrantLock

当你使用无池化vm连接时，每次发送请求都会创建新的连接和对应的Transport线程，线程之间的锁资源完全隔离，不会出现锁顺序反转；但使用PooledConnectionFactory后，连接被复用，多个请求/ACK操作共享同一个Transport连接和线程，导致锁竞争场景频繁出现，最终触发死锁。

针对这个问题，你可以尝试调整vm连接的配置来缓解：

• 在vm连接URL中添加transport.useAsyncDispatch=true，让Broker使用异步方式分发消息，避免同步调用Transport的锁
• 调整PooledConnectionFactory的参数，比如设置maxConnections=1（虽然会降低并发，但能避免多连接复用导致的锁竞争），或者启用createConnectionOnStartup=false延迟创建连接

你的自定义StompEndpoint实现（在交换处理完成后发送client-individual ACK）本身逻辑是对的，但ACK的执行线程是Stomp客户端的Transport线程，这是触发死锁的直接诱因：

当你在消息处理完成后发送ACK时，这个操作是在Stomp的Transport线程中同步执行的，会调用Broker的acknowledge方法，进而触发PrefetchSubscription.dispatchPending尝试获取对象锁；而此时Broker的任务线程可能正在处理replyTo队列的消息分发，已经持有了这个对象锁，同时尝试获取Transport的ReentrantLock（用于发送消息到客户端），最终形成锁循环。

建议你修改自定义ACK的执行时机：

• 将ACK操作提交到一个独立的线程池执行，不要在Stomp的Transport线程中同步执行，比如用Camel的ExecutorServiceStrategy来异步发送ACK
• 检查replyTo的消费逻辑是否也存在类似的锁竞争，确保replyTo处理和ACK逻辑的线程隔离

STOMP 1.2规范中对client-individual ACK的发送时机有明确原则：客户端必须在完全处理完消息（包括所有关联的业务操作）之后发送ACK，这样Broker才会将消息标记为已处理，不会触发重新投递。

对于你的请求-响应场景，规范没有强制要求ACK必须在发送响应之前还是之后，但从可靠性和业务一致性角度，建议：

• 如果你的业务允许重复响应：先发送replyTo响应，再发送ACK。这样即使ACK失败，消息会被重新投递，但需要业务端做幂等处理
• 如果你的业务不允许重复响应：使用STOMP的事务机制，将SEND（发送响应）和ACK（确认请求）放在同一个事务中，确保两个操作要么都成功，要么都失败
• 绝对不要在处理消息之前发送ACK，否则如果客户端处理失败，消息会直接丢失，无法重新投递

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