Gc

本文翻译自 Uber 官方博客 Translations at Scale: Memory Optimization Techniques That Kept Uber’s P99 Under 1ms ，作者 Cristian Velazquez（Sr Staff Engineer），原文发布于 2026 年 10 月 15 日。为便于阅读，译文对部分长句做了拆分，技术术语保留英文原词，文中的插图直接引用原文外链。 一句话总结：先在 Go 层把 sync.Map 换成 map[string]string 消掉每条翻译 4 个指针对象，再把 key 压缩成 6 字节哈希、value 压缩成 5 字节偏移量，只把热点条目留在内存、其余落盘。 引言 在 Uber，我们每秒要服务数百万次翻译请求。为了节省成本并降低延迟，这些翻译全部从内存中提供。保持资源效率是我们长期的目标。为此，我们重点关注 GC（Garbage Collection）——它一直是我们 Go 服务中最大的算力消耗方之一。过去我们用过 GoGCTuner 之类的工具来降低 GC 成本，但 tuner 只能靠把应用可用的内存全部用上来帮忙，当空闲内存本来就低的时候它就无能为力了。 在对整个机群做了一轮内存 profile 分析之后，我们发现翻译库在对象体积和对象数量上都是排名靠前的贡献者。本文介绍我们这些年来针对该库与 GC 交互方式所做的两项主要优化。 第一个问题：创建的对象数量过多 最初的问题是翻译服务的 GC 频率非常高，服务 20% 以上的 CPU 被 GC 吃掉，而其中大部分被创建的对象都来自翻译数据。 ...