gRPC高并发OOM主因是未约束缓冲区与流控参数，须设InitialWindowSize、InitialConnWindowSize、Read/WriteBufferSize四参数，并规范缓冲池使用及流式响应生命周期管理。
为什么gRPC服务一上高并发就OOM？
根本原因不是连接数多，而是每个连接背后默认分配的缓冲区、流控窗口、recvBuffer队列没做约束，导致内存呈线性甚至指数级增长。尤其在服务端流式场景下，recvBuffer无界堆积、DefaultBufferPool未复用、MaxConcurrentStreams未设上限，三者叠加会让单个连接吃掉几十MB内存。
必须调整的4个内存关键参数
这些不是“可选优化”，是高并发下防止OOM的底线配置：
-
grpc.InitialWindowSize(64 * 1024)：控制每个流的初始接收窗口，避免大消息一次性压入内存；设太大（如默认1MB）会导致recvBuffer提前占满 -
grpc.InitialConnWindowSize(128 * 1024)：连接级窗口，影响HTTP/2帧调度粒度；超过256KB易引发TCP分片和内核缓冲区压力 -
grpc.ReadBufferSize(32 * 1024)和grpc.WriteBufferSize(32 * 1024)：限制底层TCP读写缓冲区大小，防止net.Conn内部buffer失控；不设值时可能沿用系统默认（如256KB），大量连接下直接耗尽堆外内存
缓冲区池怎么用才真省内存？
gRPC-Go自带的mem.DefaultBufferPool()不是开箱即用——它只在内部编码/解码路径生效，如果你手动调用io.Copy或封装了自定义Reader/Writer，缓冲区照样逃逸到GC堆上。
- 必须显式替换所有
make([]byte, N)为pool.Get(N)，且pool.Put(buf)要放在defer里确保归还 - 优先用
sizedBufferPool而非tieredBufferPool：后者按需匹配大小，但会创建多个子池，反而增加管理开销；高频固定尺寸（如4KB日志包）用前者更稳 - 别碰
simpleBufferPool：它不回收内存，只是把make包装了一下，等于没优化
流式响应时最容易漏掉的内存泄漏点
服务端流（ServerStream）的生命周期和内存绑定极紧，常见错误是“发完就忘”：
- 没调用
stream.SendMsg()后检查error：一旦流被客户端断开，未处理的error会让recvBuffer.backlog持续积压，直到OOM - 在goroutine里发流但没加context超时：
ctx, cancel := context.WithTimeout(parentCtx, 30*time.Second)必须传给stream，否则goroutine永久挂起，携带全部buffer不释放 - 错误地复用
stream对象：每个RPC调用应新建stream，重用会导致last mem.Buffer残留和引用计数错乱
最隐蔽的是recvBufferReader.last字段——它缓存上次读取剩余数据，如果流提前关闭而reader没被GC，这块内存就永远卡住。没有自动清理机制，只能靠严格的作用域控制和及时close。
