SOFA-JRaft 中未回收 RPC 线程导致 OOM 问题分析

问题背景

在使用 SOFA-JRaft 分布式一致性框架时，开发者通过 ProcessBuilder 多次启动和停止 JRaft 服务器后，系统出现了内存溢出（OOM）错误。从错误日志中可以观察到大量未被回收的 RPC 相关线程堆积，特别是名为"JRaft-RPC-Processor"的线程数量异常增多。

问题现象

从堆栈信息中可以看到，JVM 最终因为无法分配新的线程栈空间而崩溃。线程列表中显示有大量重复的 RPC 处理器线程（JRaft-RPC-Processor）和相关的 Bolt 网络线程未被正确回收。这些线程占据了大量内存资源，最终导致系统内存耗尽。

根本原因分析

经过深入分析，这个问题主要源于以下两个关键因素：

1. 非正常关闭：开发者没有通过标准的 shutdown 流程停止 JRaft 服务，而是直接终止了进程。这种粗暴的终止方式导致 JRaft 内部的资源清理机制无法正常执行。

2. RPC 资源泄漏：JRaft 的 RPC 子系统（基于 Bolt 实现）在服务停止时需要显式关闭。如果没有正确调用关闭方法，相关的线程池、网络连接等资源将无法被回收，造成内存和线程泄漏。

解决方案

要解决这个问题，开发者需要确保以下几点：

1. 正确关闭流程：在停止 JRaft 服务时，必须调用 RaftGroupService 的 shutdown 方法。这个方法会负责清理内部状态和释放资源。

2. RPC 服务器共享处理：如果开启了 RPC 服务器共享模式（多个 JRaft 组共享同一个 RPC 服务器），则需要特别注意：

   • 共享的 RPC 服务器需要单独关闭
   • 关闭顺序应该是先关闭各个 Raft 组服务，最后关闭共享的 RPC 服务器

3. 异常处理：在 ProcessBuilder 启动的外部进程管理场景中，应该捕获进程终止信号，并在终止前执行正常的关闭流程。

最佳实践建议

1. 资源管理模板：建议使用 try-with-resources 或类似的资源管理模式来确保 JRaft 服务的正确关闭。

2. 监控机制：实现线程池和资源使用的监控，及时发现资源泄漏问题。

3. 优雅停机：在系统设计中考虑优雅停机机制，确保所有组件都能在进程终止前完成清理工作。

4. 压力测试：在开发阶段进行反复启停的压力测试，验证资源回收的正确性。

总结

SOFA-JRaft 作为生产级的分布式一致性框架，其资源管理机制设计完善，但需要开发者遵循正确的使用模式。特别是在需要频繁启停服务的场景下，确保资源的正确回收至关重要。通过理解框架的资源管理机制并遵循最佳实践，可以避免类似的内存溢出问题，保证系统的稳定运行。