内联数组加速数组访问的核心是栈/内联内存连续性、jit零开销索引展开和无gc干扰，而非内联缓存；c#中数组索引优化依赖编译期确定性、硬件局部性和jit直接偏移计算。
内联缓存（Inline Cache）和内联数组（Inline Array）是两个容易混淆但本质不同的概念。你提到的“高频访问数组索引的加速”，实际起关键作用的是内联数组的内存布局与 JIT 编译器的索引优化，而非传统意义的“内联缓存”（后者常见于动态语言如 JavaScript、Ruby 的方法分派优化中）。C# 中没有运行时意义上的“内联缓存”用于数组索引——它靠的是编译期确定性 + 硬件级局部性 + JIT 的直接偏移生成。
为什么不是“内联缓存”在加速数组访问？
C# 是静态类型语言，数组类型和元素大小在编译期已知。JIT 编译器无需像动态语言那样为每次 a[i] 去查“这个对象到底有没有 int[] 类型的 get_Item 方法”，也无需缓存上次调用的虚方法表入口。它的优化路径更底层、更直接：
- 索引表达式
buffer[i]被编译为基于结构体基地址的固定偏移计算：base_addr + i * sizeof(int) - 边界检查在 Release 模式下常被 JIT 消除（尤其在 for 循环中已知
i ） - 连续内存布局使 CPU 预取器能提前加载后续 cache line，一次加载覆盖多个后续访问
真正起加速作用的三大机制
高频数组访问变快，核心依赖以下三者协同：
-
栈/内联内存连续性：内联数组元素紧挨着存放在结构体内，无指针跳转。CPU 访问
buffer[0]后，buffer[1]极大概率已在同一 cache line（64 字节）中，避免额外内存延迟 -
JIT 的零开销索引展开：在简单循环中，JIT 可将
buffer[i]直接编译为寄存器加法 + 存储指令，例如：mov eax, [rbp-24] ; base addrmov [rax], 0mov [rax+4], 4
——完全绕过数组对象头、长度字段、边界检查分支 - 无 GC 干扰与确定生命周期：内联数组随宿主结构体分配在栈或值类型字段中，函数返回即自动回收。不会触发 GC 暂停，也不会因堆碎片导致缓存行跨页
对比：传统数组为何慢一点？
一个 int[] data = new int[10] 的访问流程更长：
- 必须先读取
data引用指向的堆地址 - 再从该地址读取数组对象头（含长度、类型信息）
- 执行边界检查（除非 JIT 证明安全）
- 最后计算
obj_header + 8 + i * 4才拿到真实数据地址 - 且堆上内存可能不连续、跨 cache line、甚至跨页，降低预取效率
如何验证这种加速效果？
写一个简单基准测试，对比两种结构体：
- 带
[InlineArray(1024)]的struct Buffer - 含
int[]字段的传统class Wrapper
在 Release 模式下用 BenchmarkDotNet 测量循环求和。你会发现内联版本耗时通常只有传统方式的 30%–50%，差距主要来自上述三方面叠加效应，而非某种“缓存命中记录”。
