C#中Memory<T>是否连续存储引用类型？及替代数组的疑问

1. 引用类型在Memory中是否连续存储？ #

Memory本质是一段连续内存的视图包装，它本身不持有数据，只是指向已有的连续内存区域。当T为引用类型时，Memory指向的连续内存里存储的是对象的引用（即指向托管堆对象的指针）——这些引用是连续排列的，但引用所指向的实际对象实例，是分散在托管堆的任意位置，并不连续。

举个例子：当你创建Memory<MyClass>时，底层内存里是一串连续的MyClass类型引用，每个引用各自指向堆上独立的MyClass对象，这些对象本身没有连续性保证。

2. 用Memory存储对象列表，访问对象时是否没有间接寻址？ #

不是。访问Memory中的引用类型对象时，必须先读取Memory里存储的引用，再通过这个引用找到托管堆上的实际对象实例——这就是一次典型的间接寻址。这和普通数组MyClass[]的访问逻辑完全一致：数组同样存储对象引用，访问时也需要经过间接寻址步骤。

3. 为什么不始终用Memory替代普通数组？ #

Memory的灵活性是它的优势，但并非所有场景都适合替代数组，核心原因包括：

• 细微的性能差异：数组是原生的连续集合类型，其长度和内存地址是直接的字段访问；而Memory包含额外的内存范围信息，在极致性能要求的场景（比如高频循环遍历），数组的访问可能略快（日常业务场景中差异通常可忽略）。
• API兼容性限制：大量现有.NET API（尤其是底层interop、老版本库）仅接受数组作为参数，此时你需要将Memory转换为数组（比如通过MemoryMarshal.TryGetArray），反而增加复杂度。
• 语义清晰度：数组的语义是固定大小、连续存储的完整集合，意图更明确；而Memory可以指向数组的切片、非托管内存、自定义内存池区域等，语义更宽泛。如果你的场景就是固定大小的完整连续集合，用数组更能准确表达代码意图。
• 遍历性能优化：数组可以直接被foreach语句优化为高效的遍历；而Memory需要先转换为Span<T>才能获得同等的遍历性能，否则会有额外的包装开销。

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