Apache RocketMQ TieredStore内存泄漏问题分析与解决方案

问题背景

在Apache RocketMQ的TieredStore存储架构中，当启用IndexStoreService并且使用PosixFileSegment作为TieredMessageStore的文件段实现时，系统会出现严重的内存泄漏问题。这个问题会导致直接内存持续增长，最终可能引发OOM异常或触发shutdownHook。

问题现象

在生产环境中部署了基于TieredStore架构的RocketMQ集群，将冷数据卸载到HDD硬盘并使用PosixFileSegment实现。经过约16小时的持续消息生产后，监控显示直接内存使用量以稳定速率持续增长，每次增长约570MB，恰好与压缩后的IndexFile大小一致。

根本原因分析

通过深入代码分析，发现问题根源在于PosixFileSegment.commit0方法中不恰当的FileChannel使用方式。具体表现为：

1. 在IndexFile上传过程中，FileChannel.write(buffer)操作会分配与buffer大小相同的DirectByteBuffer
2. 这些DirectByteBuffer作为ThreadLocal变量存储在sun.nio.ch.Util.BufferCache中
3. 由于这些缓冲区由线程池中的线程持有，且线程不会被销毁，导致直接内存无法释放

技术细节

问题的核心在于Java NIO的实现机制。当调用FileChannel.write(buffer)时：

1. 系统会查找足够大的DirectByteBuffer来存储buffer数据，如果没有则分配新的
2. 将数据从DirectByteBuffer写入pagecache
3. 将DirectByteBuffer返回BufferCache但不释放

在RocketMQ的实现中，commit0方法通过线程池执行，这些线程长期存活，导致DirectByteBuffer不断累积。

解决方案探讨

社区提出了几种可能的解决方案：

1. 限制bufferCommitExecutor线程池大小
2. 通过jdk.nio.maxCachedBufferSize参数限制BufferCache大小
3. 限制PosixFileSegment.commit0方法中inputStream的大小
4. 使用MappedByteBuffer替代FileChannel
5. 实现DirectIO直接访问方案

经过讨论和测试，最终选择了MappedByteBuffer方案，因为：

1. FileChannel.transferFrom性能无法满足要求
2. DirectIO实现需要额外依赖库
3. MappedByteBuffer在测试中表现出良好的性能

性能考量

虽然MappedByteBuffer方案会影响pagecache并可能与commit log产生资源争用，但在实际压力测试中表现良好，能够支持约60k的producer TPS。对于SSD转HDD场景，专家建议可以考虑Java directIO库来彻底解决pagecache浪费内存的问题。

总结

这个问题揭示了在实现分层存储架构时，对底层IO操作细节考虑的重要性。特别是在处理大文件传输时，需要特别注意内存管理策略。RocketMQ社区通过深入分析和多方案验证，最终找到了平衡性能和资源消耗的解决方案，为类似场景提供了有价值的参考。