C#中ref传递struct引用为何比class引用慢？性能差异疑问

这是个非常好的问题——很多人会误以为ref传递就抹平了值类型和引用类型的性能差异，但实际上CLR底层的处理逻辑还是有很大不同的，咱们一步步拆解你的疑问：

1. 先直接回答第一个问题：确实存在速度差异 #

哪怕都用ref传递，struct和class的性能表现也会不一样，你的测试结果（替换成class后性能提升20%）完全符合CLR的底层行为。

2. 为什么都是ref传递，速度却不一致？ #

核心原因在于值类型和引用类型的本质差异，以及JIT编译器对两者的优化策略不同，具体可以拆成这几点：

（1）传递的"引用"本质完全不同 #

• 当你用ref传递class时，你传递的是**「class引用变量的地址」**——而class的引用变量本身只是一个4字节（32位）或8字节（64位）的指针，指向托管堆上的对象实例。方法内部访问对象成员时，是两次解引用：先拿到引用变量的地址，再拿到堆上对象的地址，最后访问成员。
• 当你用ref传递struct时，你传递的是**「struct实例本身的地址」**——如果你的struct包含多个字段、尺寸较大（比如几十字节以上），这个地址指向的是栈上一整块连续的内存。访问struct成员时，是直接解引用到这块内存，但JIT对这种大内存块的访问优化会更保守。

（2）JIT优化的偏向性差异 #

CLR的JIT编译器对引用类型有更成熟的优化支持：

• 逃逸分析：如果JIT检测到class对象不会逃逸出当前方法/线程，会直接把对象分配到栈上（而非托管堆），这时候访问速度和struct接近，但ref传递class时，JIT更容易对小尺寸的引用变量做寄存器分配，减少内存访问开销。
• 别名分析限制：对于ref struct参数，JIT需要考虑是否存在其他ref/out指针指向同一个struct实例（别名问题），这会限制很多优化——比如无法将struct成员缓存到寄存器中，因为可能被其他别名修改。而对于ref class参数，JIT能更清晰地分析别名范围，从而进行更多优化（比如缓存对象成员到寄存器）。

（3）内存缓存的效率差异 #

虽然栈内存访问通常比堆快，但如果你的struct尺寸较大，它可能无法被CPU的L1缓存完全容纳，导致频繁的缓存失效。而class的引用是小尺寸的，即使对象在堆上，引用本身可以被高效缓存，访问对象成员时的缓存命中率反而可能更高（尤其是当对象被频繁访问时）。

（4）方法调用的底层处理不同 #

传递ref struct时，CLR需要严格保证struct的内存对齐，并且JIT对值类型的ref传递有特殊的调用约定处理，开销略高。而ref class的传递本质是传递一个指针的指针，JIT对这种类型的处理更成熟，调用开销更低。

总结 #

所以你之前的理解误区在于：误以为ref传递就让struct和class变成了"一样的引用传递"，但实际上两者传递的内容本质不同，再加上JIT优化、内存访问模式的差异，最终导致了性能差距。如果你的场景对性能敏感，最好以实际测试结果为准来选择类型，而不是单纯依赖理论上的"引用传递等价"假设。

内容的提问来源于stack exchange，提问作者Matthieu Raynaud de Fitte