关于Reactor Netty直接内存分配失败问题的技术问询

a) 为何仅调用客户端B时出现异常，其他下游正常？二者是否关联？ #

• 核心差异在客户端B的调用特性和其他下游不同：
  • 可能B返回的数据量远大于其他服务，每次调用要分配更大的直接内存缓冲区，加速耗尽了有限的直接内存池；
  • 客户端B的调用频率更高，或者存在未正确释放的直接内存泄漏（比如请求/响应流没正常终止、资源没回收），持续占着内存不释放；
  • 其他下游要么用了堆内存而非直接内存（配置了不同的内存分配策略），要么它们的内存占用刚好没到溢出阈值，所以没触发异常。
• 二者是有关联的：所有下游调用共享JVM的直接内存池，客户端B的内存消耗模式成了压垮阈值的最后一根稻草，其他服务的正常调用其实也在占用直接内存，只是没到临界点。

b) 外部客户端调用为何需要直接内存访问？是默认行为还是配置导致？ #

• Reactor Netty基于Netty实现，Netty默认用直接内存做IO操作，原因很直接：
  • 直接内存不在JVM堆里，避免了堆内存和本地内存之间的拷贝，能提升IO性能，尤其适合大流量、大文件传输场景；
  • 直接内存由操作系统回收，减少JVM GC的压力。
• 这是默认行为，但也能改配置：比如通过ChannelOption.ALLOCATOR指定用堆内存分配器PooledHeapByteBufAllocator，不过会牺牲部分IO性能。

c) 如何确定合适的直接内存大小？ #

• 先排查内存泄漏：
  • 用-XX:NativeMemoryTracking=detail启动JVM，再通过jcmd <pid> VM.native_memory detail查看直接内存的占用分布，确认有没有泄漏；
  • 检查Reactor Netty客户端的响应流处理：比如有没有订阅Flux/Mono并正确完成，避免资源挂着不释放。
• 计算基准值：
  • 统计客户端B单请求平均直接内存占用 × 并发请求数，加上其他下游服务的直接内存占用总和，再预留20%-30%的冗余空间；
  • 如果是容器化部署，还要考虑容器的内存限制，直接内存大小不能超过容器可用内存（直接内存属于JVM进程的本地内存，不算堆内存）。
• 动态调整：
  • 通过JVM参数-XX:MaxDirectMemorySize设置上限，比如-XX:MaxDirectMemorySize=2g；
  • 监控直接内存的实时占用（比如结合Reactor Netty的metrics用Prometheus+Grafana），根据实际运行情况逐步调整，别过度分配浪费资源。

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