假設(shè)要公開特殊化排序例程，以就地對內(nèi)存數(shù)據(jù)執(zhí)行操作。可能要公開需要使用數(shù)組的方法，并提供對相應(yīng) T[] 執(zhí)行操作的實現(xiàn)。如果方法的調(diào)用方有數(shù)組，且希望對整個數(shù)組進行排序，這樣做就非常合適。但如果調(diào)用方只想對部分數(shù)組進行排序，該怎么辦？可能還要公開需要使用偏移和計數(shù)的重載。但如果要支持的內(nèi)存數(shù)據(jù)不在數(shù)組中，而是來自本機代碼（舉個例子）或位于堆棧上，并且你只有指針和長度，該怎么辦？如何才能讓編寫的排序方法對內(nèi)存的任意區(qū)域執(zhí)行操作，同時還對完整數(shù)組或部分數(shù)組以及托管數(shù)組和非托管指針同樣有效？

又例如，假設(shè)要對 System.String 實現(xiàn)操作，如使用特殊化分析方法。可能要公開需要使用字符串的方法，并提供對字符串執(zhí)行操作的實現(xiàn)。但如果要支持對部分字符串執(zhí)行操作，該怎么辦？雖然 String.Substring 可用于分離出僅感興趣的部分，但此操作的成本相對高昂，涉及字符串分配和內(nèi)存復(fù)制。正如數(shù)組示例中提到的，可以使用偏移和計數(shù)。但如果調(diào)用方?jīng)]有字符串，而是有 char[]，該怎么辦？或者，如果調(diào)用方有 char*（例如為了使用堆棧上某空間而使用 stackalloc 創(chuàng)建的，或通過調(diào)用本機代碼而生成的），該怎么辦？如果才能讓編寫的分析方法不強制調(diào)用方執(zhí)行任何分配或復(fù)制操作，同時還對輸入的類型字符串、char[] 和 char* 同樣有效？

在這兩個示例中，都可以使用不安全代碼和指針，同時公開接受指針和長度的實現(xiàn)。不過，這樣一來，就無法獲取對 .NET 至關(guān)重要的安全保障，并且會遇到對大多數(shù) .NET 開發(fā)人員而言已成為過去的問題，如緩沖區(qū)溢出和訪問沖突。此外，這還會引發(fā)其他性能損失，如需要在操作期間固定托管對象，讓檢索的指針一直有效。而且根據(jù)涉及的數(shù)據(jù)類型，獲取指針根本就不可行。

此難題還是有解決方法的，即使用 Span<T>。

什么是 Span<T>？

System.Span<T> 是在 .NET 中發(fā)揮關(guān)鍵作用的新值類型。使用它，可以表示任意內(nèi)存的相鄰區(qū)域，無論相應(yīng)內(nèi)存是與托管對象相關(guān)聯(lián)，還是通過互操作由本機代碼提供，亦或是位于堆棧上。除了具有上述用途外，它仍能確保安全訪問和高性能特性，就像數(shù)組一樣。

例如，可以通過數(shù)組創(chuàng)建 Span<T>：

var arr = new byte[10]; Span<byte> bytes = arr; // Implicit cast from T[] to Span<T>

隨后，可以輕松高效地創(chuàng)建 Span，以利用 Span 的 Slice 方法重載，僅表示/指向此數(shù)組的子集。隨后，可以為生成的 Span 編制索引，以編寫和讀取原始數(shù)組中相關(guān)部分的數(shù)據(jù)：

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 IndexOutOfRangeExceptionbytes[2] = 45; // OK
Assert.Equal(arr[2], bytes[2]); Assert.Equal(45, arr[2]);

正如之前提到的，Span 不僅僅只能用于訪問數(shù)組和分離出數(shù)組子集。還可用于引用堆棧上的數(shù)據(jù)。例如，

Span<byte> bytes = stackalloc byte[2]; // Using C# 7.2 stackalloc support for spansbytes[0] = 42; bytes[1] = 43; Assert.Equal(42, bytes[0]); Assert.Equal(43, bytes[1]); bytes[2] = 44; // throws IndexOutOfRangeException

更為普遍的是，Span 可用于引用任意指針和長度（如通過本機堆分配的內(nèi)存），如下所示：

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”返回類型進行聲明，其中提供為數(shù)組編制索引的語義，同時返回對實際存儲位置的引用，而不是相應(yīng)位置上存在的副本：

public ref T this[int index] { get { ... } }

通過示例，可以最明顯地體現(xiàn)這種引用返回類型索引器帶來的影響，如將它與不是引用返回類型的 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 等不可變數(shù)據(jù)類型。使用 ReadOnlySpan<T>，可以非常高效地分離字符串，而無需執(zhí)行分配或復(fù)制操作，如下所示：

string str = "hello, world";string worldString = str.Substring(startIndex: 7, length: 5); // Allocates ReadOnlySpan<char> worldSpan =? str.AsReadOnlySpan().Slice(start: 7, length: 5); // No allocationAssert.Equal('w', worldSpan[0]); worldSpan[0] = 'a'; // Error CS0200: indexer cannot be assigned to

Span 的優(yōu)勢還有許多，遠不止已提到的這些。例如，Span 支持 reinterpret_cast 的理念，即可以將 Span<byte> 強制轉(zhuǎn)換為 Span<int>（其中，Span<int> 中的索引 0 映射到 Span<byte> 的前四個字節(jié)）。這樣一來，如果讀取字節(jié)緩沖區(qū)，可以安全高效地將它傳遞到對分組字節(jié)（視作整數(shù)）執(zhí)行操作的方法。

如何實現(xiàn) Span<T>？

開發(fā)人員通常無需了解要使用的庫是如何實現(xiàn)的。不過，對于 Span<T>，對背后的運作機制詳情至少有一個基本了解是值得的，因為這些詳情暗含有關(guān)性能和使用約束的相關(guān)信息。

首先，Span<T> 是包含引用和長度的值類型，定義大致如下：

public readonly ref struct Span<T> {private readonly ref T _pointer;private readonly int _length;... }

“引用 T”字段這一概念初看起來有些奇怪，因為其實無法在 C# 或甚至 MSIL 中聲明“引用 T”字段。不過，Span<T> 實際上旨在于運行時使用特殊內(nèi)部類型，可看作是內(nèi)部實時 (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]);

此代碼通過引用傳遞數(shù)組中的槽，這樣（除優(yōu)化外）還可以在堆棧上生成引用 T。Span<T> 中的引用 T 有異曲同工之妙，直接封裝在結(jié)構(gòu)中。直接或間接包含此類引用的類型被稱為類似引用的類型，C# 7.2 編譯器支持在簽名中使用引用結(jié)構(gòu)，從而聲明這種類似引用的類型。

根據(jù)這一簡要說明，應(yīng)明確兩點：

Span<T> 的定義方式可確保操作效率與數(shù)組一樣高：為 Span 編制索引無需通過計算來確定指針開頭及其起始偏移，因為“引用”字段本身已對兩者進行了封裝。（相比之下，ArraySegment<T> 有單獨的偏移字段，這就增加了索引編制和數(shù)據(jù)傳遞操作的成本。）

鑒于類似引用的類型這一本質(zhì)，Span<T> 因其“引用 T”字段而受到一些約束。

第二點帶來了一些有趣的后果，即導(dǎo)致 .NET 包含第二組相關(guān)的類型（由 Memory<T> 主導(dǎo)）。

什么是 Memory<T>？為什么需要它？

Span<T> 是類似引用的類型，因為它包含“引用”字段，而且“引用”字段不僅可以引用數(shù)組等對象的開頭，還可以引用它們的中間部分：

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);

這些引用被稱為“內(nèi)部指針”。對于 .NET 運行時的垃圾回收器，跟蹤這些指針是一項成本相對高昂的操作。因此，運行時將這些引用約束為僅存在于堆棧上，因為它隱式規(guī)定了可以存在的內(nèi)部指針數(shù)量下限。

此外，如前所述，Span<T> 大于計算機的字大小；也就是說，對 Span 執(zhí)行的讀取和寫入操作不是原子操作。如果多個線程同時對 Span 在堆上的字段執(zhí)行讀取和寫入操作，存在“撕裂”風險。 假設(shè)現(xiàn)有一個已初始化的 Span，其中包含有效引用和值為 50 的相應(yīng) _length。一個線程開始編寫新 Span，并且還編寫新 _pointer 值。然后，還未將相應(yīng)的 _length 設(shè)置為 20，另一個線程就開始讀取 Span，其中包含新 _pointer 和更長的舊 _length。

這樣一來，Span<T> 示例只能存在于堆棧上，而不能存在于堆上。也就是說，無法將 Span 裝箱，進而無法將 Span<T> 與現(xiàn)有反射調(diào)用 API（舉個例子）結(jié)合使用，因為它們需要執(zhí)行裝箱。這意味著，無法將 Span<T> 字段封裝在類中，甚至也無法封裝在不類似引用的結(jié)構(gòu)中。也就是說，如果 Span 可能會隱式成為類中的字段，則無法使用它們。例如，將它們捕獲到 lambda 中，或?qū)⑺鼈儾东@為異步方法或迭代器中的本地字段，因為這些本地字段可能最終會成為編譯器生成的狀態(tài)機上的字段。 這還意味著，無法將 Span<T> 用作泛型參數(shù)，因為類型參數(shù)實例可能最終會被裝箱或以其他方式存儲到堆上（暫無“where T : ref struct”約束）。

對于許多方案，尤其是對于受計算量限制和同步處理功能，這些限制無關(guān)緊要。不過，異步功能卻是另一回事。無論是處理同步操作還是異步操作，本文開頭提到的大部分有關(guān)數(shù)組、數(shù)組切片和本機內(nèi)存等問題仍存在。但如果 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;... }

可以通過數(shù)組創(chuàng)建 Memory<T>，并進行切片。這與處理 Span 基本相同，不同之處在于 Memory<T> 是不類似引用的結(jié)構(gòu)，可以存在于堆上。然后，若要執(zhí)行同步處理，可以從中獲取 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>。與預(yù)期一樣，它的 Span 屬性返回 ReadOnlySpan<T>。請參閱圖 1，快速概覽在這些類型之間進行轉(zhuǎn)換的內(nèi)置機制。

圖 1：在 Span 相關(guān)類型之間進行非分配/非復(fù)制轉(zhuǎn)換

來自	收件人	機制
ArraySegment<T>	Memory<T>	隱式強制轉(zhuǎn)換、AsMemory 方法
ArraySegment<T>	ReadOnlyMemory<T>	隱式強制轉(zhuǎn)換、AsReadOnlyMemory 方法
ArraySegment<T>	ReadOnlySpan<T>	隱式強制轉(zhuǎn)換、AsReadOnlySpan 方法
ArraySegment<T>	Span<T>	隱式強制轉(zhuǎn)換、AsSpan 方法
ArraySegment<T>	T[]	Array 屬性
Memory<T>	ArraySegment<T>	TryGetArray 方法
Memory<T>	ReadOnlyMemory<T>	隱式強制轉(zhuǎn)換、AsReadOnlyMemory 方法
Memory<T>	Span<T>	Span 屬性
ReadOnlyMemory<T>	ArraySegment<T>	DangerousTryGetArray 方法
ReadOnlyMemory<T>	ReadOnlySpan<T>	Span 屬性
ReadOnlySpan<T>	ref readonly T	索引器 get 取值函數(shù)、封送處理方法
Span<T>	ReadOnlySpan<T>	隱式強制轉(zhuǎn)換、AsReadOnlySpan 方法
Span<T>	ref T	索引器 get 取值函數(shù)、封送處理方法
字符串	ReadOnlyMemory<char>	AsReadOnlyMemory 方法
字符串	ReadOnlySpan<char>	隱式強制轉(zhuǎn)換、AsReadOnlySpan 方法
T[]	ArraySegment<T>	構(gòu)造函數(shù)、隱式強制轉(zhuǎn)換
T[]	Memory<T>	構(gòu)造函數(shù)、隱式強制轉(zhuǎn)換、AsMemory 方法
T[]	ReadOnlyMemory<T>	構(gòu)造函數(shù)、隱式強制轉(zhuǎn)換、AsReadOnlyMemory 方法
T[]	ReadOnlySpan<T>	構(gòu)造函數(shù)、隱式強制轉(zhuǎn)換、AsReadOnlySpan 方法
T[]	Span<T>	構(gòu)造函數(shù)、隱式強制轉(zhuǎn)換、AsSpan 方法
void*	ReadOnlySpan<T>	構(gòu)造函數(shù)
void*	Span<T>	構(gòu)造函數(shù)

將會注意到，Memory<T> 的 _object 字段并未強類型化為 T[]，而是存儲為對象。這突出說明 Memory<T> 可以包裝數(shù)組以外的內(nèi)容，如 System.Buffers.OwnedMemory<T>。OwnedMemory<T> 是抽象類，可用于包裝需要密切管理其生存期的數(shù)據(jù)，如從池中檢索到的內(nèi)存。此主題更為高級，超出了本文的介紹范圍，但這就是 Memory<T> 的用途所在（例如，用于將指針包裝到本機內(nèi)存）。ReadOnlyMemory<char> 也可以與字符串結(jié)合使用，就像 ReadOnlySpan<char> 一樣。

Span<T> 和 Memory<T> 如何與 .NET 庫集成？

在上面的 Memory<T> 代碼片段中，將會注意到傳入 Memory<byte> 的 Stream.ReadAsync 調(diào)用。但如今在 .NET 中，Stream.ReadAsync 被定義為接受 byte[]。它的工作原理是什么？

為了支持 Span<T> 及其成員，即將向 .NET 添加數(shù)百個新成員和類型。其中大多是現(xiàn)有基于數(shù)組和基于字符串的方法的重載，而另一些則是專注于特定處理方面的全新類型。例如，除了包含需要使用字符串的現(xiàn)有重載外，所有原始類型（如 Int32）現(xiàn)在都包含接受 ReadOnlySpan<char> 的 Parse 重載。假設(shè)字符串包含兩部分數(shù)字（用逗號隔開，如“123,456”），且希望分析這部分數(shù)字。現(xiàn)在，可以編寫如下代碼：

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 重載，可以在這整個操作期間避免執(zhí)行分配操作。類似分析和格式化方法可用于原始類型（如 Int32），其中包括 DateTime、TimeSpan 和 Guid 等核心類型，甚至還包括 BigInteger 和 IPAddress 等更高級別類型。

實際上，已跨框架添加了許多這樣的方法。從 System.Random 到 System.Text.StringBuilder，再到 System.Net.Socket，這些重載的添加有利于輕松高效地處理 {ReadOnly}Span<T> 和 {ReadOnly}Memory<T>。其中一些甚至帶來了額外的好處。例如，Stream 現(xiàn)包含以下方法：

public virtual ValueTask<int> ReadAsync(Memory<byte> destination,CancellationToken cancellationToken = default) { ... }

將會注意到，不同于接受 byte[] 并返回 Task<int> 的現(xiàn)有 ReadAsync 方法，此重載不僅接受 Memory<byte>（而不是 byte[]），還返回 ValueTask<int>（而不是 Task<int>）。在以下情況下，ValueTask<T> 是有助于避免執(zhí)行分配操作的結(jié)構(gòu)：經(jīng)常要求使用異步方法來同步返回內(nèi)容，以及不太可能為所有常見返回值緩存已完成任務(wù)。例如，運行時可以為結(jié)果 true 和 false 緩存已完成的 Task<bool>，但無法為 Task<int> 的所有可能結(jié)果值緩存四十億任務(wù)對象。

由于相當常見的是 Stream 實現(xiàn)的緩沖方式讓 ReadAsync 調(diào)用同步完成，因此這一新 ReadAsync 重載返回 ValueTask<int>。也就是說，同步完成的異步 Stream 讀取操作可以完全避免執(zhí)行分配操作。ValueTask<T> 也用于其他新重載，如 Socket.ReceiveAsync、Socket.SendAsync、WebSocket.ReceiveAsync 和 TextReader.ReadAsync 重載。

此外，在一些情況下，Span<T> 還支持向框架添加在過去引發(fā)內(nèi)存安全問題的方法。假設(shè)要創(chuàng)建的字符串包含隨機生成的值（如某類 ID）。現(xiàn)在，可能會編寫要求分配字符數(shù)組的代碼，如下所示：

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> 的新字符串構(gòu)造函數(shù)，如下所示：

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);

這樣做更好，因為避免了堆分配，但仍不得不將堆棧上生成的數(shù)據(jù)復(fù)制到字符串中。同樣，只有在所需空間大小對于堆棧而言足夠小時，此方法才有效。如果長度較短（如 32 個字節(jié)），可以使用此方法；但如果長度為數(shù)千字節(jié)，很容易就會引發(fā)堆棧溢出問題。如果可以改為直接寫入字符串的內(nèi)存，該怎么辦？Span<T> 可以實現(xiàn)此目的。除了包含新構(gòu)造函數(shù)以外，字符串現(xiàn)在還包含 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);

實現(xiàn)此方法是為了分配字符串，并分發(fā)可寫 Span，執(zhí)行寫入操作后可以在構(gòu)造字符串的同時填寫字符串的內(nèi)容。請注意，在此示例中，Span<T> 的僅限堆棧這一本質(zhì)非常有用，因為可以保證在字符串的構(gòu)造函數(shù)完成前 Span（引用字符串的內(nèi)部存儲）就不存在，這樣便無法在構(gòu)造完成后使用 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');} });

現(xiàn)在，不僅避免了分配操作，還可以直接寫入字符串在堆上的內(nèi)存，即也避免了復(fù)制操作，且不受堆棧大小限制的約束。

除了核心框架類型有新成員外，我們還正在積極開發(fā)許多可與 Span 結(jié)合使用的新 .NET 類型，從而在特定方案中實現(xiàn)高效處理。例如，對于要編寫高性能微服務(wù)和處理大量文本的網(wǎng)站的開發(fā)人員，如果在使用 UTF-8 時無需編碼和解碼字符串，則性能會大大提升。為此，我們即將添加 System.Buffers.Text.Base64、System.Buffers.Text.Utf8Parser 和 System.Buffers.Text.Utf8Formatter 等新類型。這些類型對字節(jié) Span 執(zhí)行操作，不僅避免了 Unicode 編碼和解碼，還能夠處理在各種網(wǎng)絡(luò)堆棧的最低級別中常見的本機緩沖：

ReadOnlySpan<byte> utf8Text = ...;if (!Utf8Parser.TryParse(utf8Text, out Guid value,out int bytesConsumed, standardFormat = 'P'))throw new InvalidDataException();

所有此類功能不僅僅只用于公共使用用途；框架本身也可以利用這些基于 Span<T> 和基于 Memory<T> 的新方法來提升性能。跨 .NET Core 調(diào)用網(wǎng)站已切換為使用新的 ReadAsync 重載，以避免不必要的分配操作。分析過去是通過分配子字符串完成，現(xiàn)在可以避免執(zhí)行分配操作。甚至 Rfc2898DeriveBytes 等間隙類型也實際運用了此功能，利用 System.Security.Cryptography.Hash-Algorithm 上基于 Span<byte> 的新 TryComputeHash 方法顯著減少分配操作量（每次算法迭代的字節(jié)數(shù)組，可能迭代數(shù)千次）和提升吞吐量。

這并未止步于核心 .NET 庫一級，而是繼續(xù)全面影響堆棧。ASP.NET Core 現(xiàn)在嚴重依賴 Span；例如，在 Span 基礎(chǔ)之上編寫 Kestrel 服務(wù)器的 HTTP 分析程序。Span 今后可能會通過較低級別 ASP.NET Core 中的公共 API 公開，如在它的中間件管道中。

.NET 運行時又如何呢？

.NET 運行時提供安全保障的方法之一是，確保為數(shù)組編制的索引不超出數(shù)組的長度，這種做法稱為“邊界檢查”。例如，以下面這個方法為例：

[MethodImpl(MethodImplOptions.NoInlining)]static int Return4th(int[] data) => data[3];

在我撰寫本文使用的 x64 計算機上，針對此方法生成的程序集如下所示：

sub????? rsp, 40cmp????? dword ptr [rcx+8], 3jbe????? SHORT G_M22714_IG04mov????? eax, dword ptr [rcx+28]add????? rsp, 40ret G_M22714_IG04:call ????CORINFO_HELP_RNGCHKFAILint3

cmp 指令將數(shù)據(jù)數(shù)組的長度與索引 3 進行比較。如果 3 超出范圍（異常拋出），后續(xù) jbe 指令會轉(zhuǎn)到范圍檢查失敗例程。雖然 JIT 需要生成代碼，以確保此類訪問不會超出數(shù)組邊界，但這并不意味著每個數(shù)組訪問都需要進行邊界檢查。以下面的 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] 的訪問不超出數(shù)組邊界，但因為 JIT 能夠通過循環(huán)結(jié)構(gòu)判斷 i 一直在范圍內(nèi)（循環(huán)從頭到尾遍歷每個元素），所以 JIT 可以優(yōu)化為不對數(shù)組進行邊界檢查。因此，針對循環(huán)生成的程序集代碼如下所示：

G_M33811_IG03:movsxd?? r9, edxadd????? eax, dword ptr [rcx+4*r9+16]inc????? edxcmp????? r8d, edxjg?????? SHORT G_M33811_IG03

雖然 cmp 指令仍在循環(huán)中，但只需將 i 值（存儲在 edx 寄存器中）與數(shù)組長度（存儲在 r8d 寄存器中）進行比較，無需額外進行邊界檢查。

運行時向 Span（Span<T> 和 ReadOnlySpan<T>）應(yīng)用類似優(yōu)化。將上面的示例與下面的代碼進行比較，唯一的變化是參數(shù)類型：

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, r8dadd????? ecx, dword ptr [rax+4*r9]inc????? r8dcmp????? r8d, edxjl?????? SHORT G_M33812_IG03

程序集代碼如此相似，部分是因為不用進行邊界檢查。此外，同樣重要的是 JIT 將 Span 索引器識別為內(nèi)部類型，即 JIT 為索引器生成特殊代碼，而不是將它的實際 IL 代碼轉(zhuǎn)換為程序集。

所有這些都是為了說明運行時可以為 Span 應(yīng)用與數(shù)組相同的優(yōu)化類型，讓 Span 成為高效的數(shù)據(jù)訪問機制。如需了解更多詳情，請參閱?bit.ly/2zywvyI?上的博客文章。

C# 語言和編譯器又如何呢？

我已暗示，添加到 C# 語言和編譯器的功能有助于讓 Span<T> 成為 .NET 中的一流成員。C# 7.2 的多項功能都與 Span 相關(guān)（實際上，C# 7.2 編譯器必須使用 Span<T>）。接下來，將介紹三個此類功能。

引用結(jié)構(gòu)。如前所述，Span<T> 是類似引用的類型，自版本 7.2 起在 C# 中公開為引用結(jié)構(gòu)。通過將引用關(guān)鍵字置于結(jié)構(gòu)前，可以指示 C# 編譯器將其他引用結(jié)構(gòu)類型（如 Span<T>）用作字段，這樣做還會注冊要分配給類型的相關(guān)約束。例如，若要為 Span<T> 編寫結(jié)構(gòu)枚舉器，枚舉器需要存儲 Span<T>，因此它本身必須是引用結(jié)構(gòu)，如下所示：

public ref struct Enumerator {private readonly Span<char> _span;private int _index;... }

Span 的 stackalloc 初始化。在舊版 C# 中，只能將 stackalloc 的結(jié)果存儲到指針本地變量中。自 C# 7.2 起，現(xiàn)在可以在表達式中使用 stackalloc，并能定目標到 Span，而不使用不安全關(guān)鍵字。因為，無需編寫：

Span<byte> bytes;unsafe{byte* tmp = stackalloc byte[length];bytes = new Span<byte>(tmp, length); }

只需編寫：

Span<byte> bytes = stackalloc byte[length];

如果需要一些空間來執(zhí)行操作，但又希望避免分配相對較小的堆內(nèi)存，此代碼就非常有用。過去有以下兩種選擇：

• 編寫兩個完全不同的代碼路徑，對基于堆棧的內(nèi)存和基于堆的內(nèi)存執(zhí)行分配和操作。

• 固定與托管分配相關(guān)聯(lián)的內(nèi)存，再委托到實現(xiàn)，實現(xiàn)也用于基于堆棧的內(nèi)存，并通過不安全代碼中的指針控制進行編寫。

現(xiàn)在，不使用代碼復(fù)制，即可完成相同的操作，而且還可以使用安全代碼和最簡單的操作：

Span<byte> bytes = length <= 128 ? stackalloc byte[length] : new byte[length]; ... // Code that operates on the Span<byte>

Span 使用驗證。因為 Span 可以引用可能與給定堆棧幀相關(guān)聯(lián)的數(shù)據(jù)，所以傳遞 Span 可能存在危險，此操作可能會引用不再有效的內(nèi)存。例如，假設(shè)方法嘗試執(zhí)行以下操作：

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# 編譯器使用引用結(jié)構(gòu)檢測此類無效使用，并會停止編譯，同時顯示以下錯誤：

錯誤 CS8352:無法在此上下文中使用本地“字符”，因為它可能會在聲明范圍外公開引用的變量

接下來會怎樣呢？

本文介紹的類型、方法、運行時優(yōu)化和其他元素即將順利添加到 .NET Core 2.1 中。之后，我預(yù)計它們會全面影響 .NET Framework。核心類型（如 Span<T>）和新類型（如 Utf8Parser）也即將順利添加到與 .NET Standard 1.1 兼容的 System.Memory.dll 包中。這樣一來，相關(guān)功能將適用于現(xiàn)有 .NET Framework 和 .NET Core 版本，盡管在內(nèi)置于平臺時沒有實現(xiàn)一些優(yōu)化。現(xiàn)在，可以試用此包的預(yù)覽版，只需添加對 NuGet 上 System.Memory.dll 包的引用即可。

當然，請注意，當前預(yù)覽版與實際發(fā)布的穩(wěn)定版之間可能會有重大變革。此類變革很大程度上源于像你這樣的開發(fā)人員在試用功能集時提供的反饋。因此，請試用預(yù)覽版，并關(guān)注?github.com/dotnet/coreclr?和?github.com/dotnet/corefx?存儲庫，以掌握最新動態(tài)。此外，有關(guān)文檔，還可以訪問?aka.ms/ref72。

總的來說，此功能集能否取得成功依賴開發(fā)人員試用預(yù)覽版、提供反饋以及利用這些類型生成自己的庫，所有這些都是為了能夠在新式 .NET 程序中高效安全地訪問內(nèi)存。我們熱切期待聆聽大家的使用體驗反饋，最好能夠與大家一起在 GitHub 上進一步改進 .NET。

原文：https://msdn.microsoft.com/zh-cn/magazine/mt814808

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的C# - Span 全面介绍：探索 .NET 新增的重要组成部分的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。