Go sync.Pool 在小对象高频场景反而拖慢 P99 + GC 抖动放大的 5 天复盘:victim cache + GC 周期耦合 + Batch Pool 正解

2025 年 12 月,我们给一个 Go 写的高 QPS 推送网关引入了 sync.Pool,目标是减少小对象分配压力。这个网关每秒处理 18 万条推送任务,每条任务会分配一个 ~256 字节的临时结构体。改完后跑 benchmark 看着指标全面上涨:对象分配次数 -94%,allocator overhead -38%,看起来是个漂亮的优化。但生产环境灰度 24 小时后,SRE 告诉我 P99 延迟反而从 8ms 涨到 23ms,GC 暂停频率诡异地变得更频繁。复盘 5 天后我才搞清楚:sync.Pool 不是"越用越好"的银弹,它对小对象+高频分配的场景反而有负优化,在某些规模下会把 GC 抖动放大,因为 Pool 的 victim cache 跟 GC 周期是耦合的。这篇是我们 5 天里走过的 4 个错误方向、3 种修法对比,以及最终落地的"按对象寿命决定是否池化"的判断准则。

背景:看起来应该用 sync.Pool 的负载

推送网关的代码路径很直接:收到一条 push 任务 → 反序列化 protobuf → 在内存里构造 PushContext 结构体(包含路由信息 + 重试策略 + 优先级 + meta) → 投递到下游 5 个推送 channel → 等所有 ack 完成 → 回调上游。每秒 18 万次,意味着每秒分配 18 万个 PushContext,堆增长速率 ~46MB/s。Go 1.22,GOMEMLIMIT 设了 4GB,GOGC=100。生产环境跑下来 GC CPU 占比稳定在 12%,P99 延迟 8ms。这个数字在我们组内被反复 review 过,认为已经是"还可以但仍有优化空间"的状态——12% 的 GC CPU 意味着每天有大约 2 个工程师小时等价的 CPU 时间是花在 GC 上的,如果能压到 5% 以下,集群规模就能省下大约 18% 的成本。这种"看起来还有油水"的优化目标,后来证明是一个非常危险的陷阱:有时候系统不是"还有优化空间",而是已经在某个局部最优里待着了,你贸然改动反而会让它滚下山去。

那次"性能优化"的提议者(我自己)看到 pprof 里 runtime.mallocgc 占了 11% CPU,觉得"这种短生命周期对象明摆着应该 pool 化",兴致勃勃改了。改完单元 benchmark 漂亮,提了 PR 也很顺利合了。然后线上灰度,慢慢暴露问题。事后翻 PR 讨论记录,3 个工程师 LGTM 总共花了 23 分钟,中间没有任何一个人要求看生产环境压测数据。这件事很值得反思:我们组对"修 bug"类 PR 的 review 标准很严格,但对"性能优化"类 PR 反而比较宽松——因为大家潜意识里觉得"优化最差也就是没效果,不会变差"。这个潜意识是错的,而且错得离谱。性能优化的负向风险比修 bug 高得多,因为它通常改的是热点路径,影响面更广;而且因为大家以为它"应该让事情变好",出问题时第一反应往往不是怀疑这个 PR,而是去找别的原因——我们在事故 D1-D3 整整两天都在排查"是不是 Linux 内核有问题"、"是不是某个上游服务变了",其实根因就是合进去的那个 70 行 sync.Pool PR。

事故时间线

第一轮排查:benchmark 撒谎了

D2 我反复跑同样的 benchmark,Pool 版本永远是赢的。这让我一度怀疑是生产环境的某种不一样导致 Pool 失效——比如 GOMAXPROCS 跟测试环境不同(测试 8 核,生产 16 核)、或者 Linux 内核版本影响(测试 6.5,生产 5.15)。试了把测试环境调成跟生产一致,Pool 还是赢。

// 失败的 benchmark:看起来 Pool 是稳赢的
func BenchmarkPushContextWithPool(b *testing.B) {
    pool := sync.Pool{
        New: func() any { return new(PushContext) },
    }
    b.ResetTimer()
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            ctx := pool.Get().(*PushContext)
            // 填充并使用
            ctx.RouteID = 42
            ctx.Priority = 1
            _ = doWork(ctx)
            ctx.Reset()
            pool.Put(ctx)
        }
    })
}
// 结果:Pool 版 alloc/op 8B,无 Pool 版 alloc/op 256B
// 看起来 Pool 完胜

这个 benchmark 误导性极强,因为它每个 goroutine 紧密循环 Get/Put 同一个对象,完全不反映生产环境"几百万个 goroutine 各自做不规则 Get/Put"的场景。生产里的实际访问模式是:某个 Pool 对象可能 Get 出来后跟着任务投递到 channel,几毫秒后才在另一个 goroutine 里 Put 回去——这中间发生 GC,Pool 的内容就被清掉或转移到 victim cache,下次 Get 又是 New 出新对象。Pool 的复用率远低于 benchmark 显示的水平。

这件事让我对 Go benchmark 工具的局限性有了非常深的认知。go test -bench 默认运行 1 秒就停,数据规模太小、GC 几乎不触发;就算 -benchtime=10s 跑长一点,也是同一个 goroutine 紧密循环,跟生产的"读 channel → 投递 → 等 ack → 回调"完全不是一个时序模型。benchmark 的本质是"在受控环境里测量一个微观操作的速度",它从来不是"模拟生产负载"的工具。但我们组,包括我自己,长期把它当成"代理性能测试"用,这种习惯需要在事故里被狠狠纠正。事故之后我们引入了一个新的工程纪律:任何涉及 sync.Pool / sync.Map / 池化 / 缓存的 PR,benchmark 数据只能作为参考,必须配一个"流量回放压测报告"才能合并。这个报告基于我们用 tcpreplay 录制的真实流量,在测试环境里回放 1 小时,对比新旧两个版本的 GC trace、P99、堆大小波动。这套基础设施搭建花了大约 2 周时间,但后续帮我们拦截了至少 3 个"看起来漂亮但生产环境会出问题"的优化 PR。

D4 转折:抓真实 GC trace

D4 早上我决定不再相信本地 benchmark,直接在生产灰度 Pod 上挂 GC trace + Go execution trace。这两个工具能告诉你 GC 实际怎么跑的,而不是"理论上应该怎么跑"。

# 1. GODEBUG gctrace 实时打 GC 日志,看每次 GC 的耗时 / 触发原因
GODEBUG=gctrace=1 ./edge-gw 2>&1 | tee gc.log
# 输出形如:
# gc 1234 @120.4s 12%: 0.5+8.2+0.3 ms clock, 4.0+12.1/16.4/0+2.4 ms cpu, 412->420->210 MB, 421 MB goal, 0 MB stacks, 0 MB globals, 8 P

# 2. go tool trace 抓 30 秒详细 trace,看 GC 跟用户代码的交错
curl -o trace.out http://localhost:6060/debug/pprof/trace?seconds=30
go tool trace trace.out
# 浏览器里能看到 GC mark / sweep / assist 跟每个 P 的活动

# 3. pprof 看堆增长
curl -o heap.pb http://localhost:6060/debug/pprof/heap
go tool pprof -http=:8080 heap.pb

对比 Pool 版和无 Pool 版的 gc trace,关键差异立刻出来:

看到这张表,直觉告诉我:Pool 没有让 GC 工作减少,反而让 GC 触发得更频繁了。这跟所有教科书说的都不一样。当一个观察跟主流认知严重冲突时,要么是观察方法有错,要么是教科书有遗漏的边界条件,我花了半天去验证观察方法没问题(换 Pod、换流量、换时间窗,数字都稳定),才相信确实是教科书省略了边界。

问题本质:victim cache 跟 GC 周期耦合的两面性

翻 Go runtime 源码 + Bryan C. Mills 几篇关于 sync.Pool 的演讲,我终于把因果链拼齐:

事实 1:sync.Pool 内部维护两层 buffer:本地 P-local pool + victim cache。每次 STW 阶段(GC 期间),P-local pool 整个移到 victim cache,P-local 重新置空。这是为了避免 Pool 无限增长。设计是 Bryan C. Mills 在 Go 1.13 引入的。

事实 2:victim cache 在下一次 GC 时被清空(放回堆等待回收)。也就是说每个 Pool 对象只能"跨越"一次 GC 周期,如果两次 GC 之间没被复用,就被丢弃。在高频小对象场景下,GC 间隔大约 1 秒,如果分配速率高于复用速率,大量 Pool 对象走"创建 → 入 Pool → victim cache → 丢弃"的路径,完全没节省任何分配。

事实 3:小对象在 Go 的 mcache 已经被高度优化。Go runtime 给每个 P 维护了 size class 的 mcache(类似 TCMalloc),小于 32KB 的对象分配几乎是 O(1) 的 bump pointer,根本不需要走 sync.Pool 这一层。sync.Pool 的复用收益必须超过它本身的元数据 + 同步开销,才能赢过 mcache 直接分配。256 字节的小对象,mcache 分配可能只要 5-8ns,而 Pool Get 涉及 P-local 检查 + 偶尔 mutex 同步,平均 10-15ns。

事实 4:Pool 让 live heap 看起来更小,但 GC 触发策略反而更激进。Go 的 GC 触发是基于"自上次 GC 以来分配的内存 vs 上次 GC 后的 live heap" 的比值 (GOGC=100 即 1.0)。Pool 让一部分对象"假复用",上次 GC 后 live heap 测量偏低(因为很多 Pool 对象在 victim cache 里),下次 GC 触发阈值就低,GC 就更频繁。这是个二阶效应,本地 benchmark 看不到。

把这 4 个事实串起来,完整的因果链就是:

修法 1:回滚 sync.Pool(立即生效)

D1 我们已经回滚了 PR,P99 立刻回到 8ms。但我不甘心,Pool 既然是 Go 官方推荐的优化手段,总有它适合的场景吧?于是开始系统化测试不同场景下 Pool 的真实收益。

修法 2:严格按对象大小 + 寿命决定是否用 Pool

跑了一周的对比测试,我们沉淀出一个判断表(Go 1.22 + Linux 6.5 + GOGC=100):

关键经验:Pool 的收益不来自"避免分配",而来自"避免大对象走 large object allocator"。32KB 是 Go 内部的 large object 阈值,小于这个值用 mcache,大于这个值走 mheap 全局锁。Pool 真正的杀手锏是绕开大对象那条慢路径。我们的 PushContext 是 256 字节,本来就在 mcache 快路径上,Pool 化纯属画蛇添足。这个 32KB 的阈值我后来在 Go runtime 源码 runtime/sizeclasses.go 里翻到了,它是 size class 划分的最后一档,大于这个值的对象不再走 size class 体系而是直接 page 分配,锁开销和分配开销都跳了一个数量级。理解这个阈值之后,我们组的所有 Pool 提案都会先量对象大小:小于 32KB 直接劝退,大于 32KB 才进入下一轮评估。

修法 3:重新设计,把"按 task pool 化"改成"按 batch pool 化"

既然单个 256 字节 task 不值得 Pool,我们换了一个思路:把 1000 条 task 打包成一个 batch 结构(总大小约 256KB),按 batch 维度 Pool 化。这是 Pool 真正适合的场景——大对象、跨 goroutine 长寿命、明确的 Get/Put 边界。

package gw

import (
    "sync"
)

const batchSize = 1024

// PushBatch 持有 1024 条任务 + 路由元数据,总大小 ~256KB
type PushBatch struct {
    Tasks    [batchSize]PushTask  // 内联 array,不是 slice,避免再次分配
    Count    int
    BatchID  uint64
    Priority uint8
    RouteIDs []uint32  // 关联的路由
}

func (b *PushBatch) Reset() {
    // 关键:Reset 必须把所有字段清零,否则上次的数据会泄漏
    for i := 0; i < b.Count; i++ {
        b.Tasks[i] = PushTask{}
    }
    b.Count = 0
    b.BatchID = 0
    b.Priority = 0
    b.RouteIDs = b.RouteIDs[:0]
}

var batchPool = sync.Pool{
    New: func() any {
        return &PushBatch{
            RouteIDs: make([]uint32, 0, 64),
        }
    },
}

func AcquireBatch() *PushBatch {
    return batchPool.Get().(*PushBatch)
}

func ReleaseBatch(b *PushBatch) {
    b.Reset()
    batchPool.Put(b)
}

切到 batch 模式后,Pool 命中率 91%(因为 batch 寿命平均 8ms,远长于 GC 间隔的小对象,真正能复用),GC 频率回到 0.7 次/秒,P99 进一步降到 6.5ms。这才是 Pool 该有的样子。这次设计还附带一个意外收获:因为我们改成"按 batch 处理",下游的推送 channel 利用率也变好了——之前每个 task 一次推送一次 channel 写,channel 的 lock 成了次要瓶颈;现在每个 batch 写一次 channel,锁竞争降低 1000 倍,P99 在这块又额外降了 0.8ms。这种"重构带来连锁正向收益"的体验让我意识到,很多时候性能优化的真正机会不在"加速某个调用",而在"重新定义工作单元"。把"逐条处理"改成"批量处理",几乎在所有高并发系统里都是非常值得探索的方向,但是需要业务能容忍 8ms 级别的批量延迟,这是个 trade-off,不是免费的。我们这个推送网关本来允许 50ms 内的延迟,所以批量化非常合适;如果是要求 1ms 响应的实时风控,这条路就行不通。

额外考量:Pool 的 finalizer 陷阱

有一段时间我们尝试在 Pool 对象里嵌入一个 os.File 之类的有 finalizer 的资源,被 Bryan 的文档敲打:Pool 中的对象不会被 GC 立刻回收,finalizer 调用时机变得完全不确定,文件句柄可能积累到上千个才被释放。我们最后的规矩是:任何带 finalizer / cgo / 文件 / socket / 锁的对象,绝对不进 Pool。

// 反模式:不要这么干
type BadObject struct {
    f *os.File  // 这个 File 的 finalizer 永远调不到合适时机
    // ... 其他字段
}

var badPool = sync.Pool{New: func() any { return &BadObject{} }}

// 正模式:把资源跟数据分开
type GoodObject struct {
    data []byte  // 只放纯数据
}

var goodPool = sync.Pool{New: func() any { return &GoodObject{data: make([]byte, 0, 4096)} }}

// 资源单独管理,显式 Open/Close 不依赖 GC
func processFile(path string, buf *GoodObject) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close()  // 显式关闭,跟 Pool 无关
    _, err = f.Read(buf.data)
    return err
}

判断 Pool 适用性的工具脚本

为了让团队任何人都能在引入 Pool 前快速判断"该不该用",我们写了一个小工具脚本,跑 30 秒采样后给出建议:

package main

import (
    "flag"
    "fmt"
    "runtime"
    "sync"
    "time"
)

type CheckResult struct {
    AllocPerSec      uint64
    AvgGCPause       time.Duration
    GCFrequency      float64
    SmallObjectRatio float64
    Recommendation   string
}

// AnalyzePoolFit 跑 30 秒采样,判断当前服务是否适合引入 sync.Pool
func AnalyzePoolFit(duration time.Duration) CheckResult {
    var memStart, memEnd runtime.MemStats
    runtime.ReadMemStats(&memStart)

    startTime := time.Now()
    time.Sleep(duration)
    runtime.ReadMemStats(&memEnd)

    elapsed := time.Since(startTime).Seconds()
    allocPerSec := (memEnd.Mallocs - memStart.Mallocs) / uint64(elapsed)
    gcCount := memEnd.NumGC - memStart.NumGC
    gcFreq := float64(gcCount) / elapsed

    totalPause := time.Duration(0)
    for i := uint32(0); i < gcCount && i < 256; i++ {
        idx := (memEnd.NumGC + 255 - i) % 256
        totalPause += time.Duration(memEnd.PauseNs[idx])
    }
    var avgPause time.Duration
    if gcCount > 0 {
        avgPause = totalPause / time.Duration(gcCount)
    }

    // 估算小对象比例(< 1KB)
    var smallRatio float64
    if memEnd.HeapAlloc > 0 {
        smallRatio = float64(memEnd.TotalAlloc-memEnd.Frees) / float64(memEnd.HeapAlloc)
    }

    rec := "不建议引入 sync.Pool"
    if gcFreq > 1.0 && allocPerSec > 100_000 && smallRatio < 0.5 {
        rec = "强烈建议引入 sync.Pool(大对象高频分配)"
    } else if gcFreq > 0.5 && allocPerSec > 50_000 {
        rec = "可以尝试 Pool,但要长跑验证"
    }

    return CheckResult{
        AllocPerSec:      allocPerSec,
        AvgGCPause:       avgPause,
        GCFrequency:      gcFreq,
        SmallObjectRatio: smallRatio,
        Recommendation:   rec,
    }
}

func main() {
    dur := flag.Duration("d", 30*time.Second, "sampling duration")
    flag.Parse()
    r := AnalyzePoolFit(*dur)
    fmt.Printf("%+v\n", r)
}

把这个工具集成到我们的 SRE 命令行后,引入 Pool 之前先跑一遍是组里的硬性流程。事实上 50% 以上的 Pool 提议都在这一步被劝退,因为采样数据明确显示场景不适合。这个工具的实际价值不在于它的代码,而在于它给团队提供了一个"数据驱动"的拒绝理由——之前大家在 review 时只能凭经验劝退,现在有了具体数字。

性能对比(完整数据)

从原始到最终,QPS +16%,P99 -27%,GC CPU 从 12% 降到 7%。关键是方向选对了,优化才有收益;选错方向,做得越多越糟。

5 天里走错的 4 个方向

1. "再加一层 LRU 缓存" —— D2 我曾打算给 Pool 加一层 LRU 保留更久,这其实是误解 Pool 工作原理。Pool 不是缓存,Go 已经给了 sync.Map 和各种 LRU 库专门做缓存。
2. "调 GOGC 让 GC 跑得更少" —— 把 GOGC 从 100 拉到 300,GC 频率确实降了,但 Pool 命中率没变,堆膨胀 3 倍,RSS 飙到 1.5GB,反而让 K8s 触发 throttle。
3. "换 fasthttp 系列内存池" —— 试用了 valyala 的 bytebufferpool,对 bytes.Buffer 场景确实有效,但对自定义结构体不适用,不能解决我们的问题。
4. "切到 Go 1.23 看看" —— Go 1.23 的 sync.Pool 实现没有本质变化,只是微优化。换版本不会自动解决这个问题。

我们立的 9 条 sync.Pool 工程纪律

1. 引入 sync.Pool 前必须做生产环境压测对比,不只跑 micro benchmark。本地 benchmark 撒谎概率极高。
2. 对象大小 < 1KB 默认不进 Pool,除非有压测数据证明收益。
3. 有 finalizer / cgo / 文件 / 锁的对象绝对不进 Pool,否则资源释放时机失控。
4. 每个 Pool 类型必须有 Reset 方法,Put 前强制调用,避免脏数据泄漏到下次 Get。
5. Pool 不是缓存。需要缓存就用 LRU 或 sync.Map,不要用 Pool 充数。
6. GC trace 接入 Grafana:GC 频率 + GC 暂停 + GC CPU 占比 + 堆大小波动率。任何"Pool 改动"必看这四个指标。
7. Pool 的 Put 路径要 100% 覆盖。一旦 Put 路径漏掉某些情况(比如 error path 直接 return),Pool 就变成"创建工厂",负优化。
8. 压测必须长跑。Pool 的负优化通常要跨多个 GC 周期才暴露,5 分钟 benchmark 完全不够,建议 1 小时以上。
9. 性能 PR 必须有 GC trace 对比。光 benchmark 数据不够,因为 GC 行为在 micro benchmark 里跟生产差异巨大。

另一个 sync.Pool 不适合的隐藏场景:并发度低

除了"小对象"的反模式,我们后来还发现 Pool 在并发度低的场景也是负优化。Pool 的设计前提是"多个 goroutine 高频争抢同一类对象",这时候 P-local pool 能避免全局锁。但如果你只有 2-3 个 goroutine 偶尔分配大对象,Pool 本身的元数据开销会盖过收益。我们组里另一个组件做日志归档,只有一个后台 goroutine 偶尔需要大 buffer,我帮他们移除了 Pool 改成直接 make,反而快了 20%。

Go 团队在 Pool 的文档里其实写得很清楚:"The pool's purpose is to cache allocated but unused items for later reuse, relieving pressure on the garbage collector." 关键是 "pressure on the garbage collector" ——只有 GC 真的有压力时,Pool 才有意义。如果你的服务 GC CPU 占比本来就只有 3-5%,引入 Pool 大概率是负优化。

对 Go 团队官方推荐的反思

这次复盘让我重新审视 Go 标准库的"推荐用法"——sync.Pool 几乎是每个 Go 教程都会教的"性能优化"手段,但绝大多数教程没说清楚它的边界条件。我后来读完 sync.Pool 的源码 + 6 篇官方博客 + Bryan C. Mills 在 GopherCon 的两次演讲,才真正理解它的设计意图。它从来不是为了"减少分配"而设计的,而是为了"减少大对象 / 跨 GC 周期对象的重新初始化成本"。这两个动机差很多。

类似的"被误用的标准库"在 Go 里还有几个:

• context.WithCancel 没 defer cancel:context 泄漏的最大来源,我们之前的 900031 文章详细写过。
• time.After 在循环里:每次都创建新 timer,GC 压力极大。应该用 time.NewTimer 复用。
• strings.Builder 跨 goroutine 传递:Builder 不是并发安全的,但有些人以为它是。
• runtime.GC() 主动调用:除非你在写 benchmark,几乎没有任何场景应该主动调 runtime.GC(),它会触发 STW + 阻塞业务请求。

关于"标准库优化"的元教训

真正的元教训是:标准库的优化函数都有它的适用前提,前提不满足就是负优化。这听起来废话,但 Go 圈子有一种"用标准库准没错"的心态,导致很多 PR 引入 sync.Pool、sync.Map、runtime.GC() 等等,完全不考虑场景。这不是 Go 独有的问题,Python 的 functools.lru_cache、Java 的 ThreadLocal 都有同样的滥用现象。

对工程师来说,正确的姿势是:遇到"看起来该用某个标准库工具"的场景,先问三个问题——1) 这个工具的设计动机是什么?2) 我的场景符合这个动机吗?3) 怎么用数据验证它真的有收益?三个问题都答得上来再用,答不上来宁愿不用。这套思维方式不仅适用于 sync.Pool,而是所有"性能相关"的工具选型的通用模板。我后来把它写进了组内的"性能 PR review checklist",每次别人提性能优化 PR 时,review 的人必须在评论里逐条回答这三个问题——回答不出来就不准合。这条流程被吐槽过"太重",但它实际拦下了好几个看起来漂亮、其实有负向风险的改动。流程的重量本身就是一种过滤器,挡住的不是"努力工作的人",而是"还没想清楚就提 PR 的人"。

总结

这次故障最大的认知更新是:"减少分配"不等于"减少 GC 压力"。Go 的 GC 触发是基于分配速率 vs live heap 的比值,Pool 让 live heap 测量偏低反而触发更频繁。理解这一层需要去看 runtime 源码,绝大多数人不会去做这件事,所以这类"反直觉负优化"在 Go 圈子里悄悄存在。

如果你的 Go 服务在用 sync.Pool 而性能没达到预期,先去抓 GC trace 看 GC 频率和 CPU 占比,而不是相信 micro benchmark。把对象大小、寿命、并发度三个维度量化清楚,再决定是否池化。Pool 不是免费的优化,它有它的成本曲线,只有特定场景下才"赢"。

更广义地说,这次复盘还让我对"工程师对运行时的认知深度"有了新的判断标准。Go 这门语言的一个魅力就是它把很多运行时细节藏得很好,让初学者写出还不错的代码很容易;但代价是,当你的服务到了 GC、调度、内存分配真正开始成为瓶颈的规模时,你必须打开"Go runtime"这个黑盒,理解 mcache / mcentral / mheap、P-G-M 调度模型、GC pacer 算法、写屏障的工作机制——这些东西不学,光靠"我觉得 Pool 应该有用""我觉得 channel 应该够快"是肯定要栽跟头的。我们组之后特意组织了 3 次"Go runtime 内部"的内部分享,把 GC trace 怎么读、pprof 怎么解读、go tool trace 怎么用都过了一遍。这种学习投入短期内看不到产出,但当真的发生事故时,从看到 GC trace 到定位根因的速度可以差 10 倍——这次我用了 5 天定位,如果有早期足够深的运行时知识,可能 1-2 天就能搞定。认知深度本身就是稀缺的工程资产,跟代码质量、测试覆盖率一样,都是组织能力的一部分。

最后给读者一个简单的自检清单:如果你现在的 Go 服务正在用 sync.Pool,请问问自己——1)Pool 里对象的平均寿命是多少?2)对象大小是多少?3)生产环境 GC 频率是多少?4)Pool 命中率是多少?这 4 个数字一个都答不上来的话,你的 Pool 大概率没有真正起作用,甚至可能在帮倒忙。花 30 分钟接入 GC trace 监控 + 加一个 Pool 命中率指标,你就能给自己一个明确的答案,而不是依赖"我觉得它应该在工作"的乐观假设。

—— 别看了 · 2026