字符串数组的内存存储机制及访问效率问题

你之前对int数组的内存布局理解完全正确：int是值类型，值类型数组申请的是一整块连续内存，每个槽位直接存元素的实际值，大小固定为32位，通过起始地址+索引偏移就能直接定位到元素值。

int[] i = {1, 2, 3, 4, 5};

对应内存布局：

内存地址	存储值	占用空间
1000	1	32 bit
1001	2	32 bit
1002	3	32 bit
1003	4	32 bit
1004	5	32 bit

但string是引用类型，和值类型的存储逻辑完全不一样：引用类型的数组，连续内存块里存的根本不是字符串本身的内容，而是一个个固定大小的内存指针（32位系统占4字节，64位系统占8字节），每个指针指向托管堆上实际存储字符串对象的独立内存块。字符串的长度、字符内容全存在各自独立的堆内存里，互相之间不需要连续排布。

string[] words = {
    "Hi",
    "Foo",
    "Alphabet",
};
Console.WriteLine (words[2]);
// 输出: "Alphabet"

你把第二个元素替换成更长的"Hopelessness"时，本质只是把数组第二个槽位里存的指针，改成指向堆上新的长字符串对象的地址而已：

string[] words = {
    "Hi",
    "Hopelessness",
    "Alphabet",
};
Console.WriteLine (words[2]);
// 输出仍然是: "Alphabet"

整个过程中第三个槽位里存的指针完全没被改动，它指向的存着"Alphabet"的堆内存也没被修改，自然不会出现你担心的内存覆盖、冲突问题，输出结果当然不会变。你最开始猜测的「数组按最长元素大小给每个元素预留空间」，是C/C++中栈上定长字符数组的实现逻辑，在C#这类托管语言的引用类型场景下不成立。

• 为什么替换第二个字符串为更长内容后，第三个字符串的输出不受影响？
  数组本身只存固定大小的指针，不存字符串实际内容。修改第二个元素仅更新第二个槽位的指针指向，既不会改动第三个槽位存储的指针值，也不会访问、覆盖第三个指针指向的字符串内存，完全不存在冲突的可能。
• 字符串分散存储在不同内存空间，会不会降低大数组的访问速度？
  性能影响极小，几乎可以忽略：
  • 数组的指针存储区是连续内存，定位指定索引的指针的速度和值类型数组完全一致，仅需一次简单的地址偏移计算
  • 拿到指针后访问实际字符串对象是一次CPU级别的指针解引用操作，开销极低
  • 顺序遍历场景下，高频访问的字符串对象会被CPU缓存命中，实际感知不到性能损失。
    反过来如果真按你最初猜想的逻辑，给每个元素按最长字符串长度预留空间，反而会造成极大的内存浪费，大数组内存占用会膨胀数倍，CPU缓存命中率下降，整体性能反而更差。

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