Spring GCP PubSub批量发消息时ByteBuf内存泄漏问题求助

解答 #

1. 是否属于Bug？ #

这个ByteBuf泄漏大概率是grpc-netty或Spring Cloud GCP PubSub客户端的底层Bug。从错误栈可以看到，ByteBuf是在SSL解码阶段由gRPC客户端分配的，自研代码没有直接操作Netty的ByteBuf，完全依赖底层库管理资源。这类泄漏问题在gRPC或Spring Cloud GCP的旧版本中已有相关报告，属于客户端侧未正确释放Netty资源的场景。

2. 是否由Java垃圾回收与Netty对象计数异常导致？ #

是的。Netty的ByteBuf采用引用计数机制管理内存，每个ByteBuf必须调用release()方法才能释放占用的内存。当Java垃圾回收器回收了未被正确调用release()的ByteBuf时，Netty的ResourceLeakDetector就会触发这个泄漏告警。批量发送消息时，短时间内会创建大量ByteBuf，如果底层库的资源回收逻辑存在漏洞（比如异步操作未跟踪引用、异常场景下未释放资源），就会导致部分ByteBuf未被正确释放，最终被GC回收时触发告警。

3. 解决方法 #

方法一：升级依赖版本（优先推荐）

这类资源泄漏问题通常会在后续版本中被修复，优先升级相关依赖到最新稳定版：

• 升级com.google.cloud:spring-cloud-gcp-starter-pubsub到3.4.0及以上的稳定版
• 确保Spring Boot版本与Spring Cloud GCP版本兼容（参考官方版本适配规则）

方法二：调整PubSub客户端配置

通过配置优化gRPC客户端的资源管理，减少资源堆积：

• 限制发布线程数和并发调用数，避免短时间内创建过多连接：

  spring.cloud.gcp.pubsub.publisher.executor-threads=10
  spring.cloud.gcp.pubsub.publisher.max-concurrent-calls-per-host=50
  

• 切换Netty的内存分配器为非池化模式（仅作为缓解手段，不能根治）：

  io.grpc.netty.shaded.io.netty.allocator.type=unpooled
  

方法三：控制消息发布节奏

降低批量发送的速率，给客户端足够时间处理资源回收：

• 将每批发送的条数从1000减少到500甚至更低
• 每批发送后添加短暂休眠（比如100ms），避免持续压测客户端

方法四：临时禁用泄漏检测（不推荐）

如果上述方法都无效，且确认泄漏不会导致严重内存溢出，可以临时关闭泄漏检测，但这只是隐藏问题而非解决：

spring.netty.leak-detection=disabled

内容的提问来源于stack exchange，提问作者artsgard