MediaMTX服务器writeQueue满导致流冻结问题分析与解决

问题背景

MediaMTX是一款开源的实时流媒体服务器软件，用于RTSP/RTMP等协议的流媒体传输。在最新版本1.11.1中，用户报告了一个严重问题：当服务器运行约4小时后，会出现"writeQueue full"错误，导致客户端视频流冻结，甚至API接口也无法响应。

问题表现

典型问题症状包括：

1. 服务器运行约4小时后开始出现"writeQueue full"日志信息
2. 已连接的客户端视频流停止更新，进入冻结状态
3. 新客户端无法成功连接或获取流数据
4. API接口(如9997端口)无响应
5. 服务器进程未崩溃但基本功能丧失

问题定位

通过版本回退测试，确定问题出现在2023年12月至2024年1月间的某个提交中。具体分析发现：

1. 问题与gortsplib库从v4.11.2升级到v4.12.1有关
2. 使用pprof工具分析发现大量goroutine在runtime.gopark状态
3. 主要阻塞点在sync.(*RWMutex).Lock操作上
4. 问题涉及所有客户端而不仅是单个客户端

根本原因

深入分析发现，问题根源在于8a808ac提交引入的代码变更导致了一个互斥锁被重复锁定。具体来说：

1. 新引入的统计系统需要额外的锁操作
2. 在某些代码路径中，同一个互斥锁被连续锁定两次
3. 这导致死锁情况，阻塞了所有客户端的处理流程
4. 服务器无法继续分发媒体数据包

解决方案

开发团队迅速响应，提出了以下修复方案：

1. 修复了可能导致互斥锁重复锁定的代码路径
2. 增加了额外的安全检查确保锁操作正确
3. 优化了数据包分发流程的并发控制

修复后的版本经过长时间测试验证，确认解决了该问题。该修复已包含在v1.11.3正式版本中。

经验总结

1. 并发编程中锁操作需要特别小心，避免重复锁定
2. 系统级功能(如统计)的引入可能影响核心流程
3. 压力测试和长时间运行测试对媒体服务器至关重要
4. pprof等工具是诊断Go并发问题的利器

对于使用MediaMTX的用户，建议及时升级到v1.11.3或更高版本以避免此问题。对于开发类似流媒体服务器的团队，此案例也提供了宝贵的并发控制经验。