为什么.NET中数组的索引上限是特殊值0x7FEFFFFF？

来自MSDN的官方说明：

数组总大小上限为40亿个元素，任意维度的最大索引为0x7FEFFFFF（字节数组和单字节结构数组的最大索引为0x7FFFFFC7）。

两个边界值的底层设计逻辑 #

两个数值均基于32位有符号整数最大值0x7FFFFFFF（即2^31-1，也是32位进程下用户态地址空间的半区上限）裁剪得到，裁剪规则完全对应CLR的内部运行机制：

1. 字节/单字节结构数组上限 0x7FFFFFC7（即0x7FFFFFFF - 0x38） #

裁剪掉的56字节（0x38）是CLR为托管数组预留的固定开销+边界校验优化空间：

• 托管对象固定元数据开销：每个托管数组需要存储对象头、方法表指针、数组长度字段，x86架构下共占用16字节，x64架构下占用32字节
• 剩余预留空间用于数组边界检查优化：当代码访问数组元素带固定偏移量时（比如访问数组的第N个元素的某字段），CLR无需额外做溢出校验，直接用预留空间兜底，避免每次访问都计算边界带来的性能损耗
• 最终最大索引减去1字节是因为数组索引从0开始计数，所以对应数组总大小为2GB - 57B，和实际运行观测结果一致

2. 普通引用类型/多字节结构数组上限 0x7FEFFFFF（即0x7FFFFFFF - 0x100000） #

裁剪掉的1MB（0x100000）空间是为了适配CLR的索引计算和内存管理规则：

• 多维度数组索引计算保护：多维度数组的元素位置计算需要用到维度1索引 * 维度2长度 + 维度2索引这类乘法+加法逻辑，预留1MB空间可以避免计算结果溢出到有符号整数的负数范围，减少运行时溢出校验的额外开销
• 大对象堆（LOH）兼容：CLR的大对象堆采用分段分配机制，预留1MB空间可以避免数组对象跨越LOH段边界，降低GC整理LOH时的性能损耗
• 向后兼容：该规则从.NET Framework 2.0时代就已确定，后续.NET Core/.NET 5+版本均保留该规则，避免旧版本代码迁移时出现兼容性问题

内容的提问来源于stack exchange，提问作者Nikolay