深入分析trpc项目中WebSocket订阅的内存泄漏问题

内存泄漏现象描述

在trpc项目的WebSocket订阅功能中，当使用版本11时，开发者发现了一个严重的内存泄漏问题。具体表现为：当通过WebSocket连接发送大量数据时，Node.js进程的内存使用量会持续增长，直到连接关闭后才会释放。

通过内存监控工具可以清晰地观察到这一现象：在订阅开始前，内存使用稳定在约195MB左右；一旦订阅开始并持续发送数据，内存使用量会以每次约50MB的速度递增，最终可能达到600MB以上。相比之下，在版本10中，内存使用量保持稳定，没有出现类似的泄漏情况。

问题根源分析

经过深入的技术调查，发现问题出在Promise.race的使用上。在trpc的WebSocket适配器代码中，存在以下关键代码段：

while(true){
    const next = await Promise.race([
        iterator.next().catch(TRPCError.getTRPCErrorFromUnknown),
        abortPromise
    ]);
    // ...
}

这段代码原本的目的是同时监听迭代器的下一个值和可能的终止信号。然而，Promise.race在Node.js环境下存在已知的内存管理问题，特别是在处理大量数据时会导致内存无法被垃圾回收机制正确释放。

技术背景解析

Promise.race的内存泄漏问题在Node.js社区中已有记录。其根本原因在于：

1. 引用保留：Promise.race会保留所有传入Promise的引用，直到其中一个Promise完成
2. 垃圾回收受阻：即使某些Promise已经变得无关紧要，它们仍然被保留在内存中
3. 大对象问题：当处理大型数据对象时，这个问题会变得更加明显

在trpc的上下文中，每次迭代都会产生新的Promise，而之前的Promise由于被Promise.race保留，导致其携带的数据也无法被释放。

解决方案验证

通过将代码修改为直接等待迭代器的next方法，可以避免内存泄漏：

while(true){
    const next = await iterator.next().catch(TRPCError.getTRPCErrorFromUnknown);
    // ...
}

这种修改虽然简化了逻辑，但确实解决了内存泄漏问题。测试表明，修改后的代码在持续发送大量数据时，内存使用量保持稳定，不再出现持续增长的情况。

更深入的考虑

虽然直接移除Promise.race可以解决问题，但这可能会影响原有的终止功能。更完善的解决方案可能需要：

1. 实现自定义的race逻辑，避免使用原生Promise.race
2. 添加显式的资源清理机制
3. 对大型数据流实现分块处理

对开发者的建议

对于遇到类似问题的开发者，建议：

1. 在WebSocket通信中特别注意大对象的内存管理
2. 定期进行内存使用监控
3. 谨慎使用Promise.race等可能影响垃圾回收的API
4. 考虑使用流式处理替代一次性发送大对象

总结

trpc项目中的这个内存泄漏案例展示了JavaScript异步编程中一个容易被忽视的问题。通过深入分析，我们不仅找到了问题的根源，还验证了解决方案。这个案例提醒我们，在高性能网络编程中，内存管理需要特别关注，即使是看似无害的语言特性也可能在特定场景下导致严重问题。