Go 泛型中的 GC Shape Stenciling：性能与编译速度的平衡艺术

原文来源：GC Shape Stenciling in Go Generics — Go 语言如何通过 GC shape 分组的模板化方案在完整单态化和类型擦除之间找到平衡

Go 1.18 引入泛型已经四年了。但 Go 团队在泛型实现上做了一个有趣的设计决策：既不采用 Rust/C++ 的完整单态化，也不走 Java 的类型擦除，而是选择了中间路线——GC Shape Stenciling。

为什么这么选？这背后有什么权衡？对你的 Go 程序有什么实际影响？

三种泛型实现方案

完整单态化（Rust、C++）

为每个具体类型生成独立的函数副本。以 Rust 为例：

fn identity<T>(value: T) -> T {
    value
}
 
fn main() {
    println!("{} {}", identity(42_u32), identity(42_u64));
}

编译后生成两份完全独立的函数：

; identity::<u32>
define internal i32 @_RINvCs...8identitymEB2_(i32 %value)
 
; identity::<u64>
define internal i64 @_RINvCs...8identityyEB2_(i64 %value)

优点：无运行时开销，每个类型都能做最大程度的优化和内联。 缺点：二进制体积膨胀，编译时间变长。C++ 模板和 Rust 泛型都以编译慢著称，部分原因就在这里。

类型擦除（Java）

所有泛型实例共享同一份代码，类型参数在编译后消失。

Box<String> 和 Box<Integer> 共享同一个 Box 类
T 擦除为 Object
使用时由编译器插入强制类型转换

优点：编译快，二进制小。 缺点：运行时需要类型转换和装箱（primitive boxing），带来性能开销。基本类型必须包装成对象，产生堆分配和间接引用。

GC Shape Stenciling（Go）

这是 Go 的选择——介于两者之间。

什么是 GC Shape？

GC shape 是一个类型对于分配器和垃圾回收器的展现方式：它的大小（size）、对齐（alignment）、以及哪些部分包含指针。

Go 的核心规则：两个类型共享同一个 GC shape，当且仅当它们有相同的底层类型。 但有一个例外——所有指针类型共享同一个 shape，以 *uint8 命名。

举个例子：

type User struct{}
type Order struct{}
 
func identity[T any](value T) T { return value }
 
func main() {
    fmt.Println(identity(42))
    fmt.Println(identity(3.14))
    fmt.Println(identity(&User{}))
    fmt.Println(identity(&Order{}))
}

编译后的符号表：

T main.identity[go.shape.*uint8]    ← *User 和 *Order 共享
T main.identity[go.shape.float64]
T main.identity[go.shape.int]

4 个实例化 → 3 个函数体。int 一个、float64 一个、所有指针类型共享一个。

*User 和 *Order 都是指针，大小相同、对齐相同、都指向堆上的内存——对 GC 来说它们长得一模一样，所以用同一份代码就够了。

Dict（字典）的作用

共享代码的问题在于：当函数体内需要知道具体类型信息时怎么办？

解决方案是 dictionary——一个存储在二进制只读数据段的固定表格，每个具体实例化生成一个。其中包含运行时的类型描述符和类型特定的条目。编译器会将它作为隐藏参数传给泛型函数。

// 伪代码表示
func identity[T any](value T, dict *Dictionary) T {
    // dict 里存了 T 的类型信息
    // 需要时通过 dict 查找
}

共享的成本

• 方法调用：泛型参数上的方法调用无法在编译时完全解析，需要通过字典查找
• 内联限制：字典查找可能阻止内联优化
• 逃逸分析变保守：可能导致额外的堆分配

但对于不需要具体类型信息的操作（如简单的读写），共享代码编译出的汇编和单态化版本完全一样。

命名类型的处理

type MyInt int

MyInt 复用 go.shape.int 的代码体，只需额外生成一个字典——不需要新的函数体。这也解释了为什么 Go 泛型不会像 C++ 模板那样大幅增加编译时间。

编译速度对比

Go 1.18 引入泛型后，编译速度比 Go 1.17 慢了约 15%。但到 Go 1.20 时，性能已经恢复——Go 1.20 的编译速度比 Go 1.18 提升了多达 10%，基本回到了 Go 1.17 的水平。

这说明 GC Shape Stenciling 的设计在长期来看是可持续的——编译速度不会随着泛型使用的增多而线性下降。

对开发者的实际影响

什么时候该用泛型？

适合使用泛型的场景：

• 实现通用的数据结构和算法（集合、排序、树、图）
• 类型参数仅用于保持类型安全，不需要反射
• 泛型函数体很小，字典查找开销可以忽略

不适合使用泛型的场景：

• 性能关键的热路径，且类型分支很少——手动写几个具体函数可能更快
• 需要大量调用泛型参数上的方法——每次调用都可能触发字典查找
• 二进制体积敏感的场景——大量不同类型实例化会膨胀二进制

性能调优建议

1. 指针类型共享代码体：优先使用指针类型参数，多个指针类型共享一份代码
2. 避免在热路径上使用泛型方法调用：如果循环内部调用了泛型参数的方法，考虑用接口代替
3. 注意逃逸分析：泛型参数返回的指针可能比预期的更容易逃逸

总结

Go 的 GC Shape Stenciling 是在编译速度、运行时性能和二进制体积之间的务实权衡。它不像 Rust 的完整单态化那样"完美"（零运行时开销），但也不像 Java 的类型擦除那样产生显著的装箱开销。

对于大多数 Go 开发者来说，这个设计意味着你可以放心使用泛型而不必担心性能问题——Go 团队已经帮你权衡好了。