Go UDP net.Read接收频繁创建[]byte的GC压力问题及优化方案咨询

问题描述 #

当前基于Go语言开展性能测试过程中，怀疑服务端返回数据的接收环节存在设计缺陷，相关实现代码如下：

const RecvBufferSize = 1024 * 64

for {
        readBuff := make([]byte, RecvBufferSize)
        n, err := udp_client.conn.Read(readBuff)
        if err != nil {
            log.Error("socket recv error.", zap.String("errMsg", err.Error()))
            return
        }

        select {
        case udp_client.recvMessage <- readBuff[:n]:
        case <-udp_client.closeTest:
            log.Info("close recvFrom", zap.String("Stack", string(debug.Stack())))
            close(udp_client.recvMessage)
            return
        }
    }

上述实现每次接收服务端返回数据时，都会重新申请一块[]byte类型内存，核心疑问为：大流量接收场景下该写法是否会造成GC压力，以及是否有成熟优化方案。

问题场景截图：

问题结论 #

大流量场景下该写法确实会带来显著的GC压力，具体原因如下：

• 循环内每次调用make申请64KB内存块，高吞吐场景下每秒会产生数万甚至数十万短生命周期的堆对象，GC标记、清理的CPU开销会随流量线性上涨，极端场景下GC开销可占总CPU消耗的30%以上，还会引发服务内存使用毛刺
• 代码向channel发送的是原数组的切片引用，若下游消费逻辑长时间持有该切片，会导致整个64KB底层数组无法被回收，进一步放大内存浪费

成熟优化方案 #

Go生态针对这类高频申请释放固定大小内存块的场景，通用优化方案是使用标准库sync.Pool构建字节缓冲池，实现内存块复用，具体改造逻辑如下：

1. 初始化全局缓冲池，定义缓冲创建逻辑

import "sync"

const RecvBufferSize = 1024 * 64

// 字节接收缓冲池
var recvBufferPool = sync.Pool{
    New: func() any {
        return make([]byte, RecvBufferSize)
    },
}

2. 改造接收循环逻辑，实现缓冲取用、归还

for {
    // 优先从池中取已存在的缓冲，无可用缓冲时自动新建
    readBuff := recvBufferPool.Get().([]byte)
    n, err := udp_client.conn.Read(readBuff)
    if err != nil {
        log.Error("socket recv error.", zap.String("errMsg", err.Error()))
        // 异常分支也要归还缓冲，避免对象泄漏
        recvBufferPool.Put(readBuff)
        return
    }

    // 拷贝有效数据，禁止直接传递池内缓冲的切片引用
    // 避免下游长时间占用缓冲导致复用失效，同时规避并发读写风险
    validData := make([]byte, n)
    copy(validData, readBuff[:n])
    // 缓冲使用完成立即归还池中
    recvBufferPool.Put(readBuff)

    select {
    case udp_client.recvMessage <- validData:
    case <-udp_client.closeTest:
        log.Info("close recvFrom", zap.String("Stack", string(debug.Stack())))
        close(udp_client.recvMessage)
        return
    }
}

优化注意事项 #

• 必须覆盖所有代码分支保证缓冲归还，包括异常、提前退出的分支，否则会出现对象泄漏，缓冲池退化为每次新建，失去优化意义
• 禁止将从池中取出的缓冲直接通过channel传递给下游消费逻辑，下游消费时长不可控，既会导致缓冲长时间被占用无法复用，还可能引发多协程并发读写同一块内存的脏数据问题
• 若UDP包大小差异极大，可进一步实现分层缓冲池，针对不同大小区间的数据包匹配对应容量的缓冲，减少额外内存开销，绝大多数常规场景下上述单池方案已可满足性能要求

内容的提问来源于stack exchange，提问作者江南薛