BRPC项目中pthread_mutex_trylock与jemalloc死锁问题分析

问题背景

在BRPC项目中，开发者发现了一个与pthread_mutex_trylock和jemalloc内存分配器相关的死锁问题。这个问题出现在最新版本的BRPC代码中，特别是当项目同时使用了jemalloc 5.2.1内存分配器时。

技术细节分析

问题的核心在于BRPC对pthread_mutex_trylock等pthread互斥锁相关函数的覆盖（hook）实现。BRPC通过覆盖这些系统函数来实现两个重要功能：

1. 支持竞争分析器（contention profiler），用于监控和分析多线程环境中的锁竞争情况
2. 检测工作线程潜在的锁死问题

在实现这些功能时，BRPC使用了dlsym来获取原始的系统函数指针。然而，当与jemalloc一起使用时，这种实现方式可能导致递归调用和死锁。

死锁发生机制

通过分析调用栈，我们可以清晰地看到死锁的发生过程：

1. jemalloc在执行内存分配操作时，需要获取内部锁，调用pthread_mutex_trylock
2. 这个调用被BRPC的hook实现拦截，进入BRPC的覆盖函数
3. BRPC的覆盖函数尝试通过dlsym获取原始的系统函数指针
4. dlsym内部需要分配内存，又进入了jemalloc的内存分配路径
5. jemalloc再次尝试获取内部锁，形成循环依赖

这种循环依赖最终导致了死锁的发生，因为jemalloc在等待自己的锁释放，而这个锁的获取过程又被BRPC的hook实现所拦截。

解决方案

BRPC项目组针对这个问题提出了有效的解决方案：

1. 使用__dl_sym替代dlsym来获取系统函数指针。__dl_sym是更底层的符号查找函数，不会触发内存分配操作，从而避免了递归调用jemalloc的问题。
2. 引入NO_PTHREAD_MUTEX_HOOK宏，在无法调整动态库加载顺序的情况下，可以选择不覆盖pthread的互斥锁相关函数。

性能影响

对于性能敏感的开发者可能会关心hook实现带来的性能开销。实际上：

• 在未开启竞争分析器的情况下，hook实现仅增加了一个判断和线程局部变量的操作，对性能影响微乎其微
• 开启竞争分析器后，虽然会有额外的性能开销，但这是功能实现所必需的，且提供了有价值的竞争分析数据

最佳实践建议

基于这个问题的分析，我们建议开发者在类似场景下：

1. 谨慎使用系统函数的hook实现，特别是在内存分配器等关键系统组件中
2. 在hook实现中避免可能触发递归调用的操作
3. 考虑使用更底层的系统接口（如__dl_sym）来避免依赖高级功能
4. 在必须hook的情况下，为关键路径提供绕过机制

这个问题不仅揭示了BRPC与jemalloc交互时的潜在陷阱，也为其他需要hook系统函数的项目提供了有价值的参考。理解这类问题的本质有助于开发者在设计类似功能时做出更合理的技术决策。