C# Union Types 内存布局与 GC 优化：值类型封装、栈分配权衡与 F# 互操作

C# 15 提案引入的 Union Types 为类型系统带来了代数数据类型的表达能力，但在性能工程视角下，其内存布局设计引发了关于 GC 压力与栈堆分配权衡的关键讨论。本文从运行时内存模型出发，分析 record struct 包装器方案的实际开销，对比 F# Discriminated Unions 的两种表示形式，并提供可落地的优化参数与监控策略。

Union Types 的内存布局设计

当前 C# 15 提案采用 record struct 作为 Union 的底层载体，内部通过 object? 字段存储具体变体值。这一设计在语言层面保证了值语义，但运行时行为揭示了关键的内存 trade-off：

// 概念性伪代码展示内存布局
public readonly record struct Union<T1, T2>
{
    private readonly object? _value;  // 引用类型字段
    private readonly byte _tag;      // 类型标记
}

Union 实例本身是值类型（struct），可驻留在栈上或内联于父对象中。然而，当存储值类型变体时，_value 字段的 object? 类型会导致装箱（boxing），将栈上的值迁移至托管堆。这意味着每个值类型变体的存储都伴随一次堆分配，GC 需要追踪这些临时对象的生命周期。

对于引用类型变体（如 string、class 实例），装箱不会发生，但 Union 仍持有对象引用，参与 GC 的引用链追踪。这种设计在类型安全与内存效率之间选择了前者 ——Union 获得了统一的内存表示，但牺牲了值类型的零分配特性。

值类型装箱的 GC 影响与优化路径

装箱操作对 GC 的影响体现在三个维度：分配频率、堆内存碎片和代际提升压力。在高频场景（如解析器、消息队列处理）中，每个 Union 变体的创建都可能触发一次小对象堆（SOH）分配，累积后引发频繁的 Gen 0 回收。

优化策略需围绕 "避免装箱" 展开：

1. 手动布局的逃逸舱（Escape Hatch）

对于纯值类型的 Union，可使用 StructLayout 显式控制内存排布，避免 object? 字段的装箱开销：

[StructLayout(LayoutKind.Explicit)]
public struct ValueUnion
{
    [FieldOffset(0)] public byte Tag;
    [FieldOffset(1)] public int IntValue;
    [FieldOffset(1)] public double DoubleValue;
    // 共享内存区域，无装箱
}

此方案要求所有变体大小一致，且失去了类型安全保证，仅适用于性能关键路径。

2. 栈分配与 stackalloc 的边界

虽然 Union 本身是 struct，但内部 object? 的存在使其无法完全利用栈分配的优势。在 Span 友好的场景中，可考虑将 Union 替换为 ref struct 配合 MemoryMarshal 操作，但这限制了使用场景（不能作为字段、不能装箱）。

3. 对象池化与复用

对于无法避免的装箱场景，实施对象池化可减少分配频率。通过 ArrayPool<object> 或自定义池管理变体对象，将 GC 压力从 "频繁分配" 转化为 "池维护开销"。

F# Discriminated Unions 的内存模型对比

F# 的 Discriminated Unions（DU）提供了与 C# Union Types 类似的功能，但内存布局存在本质差异：

F# Reference DU 的每个值都是堆对象，数组中存储的是引用而非数据，导致缓存未命中和指针追逐开销。Struct DU 通过内联存储改善局部性，但需为最大变体预留空间，小变体存在内存浪费。

C# 15 Union 的 object? 设计在功能上更接近 F# Reference DU，但值类型装箱引入了额外的 GC 对象。从内存密度角度，C# Union 在存储值类型时劣于 F# Struct DU，但优于 F# Reference DU（后者无论如何都有堆分配）。

C# 与 F# 互操作的性能开销

跨语言边界使用 Union 类型时，性能开销主要来自表示形式的转换：

1. 装箱差异导致的序列化成本

当 C# Union 存储值类型时，F# 侧接收到的数据需经历拆箱（unboxing）或重新包装。这一转换在热路径上可能消耗 20-50ns（取决于变体复杂度），对于高频调用（>1M ops/sec）构成显著开销。

2. 模式匹配的性能不对称

F# 对 DU 的模式匹配有编译器优化（生成高效跳转表），而 C# Union 依赖属性访问和类型检查。在互操作边界，这种不对称可能导致一侧优化、另一侧退化的现象。

3. 推荐的互操作策略

• 共享简单表示：使用 record/class 替代 Union，显式建模变体，避免语言特定的 Union 编码
• 边界转换层：在 C#/F# 边界处实现显式转换，而非直接传递 Union 实例
• 性能关键路径隔离：高频交互场景使用原始类型（int、Span）而非 Union 抽象

可落地的优化参数与监控清单

基于上述分析，以下参数和检查点可用于指导 Union Types 的内存优化：

设计阶段检查清单

• 变体类型分布：统计值类型 vs 引用类型变体的比例，若值类型 > 50%，评估手动布局方案
• 生命周期分析：确认 Union 实例是否逃逸出创建作用域，逃逸实例的装箱成本更高
• 集合存储模式：若 Union 用于大数组，优先测试 Struct DU 或手动布局的内存密度收益

运行时监控参数

代码级优化策略

// 策略1：优先使用引用类型变体避免装箱
public readonly record struct Result<T>
    where T : class  // 约束为引用类型
{
    private readonly T? _value;  // 无装箱
    private readonly Error? _error;
}

// 策略2：小值类型使用专用 struct 包装
public readonly record struct SmallUnion
{
    private readonly long _packed;  // 8字节打包存储
    // 通过位操作提取变体标记和值
}

// 策略3：高频场景使用对象池
public static class UnionPool<T1, T2> where T1 : class where T2 : class
{
    private static readonly ObjectPool<Union<T1, T2>> Pool = 
        new DefaultObjectPool<Union<T1, T2>>(new UnionPolicy());
}

结论

C# 15 Union Types 的 record struct + object? 设计在类型安全与内存效率之间做出了明确取舍：它提供了统一的代数数据类型抽象，但值类型装箱引入了不可忽视的 GC 压力。与 F# Discriminated Unions 相比，C# Union 在功能上更接近 Reference DU，却失去了 Struct DU 的内存密度优势。

在高性能场景中，开发者应审慎评估 Union 的使用范围：对于类型安全优先的 API 设计，Union Types 提供了清晰的表达能力；对于分配敏感的热路径，手动布局的 struct 或引用类型约束仍是更优选择。跨语言互操作时，建议在边界处使用简单类型而非 Union 抽象，以避免装箱和模式匹配的不对称开销。

最终，Union Types 的价值在于代码可维护性而非自动内存优化。理解其底层布局机制，结合具体的性能监控数据，才能在类型安全与运行时效率之间找到合适的平衡点。

参考来源

• NDepend Blog: C# 15 Unions - 内存布局与装箱分析
• Matthew Crews: Performance of Discriminated Unions and Active Patterns - F# DU 性能基准测试

dotnet-performance