mediasoup项目中WebRtcServer内存泄漏问题分析与修复

问题背景

在mediasoup项目的实际使用中，开发者发现当使用WebRtcServer创建WebRtcTransport时，系统内存会随着时间推移不断增加，最终达到约7GB的内存占用。这个问题在使用glibc分配器和jemalloc时都会出现，且当所有用户断开连接后，大部分内存不会被释放。

问题现象

通过内存分析工具(jemalloc和heaptrack)的分析结果发现，内存泄漏主要与TCP连接相关的缓冲区分配有关。具体表现为：

1. 当WebRtcTransport被关闭时，虽然Transport对象被销毁，但底层的TcpConnectionHandle对象没有被正确释放
2. 只有在WebRtcServer被关闭时，这些TCP连接才会被真正释放
3. 使用Valgrind工具检测到约15MB的内存可能泄漏，调用栈指向TCP连接的缓冲区分配

技术分析

WebRtcTransport与WebRtcServer的关系

在mediasoup中，WebRtcTransport可以通过两种方式创建：

1. 直接创建独立的Transport
2. 通过WebRtcServer创建共享的Transport

当使用WebRtcServer时，TCP服务器实例由WebRtcServer管理并共享给所有使用该Server创建的Transport。每个Transport会创建自己的TCP连接实例(TcpConnectionHandle)。

内存泄漏的根本原因

通过深入代码分析，发现问题出在WebRtcTransport的销毁流程中：

1. 当WebRtcTransport被关闭时，会调用ICE Server的关闭逻辑
2. ICE Server会尝试关闭相关的TCP连接
3. 然而，在WebRtcServer模式下，TCP连接的生命周期管理存在问题：
   • 只调用了TcpConnectionHandle::Close()方法
   • 但没有调用TcpConnectionHandle的析构函数
   • 导致TCP连接使用的缓冲区内存没有被释放

问题复现

开发者通过以下步骤可以稳定复现该问题：

1. 配置服务器仅使用TCP传输
2. 从Android客户端创建WebRtcTransport并建立连接
3. 突然断开网络连接(如开启飞行模式)
4. 通过信号层检测到断开后主动关闭Transport
5. 观察到Transport对象被销毁，但TcpConnectionHandle对象未被销毁

解决方案

修复方案的核心是确保在WebRtcTransport被销毁时，正确清理所有相关的TCP连接资源。具体包括：

1. 在WebRtcTransport析构函数中，确保所有TCP连接被正确关闭和销毁
2. 确保TcpConnectionHandle的析构函数被调用，从而释放缓冲区内存
3. 正确处理各种断开场景(正常关闭、异常断开等)

技术启示

这个案例给我们带来几点重要的技术启示：

1. 资源共享模式下的生命周期管理：当多个对象共享资源时，需要特别小心资源的生命周期管理
2. 连接断开处理：网络应用中必须妥善处理各种断开场景，包括正常关闭和异常断开
3. 内存泄漏检测：合理使用内存分析工具(jemalloc、heaptrack、Valgrind等)可以帮助快速定位内存问题
4. 析构函数的正确调用：在C++中，确保所有资源的析构函数被正确调用至关重要

总结

mediasoup项目中WebRtcServer内存泄漏问题的发现和修复过程，展示了在实际网络应用开发中资源管理的重要性。通过深入分析问题现象，结合工具定位，最终找到了问题的根本原因并提供了解决方案。这也提醒开发者在实现资源共享机制时，需要特别注意资源的生命周期管理和释放逻辑。