@iseki 主要还是 grpc 框架的限制，目前是不支持这种方式的。然后就算是在流中处理，他也是需要占用堆内存，还是解决不了 GC 的问题

@ccde8259 这个我理解 netty 已经给封装好了？各种 handler ，直接处理 ByteBuf 就行了

@iseki proto 编解码工作量还行，接口不多，而且工作是一次性的。至于 API 这个，说多了都是泪，需要适配客户端，客户端升级不了。
能再详细说一下 arena 是什么原理，怎么用吗？

@momo24672 这个解决不了，protobuf 里面的 bytes 还是会分配对堆内存的问题

@flyqie 消息队列的场景

@ccde8259 思路是这个，就是说目前 grpc 的 api 不支持分配到非堆，所以想看看我说的那个用 netty 实现的思路行不行

@wenhuibrave 都不用强制 GC ，每分钟十几次，主要是流量大 2GB/s ，垃圾多，算下来也是这么个 GC 频率。gc 调优治标不治本。所以才想不用 grpc ，自己去解析 ByteBuf

@haython 对，必须得用 java

@chendy 最大可能几十 MB ，单机流量快 2GB/s 。用的 ZGC ，主要是 Allocation Stall 内存分配暂停。

@me1onsoda 用的 ZGC ，stw 比较短，但是会有 Allocation Stall ，几百毫秒

@lmshl 目前是 ZGC ，流量太大 2GB/s ，堆都用了 40G 了，偶尔还是会有内存分配暂停。单个 grpc 请求比较大，可能会有几十 M