假設要公開特殊化排序例程，以就地對內存數據執行操作。可能要公開需要使用數組的方法，並提供對相應 T[] 執行操作的實現。如果方法的調用方有數組，且希望對整個數組進行排序，這樣做就非常合適。但如果調用方只想對部分數組進行排序，該怎么辦？可能還要公開需要使用偏移和計數的重載。但如果要支持的內存數據不在數組中，而是來自本機代碼（舉個例子）或位於堆棧上，並且你只有指針和長度，該怎么辦？如何才能讓編寫的排序方法對內存的任意區域執行操作，同時還對完整數組或部分數組以及托管數組和非托管指針同樣有效？
又例如，假設要對 System.String 實現操作，如使用特殊化分析方法。可能要公開需要使用字符串的方法，並提供對字符串執行操作的實現。但如果要支持對部分字符串執行操作，該怎么辦？雖然 String.Substring 可用於分離出僅感興趣的部分，但此操作的成本相對高昂，涉及字符串分配和內存復制。正如數組示例中提到的，可以使用偏移和計數。但如果調用方沒有字符串，而是有 char[]，該怎么辦？或者，如果調用方有 char*（例如為了使用堆棧上某空間而使用 stackalloc 創建的，或通過調用本機代碼而生成的），該怎么辦？如果才能讓編寫的分析方法不強制調用方執行任何分配或復制操作，同時還對輸入的類型字符串、char[] 和 char* 同樣有效？
在這兩個示例中，都可以使用不安全代碼和指針，同時公開接受指針和長度的實現。不過，這樣一來，就無法獲取對 .NET 至關重要的安全保障，並且會遇到對大多數 .NET 開發人員而言已成為過去的問題，如緩沖區溢出和訪問沖突。此外，這還會引發其他性能損失，如需要在操作期間固定托管對象，讓檢索的指針一直有效。而且根據涉及的數據類型，獲取指針根本就不可行。
此難題還是有解決方法的，即使用 Span<T>。
什么是 Span<T>？
System.Span<T> 是在 .NET 中發揮關鍵作用的新值類型。使用它，可以表示任意內存的相鄰區域，無論相應內存是與托管對象相關聯，還是通過互操作由本機代碼提供，亦或是位於堆棧上。除了具有上述用途外，它仍能確保安全訪問和高性能特性，就像數組一樣。
例如，可以通過數組創建 Span<T>：
var arr = new byte[10]; Span<byte> bytes = arr; // Implicit cast from T[] to Span<T>
隨后，可以輕松高效地創建 Span，以利用 Span 的 Slice 方法重載，僅表示/指向此數組的子集。隨后，可以為生成的 Span 編制索引，以編寫和讀取原始數組中相關部分的數據：
Span<byte> slicedBytes = bytes.Slice(start: 5, length: 2); slicedBytes[0] = 42; slicedBytes[1] = 43; Assert.Equal(42, slicedBytes[0]); Assert.Equal(43, slicedBytes[1]); Assert.Equal(arr[5], slicedBytes[0]); Assert.Equal(arr[6], slicedBytes[1]); slicedBytes[2] = 44; // Throws IndexOutOfRangeException bytes[2] = 45; // OK Assert.Equal(arr[2], bytes[2]); Assert.Equal(45, arr[2]);
正如之前提到的，Span 不僅僅只能用於訪問數組和分離出數組子集。還可用於引用堆棧上的數據。例如，
Span<byte> bytes = stackalloc byte[2]; // Using C# 7.2 stackalloc support for spans bytes[0] = 42; bytes[1] = 43; Assert.Equal(42, bytes[0]); Assert.Equal(43, bytes[1]); bytes[2] = 44; // throws IndexOutOfRangeException
更為普遍的是，Span 可用於引用任意指針和長度（如通過本機堆分配的內存），如下所示：
IntPtr ptr = Marshal.AllocHGlobal(1);
try
{
Span<byte> bytes;
unsafe { bytes = new Span<byte>((byte*)ptr, 1); }
bytes[0] = 42;
Assert.Equal(42, bytes[0]);
Assert.Equal(Marshal.ReadByte(ptr), bytes[0]);
bytes[1] = 43; // Throws IndexOutOfRangeException
}
finally { Marshal.FreeHGlobal(ptr); }
Span<T> 索引器利用 C# 7.0 中引入的 C# 語言功能，即引用返回。索引器使用“引用 T”返回類型進行聲明，其中提供為數組編制索引的語義，同時返回對實際存儲位置的引用，而不是相應位置上存在的副本：
public ref T this[int index] { get { ... } }
通過示例，可以最明顯地體現這種引用返回類型索引器帶來的影響，如將它與不是引用返回類型的 List<T> 索引器進行比較。例如：
struct MutableStruct { public int Value; }
...
Span<MutableStruct> spanOfStructs = new MutableStruct[1];
spanOfStructs[0].Value = 42;
Assert.Equal(42, spanOfStructs[0].Value);
var listOfStructs = new List<MutableStruct> { new MutableStruct() };
listOfStructs[0].Value = 42; // Error CS1612: the return value is not a variable
Span<T> 的第二個變體為 System.ReadOnlySpan<T>，可啟用只讀訪問。此類型與 Span<T> 基本類似，不同之處在於前者的索引器利用新 C# 7.2 功能來返回“引用只讀 T”，而不是“引用 T”，這樣就可以處理 System.String 等不可變數據類型。使用 ReadOnlySpan<T>，可以非常高效地分離字符串，而無需執行分配或復制操作，如下所示：
string str = "hello, world";
string worldString = str.Substring(startIndex: 7, length: 5); // Allocates ReadOnlySpan<char> worldSpan =
str.AsReadOnlySpan().Slice(start: 7, length: 5); // No allocation
Assert.Equal('w', worldSpan[0]);
worldSpan[0] = 'a'; // Error CS0200: indexer cannot be assigned to
Span 的優勢還有許多，遠不止已提到的這些。例如，Span 支持 reinterpret_cast 的理念，即可以將 Span<byte> 強制轉換為 Span<int>（其中，Span<int> 中的索引 0 映射到 Span<byte> 的前四個字節）。這樣一來，如果讀取字節緩沖區，可以安全高效地將它傳遞到對分組字節（視作整數）執行操作的方法。
如何實現 Span<T>？
開發人員通常無需了解要使用的庫是如何實現的。不過，對於 Span<T>，對背后的運作機制詳情至少有一個基本了解是值得的，因為這些詳情暗含有關性能和使用約束的相關信息。
首先，Span<T> 是包含引用和長度的值類型，定義大致如下：
public readonly ref struct Span<T>
{
private readonly ref T _pointer;
private readonly int _length;
...
}
“引用 T”字段這一概念初看起來有些奇怪，因為其實無法在 C# 或甚至 MSIL 中聲明“引用 T”字段。不過，Span<T> 實際上旨在於運行時使用特殊內部類型，可看作是內部實時 (JIT) 類型，由 JIT 為其生成等效的“引用 T”字段。以可能更為熟悉的引用用法為例：
public static void AddOne(ref int value) => value += 1;
...
var values = new int[] { 42, 84, 126 };
AddOne(ref values[2]);
Assert.Equal(127, values[2]);
此代碼通過引用傳遞數組中的槽，這樣（除優化外）還可以在堆棧上生成引用 T。Span<T> 中的引用 T 有異曲同工之妙，直接封裝在結構中。直接或間接包含此類引用的類型被稱為類似引用的類型，C# 7.2 編譯器支持在簽名中使用引用結構，從而聲明這種類似引用的類型。
根據這一簡要說明，應明確兩點：
- Span<T> 的定義方式可確保操作效率與數組一樣高：為 Span 編制索引無需通過計算來確定指針開頭及其起始偏移，因為“引用”字段本身已對兩者進行了封裝。（相比之下，ArraySegment<T> 有單獨的偏移字段，這就增加了索引編制和數據傳遞操作的成本。）
- 鑒於類似引用的類型這一本質，Span<T> 因其“引用 T”字段而受到一些約束。
第二點帶來了一些有趣的后果，即導致 .NET 包含第二組相關的類型（由 Memory<T> 主導）。
什么是 Memory<T>？為什么需要它？
Span<T> 是類似引用的類型，因為它包含“引用”字段，而且“引用”字段不僅可以引用數組等對象的開頭，還可以引用它們的中間部分：
var arr = new byte[100]; Span<byte> interiorRef1 = arr.AsSpan().Slice(start: 20); Span<byte> interiorRef2 = new Span<byte>(arr, 20, arr.Length – 20); Span<byte> interiorRef3 = Span<byte>.DangerousCreate(arr, ref arr[20], arr.Length – 20);
這些引用被稱為“內部指針”。對於 .NET 運行時的垃圾回收器，跟蹤這些指針是一項成本相對高昂的操作。因此，運行時將這些引用約束為僅存在於堆棧上，因為它隱式規定了可以存在的內部指針數量下限。
此外，如前所述，Span<T> 大於計算機的字大小；也就是說，對 Span 執行的讀取和寫入操作不是原子操作。如果多個線程同時對 Span 在堆上的字段執行讀取和寫入操作，存在“撕裂”風險。 假設現有一個已初始化的 Span，其中包含有效引用和值為 50 的相應 _length。一個線程開始編寫新 Span，並且還編寫新 _pointer 值。然后，還未將相應的 _length 設置為 20，另一個線程就開始讀取 Span，其中包含新 _pointer 和更長的舊 _length。
這樣一來，Span<T> 示例只能存在於堆棧上，而不能存在於堆上。也就是說，無法將 Span 裝箱，進而無法將 Span<T> 與現有反射調用 API（舉個例子）結合使用，因為它們需要執行裝箱。這意味着，無法將 Span<T> 字段封裝在類中，甚至也無法封裝在不類似引用的結構中。也就是說，如果 Span 可能會隱式成為類中的字段，則無法使用它們。例如，將它們捕獲到 lambda 中，或將它們捕獲為異步方法或迭代器中的本地字段，因為這些本地字段可能最終會成為編譯器生成的狀態機上的字段。 這還意味着，無法將 Span<T> 用作泛型參數，因為類型參數實例可能最終會被裝箱或以其他方式存儲到堆上（暫無“where T : ref struct”約束）。
對於許多方案，尤其是對於受計算量限制和同步處理功能，這些限制無關緊要。不過，異步功能卻是另一回事。無論是處理同步操作還是異步操作，本文開頭提到的大部分有關數組、數組切片和本機內存等問題仍存在。但如果 Span<T> 無法存儲到堆，因而無法跨異步操作暫留，那么還有什么解決方法？答案就是 Memory<T>。
Memory<T> looks very much like an ArraySegment<T>:
public readonly struct Memory<T>
{
private readonly object _object;
private readonly int _index;
private readonly int _length;
...
}
可以通過數組創建 Memory<T>，並進行切片。這與處理 Span 基本相同，不同之處在於 Memory<T> 是不類似引用的結構，可以存在於堆上。然后，若要執行同步處理，可以從中獲取 Span<T>，例如：
static async Task<int> ChecksumReadAsync(Memory<byte> buffer, Stream stream)
{
int bytesRead = await stream.ReadAsync(buffer);
return Checksum(buffer.Span.Slice(0, bytesRead));
// Or buffer.Slice(0, bytesRead).Span
}
static int Checksum(Span<byte> buffer) { ... }
與 Span<T> 和 ReadOnlySpan<T> 一樣，Memory<T> 也有等效的只讀類型，即 ReadOnlyMemory<T>。與預期一樣，它的 Span 屬性返回 ReadOnlySpan<T>。請參閱圖 1，快速概覽在這些類型之間進行轉換的內置機制。
圖 1：在 Span 相關類型之間進行非分配/非復制轉換
| 來自 | 收件人 | 機制 |
| ArraySegment<T> | Memory<T> | 隱式強制轉換、AsMemory 方法 |
| ArraySegment<T> | ReadOnlyMemory<T> | 隱式強制轉換、AsReadOnlyMemory 方法 |
| ArraySegment<T> | ReadOnlySpan<T> | 隱式強制轉換、AsReadOnlySpan 方法 |
| ArraySegment<T> | Span<T> | 隱式強制轉換、AsSpan 方法 |
| ArraySegment<T> | T[] | Array 屬性 |
| Memory<T> | ArraySegment<T> | TryGetArray 方法 |
| Memory<T> | ReadOnlyMemory<T> | 隱式強制轉換、AsReadOnlyMemory 方法 |
| Memory<T> | Span<T> | Span 屬性 |
| ReadOnlyMemory<T> | ArraySegment<T> | DangerousTryGetArray 方法 |
| ReadOnlyMemory<T> | ReadOnlySpan<T> | Span 屬性 |
| ReadOnlySpan<T> | ref readonly T | 索引器 get 取值函數、封送處理方法 |
| Span<T> | ReadOnlySpan<T> | 隱式強制轉換、AsReadOnlySpan 方法 |
| Span<T> | ref T | 索引器 get 取值函數、封送處理方法 |
| 字符串 | ReadOnlyMemory<char> | AsReadOnlyMemory 方法 |
| 字符串 | ReadOnlySpan<char> | 隱式強制轉換、AsReadOnlySpan 方法 |
| T[] | ArraySegment<T> | 構造函數、隱式強制轉換 |
| T[] | Memory<T> | 構造函數、隱式強制轉換、AsMemory 方法 |
| T[] | ReadOnlyMemory<T> | 構造函數、隱式強制轉換、AsReadOnlyMemory 方法 |
| T[] | ReadOnlySpan<T> | 構造函數、隱式強制轉換、AsReadOnlySpan 方法 |
| T[] | Span<T> | 構造函數、隱式強制轉換、AsSpan 方法 |
| void* | ReadOnlySpan<T> | 構造函數 |
| void* | Span<T> | 構造函數 |
將會注意到，Memory<T> 的 _object 字段並未強類型化為 T[]，而是存儲為對象。這突出說明 Memory<T> 可以包裝數組以外的內容，如 System.Buffers.OwnedMemory<T>。OwnedMemory<T> 是抽象類，可用於包裝需要密切管理其生存期的數據，如從池中檢索到的內存。此主題更為高級，超出了本文的介紹范圍，但這就是 Memory<T> 的用途所在（例如，用於將指針包裝到本機內存）。ReadOnlyMemory<char> 也可以與字符串結合使用，就像 ReadOnlySpan<char> 一樣。
Span<T> 和 Memory<T> 如何與 .NET 庫集成？
在上面的 Memory<T> 代碼片段中，將會注意到傳入 Memory<byte> 的 Stream.ReadAsync 調用。但如今在 .NET 中，Stream.ReadAsync 被定義為接受 byte[]。它的工作原理是什么？
為了支持 Span<T> 及其成員，即將向 .NET 添加數百個新成員和類型。其中大多是現有基於數組和基於字符串的方法的重載，而另一些則是專注於特定處理方面的全新類型。例如，除了包含需要使用字符串的現有重載外，所有原始類型（如 Int32）現在都包含接受 ReadOnlySpan<char> 的 Parse 重載。假設字符串包含兩部分數字（用逗號隔開，如“123,456”），且希望分析這部分數字。現在，可以編寫如下代碼：
string input = ...;
int commaPos = input.IndexOf(',');
int first = int.Parse(input.Substring(0, commaPos));
int second = int.Parse(input.Substring(commaPos + 1));
不過，這會生成兩個字符串分配。若要編寫高性能代碼，兩個字符串分配可能就太多了。此時，可以改為編寫如下代碼：
string input = ...;
ReadOnlySpan<char> inputSpan = input.AsReadOnlySpan();
int commaPos = input.IndexOf(',');
int first = int.Parse(inputSpan.Slice(0, commaPos));
int second = int.Parse(inputSpan.Slice(commaPos + 1));
通過使用基於 Span 的新 Parse 重載，可以在這整個操作期間避免執行分配操作。類似分析和格式化方法可用於原始類型（如 Int32），其中包括 DateTime、TimeSpan 和 Guid 等核心類型，甚至還包括 BigInteger 和 IPAddress 等更高級別類型。
實際上，已跨框架添加了許多這樣的方法。從 System.Random 到 System.Text.StringBuilder，再到 System.Net.Socket，這些重載的添加有利於輕松高效地處理 {ReadOnly}Span<T> 和 {ReadOnly}Memory<T>。其中一些甚至帶來了額外的好處。例如，Stream 現包含以下方法：
public virtual ValueTask<int> ReadAsync(
Memory<byte> destination,
CancellationToken cancellationToken = default) { ... }
將會注意到，不同於接受 byte[] 並返回 Task<int> 的現有 ReadAsync 方法，此重載不僅接受 Memory<byte>（而不是 byte[]），還返回 ValueTask<int>（而不是 Task<int>）。在以下情況下，ValueTask<T> 是有助於避免執行分配操作的結構：經常要求使用異步方法來同步返回內容，以及不太可能為所有常見返回值緩存已完成任務。例如，運行時可以為結果 true 和 false 緩存已完成的 Task<bool>，但無法為 Task<int> 的所有可能結果值緩存四十億任務對象。
由於相當常見的是 Stream 實現的緩沖方式讓 ReadAsync 調用同步完成，因此這一新 ReadAsync 重載返回 ValueTask<int>。也就是說，同步完成的異步 Stream 讀取操作可以完全避免執行分配操作。ValueTask<T> 也用於其他新重載，如 Socket.ReceiveAsync、Socket.SendAsync、WebSocket.ReceiveAsync 和 TextReader.ReadAsync 重載。
此外，在一些情況下，Span<T> 還支持向框架添加在過去引發內存安全問題的方法。假設要創建的字符串包含隨機生成的值（如某類 ID）。現在，可能會編寫要求分配字符數組的代碼，如下所示：
int length = ...;
Random rand = ...;
var chars = new char[length];
for (int i = 0; i < chars.Length; i++)
{
chars[i] = (char)(rand.Next(0, 10) + '0');
}
string id = new string(chars);
可以改用堆棧分配，甚至能夠利用 Span<char>，這樣就無需使用不安全代碼。此方法還利用接受 ReadOnlySpan<char> 的新字符串構造函數，如下所示：
int length = ...;
Random rand = ...;
Span<char> chars = stackalloc char[length];
for (int i = 0; i < chars.Length; i++)
{
chars[i] = (char)(rand.Next(0, 10) + '0');
}
string id = new string(chars);
這樣做更好，因為避免了堆分配，但仍不得不將堆棧上生成的數據復制到字符串中。同樣，只有在所需空間大小對於堆棧而言足夠小時，此方法才有效。如果長度較短（如 32 個字節），可以使用此方法；但如果長度為數千字節，很容易就會引發堆棧溢出問題。如果可以改為直接寫入字符串的內存，該怎么辦？Span<T> 可以實現此目的。除了包含新構造函數以外，字符串現在還包含 Create 方法：
public static string Create<TState>( int length, TState state, SpanAction<char, TState> action); ... public delegate void SpanAction<T, in TArg>(Span<T> span, TArg arg);
實現此方法是為了分配字符串，並分發可寫 Span，執行寫入操作后可以在構造字符串的同時填寫字符串的內容。請注意，在此示例中，Span<T> 的僅限堆棧這一本質非常有用，因為可以保證在字符串的構造函數完成前 Span（引用字符串的內部存儲）就不存在，這樣便無法在構造完成后使用 Span 改變字符串了：
int length = ...;
Random rand = ...;
string id = string.Create(length, rand, (Span<char> chars, Random r) =>
{
for (int i = 0; chars.Length; i++)
{
chars[i] = (char)(r.Next(0, 10) + '0');
}
});
現在，不僅避免了分配操作，還可以直接寫入字符串在堆上的內存，即也避免了復制操作，且不受堆棧大小限制的約束。
除了核心框架類型有新成員外，我們還正在積極開發許多可與 Span 結合使用的新 .NET 類型，從而在特定方案中實現高效處理。例如，對於要編寫高性能微服務和處理大量文本的網站的開發人員，如果在使用 UTF-8 時無需編碼和解碼字符串，則性能會大大提升。為此，我們即將添加 System.Buffers.Text.Base64、System.Buffers.Text.Utf8Parser 和 System.Buffers.Text.Utf8Formatter 等新類型。這些類型對字節 Span 執行操作，不僅避免了 Unicode 編碼和解碼，還能夠處理在各種網絡堆棧的最低級別中常見的本機緩沖：
ReadOnlySpan<byte> utf8Text = ...; if (!Utf8Parser.TryParse(utf8Text, out Guid value, out int bytesConsumed, standardFormat = 'P')) throw new InvalidDataException();
所有此類功能不僅僅只用於公共使用用途；框架本身也可以利用這些基於 Span<T> 和基於 Memory<T> 的新方法來提升性能。跨 .NET Core 調用網站已切換為使用新的 ReadAsync 重載，以避免不必要的分配操作。分析過去是通過分配子字符串完成，現在可以避免執行分配操作。甚至 Rfc2898DeriveBytes 等間隙類型也實際運用了此功能，利用 System.Security.Cryptography.HashAlgorithm 上基於 Span<byte> 的新 TryComputeHash 方法顯著減少分配操作量（每次算法迭代的字節數組，可能迭代數千次）和提升吞吐量。
這並未止步於核心 .NET 庫一級，而是繼續全面影響堆棧。ASP.NET Core 現在嚴重依賴 Span；例如，在 Span 基礎之上編寫 Kestrel 服務器的 HTTP 分析程序。Span 今后可能會通過較低級別 ASP.NET Core 中的公共 API 公開，如在它的中間件管道中。
.NET 運行時又如何呢？
.NET 運行時提供安全保障的方法之一是，確保為數組編制的索引不超出數組的長度，這種做法稱為“邊界檢查”。例如，以下面這個方法為例：
[MethodImpl(MethodImplOptions.NoInlining)] static int Return4th(int[] data) => data[3];
在我撰寫本文使用的 x64 計算機上，針對此方法生成的程序集如下所示：
sub rsp, 40 cmp dword ptr [rcx+8], 3 jbe SHORT G_M22714_IG04 mov eax, dword ptr [rcx+28] add rsp, 40 ret G_M22714_IG04: call CORINFO_HELP_RNGCHKFAIL int3
cmp 指令將數據數組的長度與索引 3 進行比較。如果 3 超出范圍（異常拋出），后續 jbe 指令會轉到范圍檢查失敗例程。雖然 JIT 需要生成代碼，以確保此類訪問不會超出數組邊界，但這並不意味着每個數組訪問都需要進行邊界檢查。以下面的 Sum 方法為例：
static int Sum(int[] data)
{
int sum = 0;
for (int i = 0; i < data.Length; i++) sum += data[i];
return sum;
}
雖然 JIT 此時需要生成代碼，以確保對 data[i] 的訪問不超出數組邊界，但因為 JIT 能夠通過循環結構判斷 i 一直在范圍內（循環從頭到尾遍歷每個元素），所以 JIT 可以優化為不對數組進行邊界檢查。因此，針對循環生成的程序集代碼如下所示：
G_M33811_IG03: movsxd r9, edx add eax, dword ptr [rcx+4*r9+16] inc edx cmp r8d, edx jg SHORT G_M33811_IG03
雖然 cmp 指令仍在循環中，但只需將 i 值（存儲在 edx 寄存器中）與數組長度（存儲在 r8d 寄存器中）進行比較，無需額外進行邊界檢查。
運行時向 Span（Span<T> 和 ReadOnlySpan<T>）應用類似優化。將上面的示例與下面的代碼進行比較，唯一的變化是參數類型：
static int Sum(Span<int> data)
{
int sum = 0;
for (int i = 0; i < data.Length; i++) sum += data[i];
return sum;
}
針對此代碼生成的程序集幾乎完全相同：
G_M33812_IG03: movsxd r9, r8d add ecx, dword ptr [rax+4*r9] inc r8d cmp r8d, edx jl SHORT G_M33812_IG03
程序集代碼如此相似，部分是因為不用進行邊界檢查。此外，同樣重要的是 JIT 將 Span 索引器識別為內部類型，即 JIT 為索引器生成特殊代碼，而不是將它的實際 IL 代碼轉換為程序集。
所有這些都是為了說明運行時可以為 Span 應用與數組相同的優化類型，讓 Span 成為高效的數據訪問機制。如需了解更多詳情，請參閱 bit.ly/2zywvyI 上的博客文章。
C# 語言和編譯器又如何呢？
我已暗示，添加到 C# 語言和編譯器的功能有助於讓 Span<T> 成為 .NET 中的一流成員。C# 7.2 的多項功能都與 Span 相關（實際上，C# 7.2 編譯器必須使用 Span<T>）。接下來，將介紹三個此類功能。
引用結構。如前所述，Span<T> 是類似引用的類型，自版本 7.2 起在 C# 中公開為引用結構。通過將引用關鍵字置於結構前，可以指示 C# 編譯器將其他引用結構類型（如 Span<T>）用作字段，這樣做還會注冊要分配給類型的相關約束。例如，若要為 Span<T> 編寫結構枚舉器，枚舉器需要存儲 Span<T>，因此它本身必須是引用結構，如下所示：
public ref struct Enumerator
{
private readonly Span<char> _span;
private int _index;
...
}
Span 的 stackalloc 初始化。在舊版 C# 中，只能將 stackalloc 的結果存儲到指針本地變量中。自 C# 7.2 起，現在可以在表達式中使用 stackalloc，並能定目標到 Span，而不使用不安全關鍵字。因為，無需編寫：
Span<byte> bytes;
unsafe
{
byte* tmp = stackalloc byte[length];
bytes = new Span<byte>(tmp, length);
}
只需編寫：
Span<byte> bytes = stackalloc byte[length];
如果需要一些空間來執行操作，但又希望避免分配相對較小的堆內存，此代碼就非常有用。過去有以下兩種選擇：
- 編寫兩個完全不同的代碼路徑，對基於堆棧的內存和基於堆的內存執行分配和操作。
- 固定與托管分配相關聯的內存，再委托到實現，實現也用於基於堆棧的內存，並通過不安全代碼中的指針控制進行編寫。
現在，不使用代碼復制，即可完成相同的操作，而且還可以使用安全代碼和最簡單的操作：
Span<byte> bytes = length <= 128 ? stackalloc byte[length] : new byte[length]; ... // Code that operates on the Span<byte>
Span 使用驗證。因為 Span 可以引用可能與給定堆棧幀相關聯的數據，所以傳遞 Span 可能存在危險，此操作可能會引用不再有效的內存。例如，假設方法嘗試執行以下操作：
static Span<char> FormatGuid(Guid guid)
{
Span<char> chars = stackalloc char[100];
bool formatted = guid.TryFormat(chars, out int charsWritten, "d");
Debug.Assert(formatted);
return chars.Slice(0, charsWritten); // Uh oh
}
此時，空間從堆棧進行分配，然后嘗試返回對此空間的引用，但在返回的同時，此空間不再可用。幸運的是，C# 編譯器使用引用結構檢測此類無效使用，並會停止編譯，同時顯示以下錯誤：
錯誤 CS8352:無法在此上下文中使用本地“字符”，因為它可能會在聲明范圍外公開引用的變量
接下來會怎樣呢？
本文介紹的類型、方法、運行時優化和其他元素即將順利添加到 .NET Core 2.1 中。之后，我預計它們會全面影響 .NET Framework。核心類型（如 Span<T>）和新類型（如 Utf8Parser）也即將順利添加到與 .NET Standard 1.1 兼容的 System.Memory.dll 包中。這樣一來，相關功能將適用於現有 .NET Framework 和 .NET Core 版本，盡管在內置於平台時沒有實現一些優化。現在，可以試用此包的預覽版，只需添加對 NuGet 上 System.Memory.dll 包的引用即可。
當然，請注意，當前預覽版與實際發布的穩定版之間可能會有重大變革。此類變革很大程度上源於像你這樣的開發人員在試用功能集時提供的反饋。因此，請試用預覽版，並關注 github.com/dotnet/coreclr 和 github.com/dotnet/corefx 存儲庫，以掌握最新動態。此外，有關文檔，還可以訪問 aka.ms/ref72。
總的來說，此功能集能否取得成功依賴開發人員試用預覽版、提供反饋以及利用這些類型生成自己的庫，所有這些都是為了能夠在新式 .NET 程序中高效安全地訪問內存。我們熱切期待聆聽大家的使用體驗反饋，最好能夠與大家一起在 GitHub 上進一步改進 .NET。
Stephen Toub 就職於 Microsoft，負責 .NET 產品。可以在 GitHub (github.com/stephentoub) 上關注他。
本文轉自 https://msdn.microsoft.com/zh-cn/magazine/mt814808