libdatachannel项目中TCP传输层死锁问题分析与解决方案

问题背景

在libdatachannel项目的实际应用场景中，当通过WebSocket传输较大数据量（如10MB）且网络存在丢包或高延迟导致套接字缓冲区填满时，开发团队发现存在缓冲区损坏问题。为解决这一问题，项目引入了mSendMutex互斥锁机制，旨在防止应用程序线程推送数据时的乱序问题。

死锁现象分析

引入mSendMutex机制后，系统出现了新的死锁问题。死锁主要发生在TcpTransport::setPoll和PollService::Instance().add这两个函数的调用链路上。具体表现为：

1. 轮询线程获取mSendMutex锁
2. 在持有该锁的情况下，尝试调用PollService相关函数
3. PollService内部也需要获取自己的mMutex锁
4. 当两个线程以不同顺序获取这两个锁时，就可能形成典型的互斥锁死锁

技术细节深入

问题的核心在于锁的获取顺序不一致。在libdatachannel的实现中：

• 发送数据路径：先获取mSendMutex，然后可能触发PollService操作
• 轮询回调路径：PollService处理时持有自己的mMutex，然后可能调用需要mSendMutex的回调

这种交叉依赖的锁获取顺序是典型的死锁诱因。此外，代码中还观察到回调函数直接传递'this'指针的做法存在潜在风险，特别是在对象生命周期管理方面。

解决方案

经过分析，开发团队提出了以下解决方案：

1. 锁释放优化：在PollService::process函数中，先释放mMutex再执行回调函数。这样可以打破锁的持有链，避免死锁情况的发生。

2. 对象生命周期管理改进：对于回调函数中直接使用'this'指针的问题，建议改为使用weak_ptr机制。具体做法是：

   • 在对象删除前创建weak_ptr
   • 回调函数中先检查weak_ptr是否有效
   • 这样可以避免访问已删除对象的内存

实施效果

应用上述解决方案后，系统在大量数据传输测试中不再出现死锁或数据损坏问题。特别是在高负载、高延迟的网络环境下，传输稳定性和可靠性得到了显著提升。

经验总结

这个案例为我们提供了几个重要的经验教训：

1. 多线程环境下的锁管理需要谨慎设计获取顺序
2. 回调机制中的对象引用需要特别注意生命周期管理
3. 性能优化（如缓冲区管理）可能引入新的同步问题
4. 系统性的压力测试对于发现并发问题至关重要

通过这次问题的分析和解决，libdatachannel项目的TCP传输层稳定性和可靠性得到了进一步提升，为后续的大规模数据传输应用奠定了更坚实的基础。