HAProxy 线程关闭过程中的死循环问题分析

问题背景

在HAProxy的日常运维中，我们遇到了一个关于线程关闭时的异常情况。当HAProxy接收到关闭信号时，部分线程会进入一个无限循环状态，持续消耗CPU资源，导致系统负载升高。这个问题最初是在HAProxy 2.6版本的OpenShift部署环境中发现的。

问题表现

在关闭过程中，可以观察到以下现象：

1. 主线程（tid=0）处于等待其他线程完成的状态
2. 其他线程持续进行epoll_wait和clock_gettime系统调用
3. CPU使用率达到100%
4. 通过perf工具统计，每秒约产生300万次epoll_wait和600万次clock_gettime系统调用

问题根源

通过分析线程堆栈和代码逻辑，发现问题出在信号处理机制上。当HAProxy接收到关闭信号时：

1. 主线程负责协调关闭过程，等待其他工作线程完成
2. 工作线程在poll循环中检查信号队列(signal_queue_len)
3. 存在一个竞态条件：工作线程可能检测到信号队列非空，从而保持活跃状态
4. 但实际只有主线程(tid=0)应该处理这些信号

这种设计导致工作线程误以为有信号需要处理，从而无法正常退出，形成死循环。

解决方案

修复方案非常简洁但有效：修改信号队列检查逻辑，确保只有主线程(tid=0)会因信号队列非空而保持活跃状态。具体代码修改如下：

- } else if (signal_queue_len) {
+ } else if (signal_queue_len && tid == 0) {

这一修改确保了：

1. 工作线程不会因为信号队列的存在而保持活跃
2. 主线程仍能正常处理信号
3. 消除了线程间的竞态条件

问题验证

通过以下步骤可以验证问题：

1. 编译带有调试标记的HAProxy
2. 使用特定配置触发线程竞争
3. 观察线程状态和系统调用频率
4. 应用修复后验证关闭过程是否正常

技术启示

这个问题给我们几个重要的技术启示：

1. 多线程编程中，信号处理需要特别小心
2. 资源清理和线程退出逻辑需要明确的责任划分
3. 竞态条件可能在特定条件下才会显现
4. 系统监控工具(如perf)对于诊断此类问题非常有帮助

总结

HAProxy作为高性能负载均衡器，其线程模型设计精巧。这次发现的关闭过程中的死循环问题，展示了在多线程环境下信号处理的复杂性。通过限制信号处理的责任范围，我们确保了系统能够优雅关闭，避免了资源浪费。这一修复已被合并到主分支，并将向后移植到各个稳定版本中。