Apache Pulsar NegativeAcksTracker 死锁问题分析与解决方案

问题背景

在 Apache Pulsar 4.0 分支的测试过程中，发现了一个潜在的死锁问题。该问题出现在 org.apache.pulsar.client.api.InterceptorsTest.testConsumerInterceptorForNegativeAcksSend 测试用例执行期间，涉及 NegativeAcksTracker 和 ConsumerImpl 两个关键组件之间的锁竞争。

死锁场景分析

死锁发生在两个线程之间：

1. 主测试线程：

   • 持有 ConsumerImpl 的锁
   • 等待获取 NegativeAcksTracker 的锁

2. 定时器线程(pulsar-timer)：

   • 持有 NegativeAcksTracker 的锁
   • 等待获取 ConsumerImpl 的锁

具体调用链如下：

• 测试线程： ConsumerImpl.closeAsync() → ConsumerImpl.closeConsumerTasks() → NegativeAcksTracker.close()

• 定时器线程： NegativeAcksTracker.triggerRedelivery() → ConsumerImpl.redeliverUnacknowledgedMessages()

根本原因

这个死锁问题的根本原因是锁获取顺序不一致导致的循环等待：

1. 测试线程先获取 ConsumerImpl 锁，然后尝试获取 NegativeAcksTracker 锁
2. 定时器线程先获取 NegativeAcksTracker 锁，然后尝试获取 ConsumerImpl 锁

这种交叉锁获取方式在并发环境下很容易形成死锁。

技术影响

这种死锁会导致以下问题：

1. 消费者无法正常关闭，资源无法释放
2. 消息重投递机制可能失效
3. 系统资源可能被长时间占用
4. 在长时间运行的生产环境中可能导致内存泄漏

解决方案

解决这类死锁问题的常见方法包括：

1. 统一锁获取顺序：确保所有线程都以相同的顺序获取锁
2. 锁超时机制：为锁获取设置超时时间
3. 减小锁粒度：将大锁拆分为多个小锁
4. 无锁设计：使用并发容器或原子操作

针对这个具体问题，最合适的解决方案是统一锁获取顺序。可以调整 NegativeAcksTracker 的实现，确保它不会在持有自身锁的情况下调用需要 ConsumerImpl 锁的方法。

实现建议

1. 在 NegativeAcksTracker 中，将触发重投递的操作放入队列
2. 使用单独的线程处理这些操作，避免在定时器线程中直接调用需要 ConsumerImpl 锁的方法
3. 在 close 方法中，先获取 NegativeAcksTracker 锁，再获取 ConsumerImpl 锁（如果需要）

预防措施

为避免类似问题再次发生，建议：

1. 在代码审查时特别注意跨组件的锁依赖
2. 编写并发测试用例，模拟高并发场景
3. 使用静态分析工具检测潜在的锁顺序问题
4. 文档化组件间的锁依赖关系

总结

Apache Pulsar 中的这个死锁问题展示了分布式系统中常见的并发挑战。通过分析锁竞争关系和调整锁获取顺序，可以有效解决这类问题。对于消息中间件这类高并发系统，合理的锁设计和严格的并发控制是保证系统稳定性的关键。