Janus Gateway视频会议室模块中的死锁问题分析与解决

问题背景

在Janus Gateway 1.3.0版本中，视频会议室模块(janus_videoroom)出现了一个严重的死锁问题。该问题会导致整个janus-gateway进程停止响应HTTP请求，严重影响生产环境的稳定性。问题在从0.x版本升级到1.3.0后首次出现，且难以在测试环境中复现。

死锁现象分析

通过GDB调试工具捕获的堆栈跟踪显示，系统出现了典型的互斥锁死锁情况。具体表现为：

1. 线程6持有participant->streams_mutex锁，同时尝试获取handle->mutex锁
2. 线程5持有handle->mutex锁，同时尝试获取participant->streams_mutex锁

这种循环等待的情况导致了系统完全死锁。具体来说：

• 当处理参与者配置时，线程在持有流互斥锁的情况下请求核心发送PLI(图片丢失指示)
• 同时，处理管理API请求的线程在持有句柄互斥锁的情况下尝试查询视频会议室会话状态

问题根源

深入分析代码后发现，问题的根本原因在于锁的获取顺序不一致。在Janus Gateway的核心架构中：

1. janus_ice_relay_rtcp函数在发送RTCP数据包时需要获取ICE句柄的互斥锁
2. janus_videoroom_query_session函数在查询会话状态时需要获取参与者的流互斥锁

当这两个操作以相反的顺序发生时，就可能形成死锁。特别是在处理handle_info管理API请求时，这种锁顺序冲突尤为明显。

解决方案

开发团队通过重构代码解决了这个问题，主要改进包括：

1. 统一锁的获取顺序，确保总是先获取高层锁再获取底层锁
2. 优化RTCP数据包中继流程，减少不必要的锁持有时间
3. 重构内部函数调用关系，避免交叉锁依赖

验证与效果

经过在生产环境中的长期测试验证：

1. 死锁频率从每天约15次降低到测试期间仅发生1次
2. 系统稳定性显著提升，HTTP请求超时问题基本消失
3. 性能开销在可接受范围内，没有引入明显的延迟

最佳实践建议

对于使用Janus Gateway视频会议室功能的开发者，建议：

1. 及时升级到包含此修复的版本(1.3.1及以上)
2. 避免在高并发场景下频繁调用handle_info管理API
3. 监控系统锁等待情况，及时发现潜在的死锁风险
4. 在生产环境部署前，充分测试锁相关的边界条件

总结

Janus Gateway视频会议室模块的死锁问题展示了分布式系统中锁管理的复杂性。通过分析锁获取顺序和重构关键代码路径，开发团队成功解决了这一棘手问题。这个案例也提醒我们，在开发实时通信系统时，需要特别注意并发控制和资源锁定的设计。