通俗易懂，C#如何安全、高效地玩转任何种类的内存之Span

前言

作为.net程序员，使用过指针，写过不安全代码吗？

为什么要使用指针，什么时候需要使用它？

如果能很好地回答这两个问题，那么就能很好地理解今天了主题了。C#构建了一个托管世界，在这个世界里，只要不写不安全代码，不操作指针，那么就能获得.Net至关重要的安全保障，即什么都不用担心；那如果我们需要操作的数据不在托管内存中，而是来自于非托管内存，比如位于本机内存或者堆栈上，该如何编写代码支持来自任意区域的内存呢？这个时候就需要写不安全代码，使用指针了；而如何安全、高效地操作任何类型的内存，一直都是C#的痛点，今天我们就来谈谈这个话题，讲清楚 What、How 和 Why ，让你知其然，更知其所以然，以后有人问你这个问题，就让他看这篇文章吧，呵呵。

what - 痛点是什么？

回答这个问题前，先总结一下如何用C#操作任何类型的内存：

托管内存（managed memory ）
```
var mangedMemory = new Student();
```
很熟悉吧，只需使用new操作符就分配了一块托管堆内存，而且还不用手工释放它，因为它是由垃圾收集器（GC）管理的，GC会智能地决定何时释放它，这就是所谓的托管内存。默认情况下，GC通过复制内存的方式分代管理小对象（size < 85000 bytes），而专门为大对象（size >= 85000 bytes）开辟大对象堆（LOH），管理大对象时，并不会复制它，而是将其放入一个列表，提供较慢的分配和释放，而且很容易产生内存碎片。
栈内存（stack memory ）
```
unsafe{
    var stackMemory = stackalloc byte[100];
}
```
很简单，使用stackalloc关键字非常快速地就分配好了一块栈内存，也不用手工释放，它会随着当前作用域而释放，比如方法执行结束时，就自动释放了。栈内存的容量非常小（ ARM、x86 和 x64 计算机，默认堆栈大小为 1 MB），当你使用栈内存的容量大于1M时，就会报StackOverflowException 异常，这通常是致命的，不能被处理，而且会立即干掉整个应用程序，所以栈内存一般用于需要小内存，但是又不得不快速执行的大量短操作，比如微软使用栈内存来快速地记录ETW事件日志。
本机内存（native memory ）
```
IntPtr nativeMemory0 = default(IntPtr), nativeMemory1 = default(IntPtr);
try
{
    unsafe
    {
        nativeMemory0 = Marshal.AllocHGlobal(256);
        nativeMemory1 = Marshal.AllocCoTaskMem(256);
    }
}
finally
{
    Marshal.FreeHGlobal(nativeMemory0);
    Marshal.FreeCoTaskMem(nativeMemory1);
}
```
通过调用方法Marshal.AllocHGlobal或Marshal.AllocCoTaskMem来分配非托管堆内存，非托管就是垃圾回收器（GC）不可见的意思，并且还需要手工调用方法Marshal.FreeHGlobal or Marshal.FreeCoTaskMem 释放它，千万不能忘记，不然就产生内存碎片了。

抛砖引玉 - 痛点

首先我们设计一个解析完整或部分字符串为整数的API，如下：

public interface IntParser
{
    // allows us to parse the whole string.
    int Parse(string managedMemory);

    // allows us to parse part of the string.
    int Parse(string managedMemory, int startIndex, int length);

    // allows us to parse characters stored on the unmanaged heap / stack.
    unsafe int Parse(char* pointerToUnmanagedMemory, int length);

    // allows us to parse part of the characters stored on the unmanaged heap / stack.
    unsafe int Parse(char* pointerToUnmanagedMemory, int startIndex, int length); 
}

从上面可以看到，为了支持解析来自任何内存区域的字符串，一共写了4个重载方法。

接下来在来设计一个支持复制任何内存块的API，如下：

public interface MemoryblockCopier
{
    void Copy<T>(T[] source, T[] destination);
    void Copy<T>(T[] source, int sourceStartIndex, T[] destination, int destinationStartIndex, int elementsCount);
    unsafe void Copy<T>(void* source, void* destination, int elementsCount);
    unsafe void Copy<T>(void* source, int sourceStartIndex, void* destination, int destinationStartIndex, int elementsCount);
    unsafe void Copy<T>(void* source, int sourceLength, T[] destination);
    unsafe void Copy<T>(void* source, int sourceStartIndex, T[] destination, int destinationStartIndex, int elementsCount);
}

脑袋蒙圈没，以前C#操纵各种内存就是这么复杂、麻烦。通过上面的总结如何用C#操作任何类型的内存，相信大多数同学都能够很好地理解这两个类的设计，但我心里是没底的，因为使用了不安全代码和指针，这些操作是危险的、不可控的，根本无法获得.net至关重要的安全保障，并且可能还会有难以预估的问题，比如堆栈溢出、内存碎片、栈撕裂等等，微软的工程师们早就意识到了这个痛点，所以span诞生了，它就是这个痛点的解决方案。

how - span如何解决这个痛点？

先来看看，如何使用span操作各种类型的内存（伪代码）：

托管内存（managed memory ）

var managedMemory = new byte[100];
Span<byte> span = managedMemory;

栈内存（stack memory ）

var stackedMemory = stackalloc byte[100];
var span = new Span<byte>(stackedMemory, 100);

本机内存（native memory ）

var nativeMemory = Marshal.AllocHGlobal(100);
var nativeSpan = new Span<byte>(nativeMemory.ToPointer(), 100);

span就像黑洞一样，能够吸收来自于内存任意区域的数据，实际上，现在，在.Net的世界里，Span就是所有类型内存的抽象化身，表示一段连续的内存，它的API设计和性能就像数组一样，所以我们完全可以像使用数组一样地操作各种内存，真的是太方便了。

现在重构上面的两个设计，如下：

public interface IntParser
{
    int Parse(Span<char> managedMemory);
    int Parse(Span<char>, int startIndex, int length);
}
public interface MemoryblockCopier
{
    void Copy<T>(Span<T> source, Span<T> destination); 
    void Copy<T>(Span<T> source, int sourceStartIndex, Span<T> destination, int destinationStartIndex, int elementsCount);
}

上面的方法根本不关心它操作的是哪种类型的内存，我们可以自由地从托管内存切换到本机代码，再切换到堆栈上，真正的享受玩转内存的乐趣。

why - 为什么span能解决这个痛点？

浅析span的工作机制

先来窥视一下源码：

我已经圈出的三个字段：偏移量、索引、长度（使用过ArraySegment<byte> 的同学可能已经大致理解到设计的精髓了），这就是它的主要设计，当我们访问span表示的整体或部分内存时，内部的索引器会按照下面的算法运算指针（伪代码）：

ref T this[int index]
{
    get => ref ((ref reference + byteOffset) + index * sizeOf(T));
}

整个变化的过程，如图所示：

上面的动画非常清楚了吧，旧span整合它的引用和偏移成新的span的引用，整个过程并没有复制内存，而是直接返回引用，因此性能非常高，因为新span获得并更新了引用，所以垃圾回收器（GC）知道如何处理新的span，从而获得了.Net至关重要的安全保障，而这些都是span内部默默完成的，开发人员根本不用担心，非托管世界依然美好。
正是由于span的高性能，目前很多基础设施都开始支持span，甚至使用span进行重构，比如：System.String.Substring方法，我们都知道此方法是非常消耗性能的，首先会创建一个新的字符串，然后在复制原始字符串的字符集给它，而使用span可以实现Non-Allocating、Zero-coping，下面是我做的一个基准测试：

使用String.SubString和Span.Slice分别截取长度为10和1000的字符串的前一半，从指标Mean可以看出方法SubString的耗时随着字符串长度呈线性增长，而Slice几乎保持不变；从指标Allocated Memory/Op可以看出，方法Slice并没有被分配新的内存，实践出真知，可以预见Span未来将会成为.Net下编写高性能应用程序的重要积木，应用前景也会非常地广，微服务、物联网都是它发光发热的好地方。

基准测试示例

----------------------------------------------------------------------------------------------------------------------------------------------------

.Net Core中使用ref和Span<T>提高程序性能的简单实现代码,需要的朋友可以参考下

一、前言

其实说到ref，很多同学对它已经有所了解，ref是C# 7.0的一个语言特性，它为开发人员提供了返回本地变量引用和值引用的机制。
Span也是建立在ref语法基础上的一个复杂的数据类型，在文章的后半部分，我会有一个例子说明如何使用它。

二、ref关键字

不论是ref还是out关键，都是一种比较难以理解和操作的语言特性，如C语言中操作指针一样，这样的高级语法总是什么带来一些副作用，但是我不认为这有什么，而且不是每一个C#开发者都要对这些内部运行的机制有着深刻的理解，我觉得不论什么复杂的东西只是为人们提供了一个自由的选择，风险和灵活性永远是不能兼容的。

来看几个例子来说明引用与指针的相同性，当然下面的使用方式早在C# 7.0之前就可以使用了：

public static void IncrementByRef(ref int x)
{
 x++;
}

public unsafe static void IncrementByPointer(int* x)
{
 (*x)++;
}

上面两个函数分别是使用ref和非安全指针来完成参数+1。

int i = 30;
IncrementByRef(ref i);
// i = 31
unsafe{
 IncrementByPointer(&i);
}
// i = 32

下面是C# 7.0提供的特性：

1.ref locals (引用本地变量)

int i = 42;
ref var x = ref i;
x = x + 1;
// i = 43

这个例子中为本地 i 变量的引用 x, 当改变x的值时i变量的值也改变了。

2.ref returns (返回值引用)

ref returns是C# 7中一个强大的特性，下面代码是最能体现其特性的，该函数提供了，返回int数组中某一项的引用：

public static ref int GetArrayRef(int[] items, int index) => ref items[index];

三、Span通过下标取得数组中的项目的引用，改变引用值时，数组也会随之改变。

System.Span是.Net Core核心的一部分，在System.Memory.dll 程序集下。目前该特性是独立的，将来可能会集成到CoreFx中；

如何使用呢？在.Net Core 2.0 SDK创建的项目下引用如下NuGet包：

<ItemGroup>
<PackageReference Include="System.Memory" Version="4.4.0-preview1-25305-02" />
<PackageReference Include="System.Runtime.CompilerServices.Unsafe" Version="4.4.0-preview1-25305-02" />
</ItemGroup>

Span表示为一个已知长度和类型的连续内存块。许多方面讲它非常类似T[]或ArraySegment，它提供安全的访问内存区域指针的能力。其实我理解它更将是.NET中操作(void*)指针的抽象,熟悉C/C++开发者应该更明白这意味着什么。在上面我们看到了使用ref关键字可以提供的类似指针(T*)的操作单一值对象方式。基本上在.NET体系下操作指针都不认为是一件好的事件，当然.NET为我们提供了安全操作单值引用的ref。但是单值只是用户使用“指针”的一小部分需求；对于指针来说，更常见的情况是操作一系列连续的内存空间中的“元素”时。

Span的特点如下：

•抽象了所有连续内存空间的类型系统，包括：数组、非托管指针、堆栈指针、fixed或pinned过的托管数据，以及值内部区域的引用
•支持CLR标准对象类型和值类型
•支持泛型
•支持GC,而不像指针需要自己来管理释放

下面来看下Span的定义，它与ref有着语法和语义上的联系：

public struct Span<T> {
 ref T _reference;
 int _length;
 public ref T this[int index] { get {...} }
 ...
}

public struct ReadOnlySpan<T> {
 ref T _reference;
 int _length;
 public T this[int index] { get {...} }
 ...
}

接下来我会用一个直观的例子来说明Span的使用场景；我们以字符截取和字符转换（转换为整型）为例：

如有一个字符串string content = "content-length:123",要转换将123转换为整型，通常的做法是先Substring将与数字字符无关的字符串进行截断，转换代码如下：

string content = "content-length:123";
Stopwatch watch1 = new Stopwatch();
watch1.Start();
for (int j = 0; j < 100000; j++)
{
 int.Parse(content.Substring(15));
}
watch1.Stop();
Console.WriteLine("\tTime Elapsed:\t" + watch1.ElapsedMilliseconds.ToString("N0") + "ms");

使用Span实现这个算法：为什么使用这个例子呢，这是一个典型的substring的使用场景，每次操作string都会生成新的string对象,当然不光是Substring,在进行int.Parse时重复操作string对象，如果大量操作就会给GC造成压力。

string content = "content-length:123";
ReadOnlySpan<char> span = content.ToCharArray(); 
span.Slice(15).ParseToInt();
watch.Start();
for (int j = 0; j < 100000; j++)
{
 int icb = span.Slice(15).ParseToInt();
}
watch.Stop();
Console.WriteLine("\tTime Elapsed:\t" + watch.ElapsedMilliseconds.ToString("N0") + "ms");

转换代码如下：这里将string转换为int的算法利用ReadonlySpan实现，这也是Span的典型使用场景，官方给的场景也是如些，Span适用于多次复用操作连续内存的场景。

public static class ReadonlySpanxtension
{
 public static int ParseToInt(this ReadOnlySpan<char> rspan)
 {
  Int16 sign = 1;
  int num = 0;
  UInt16 index = 0;
  if (rspan[0].Equals('-')){
   sign = -1; index = 1;
  }
  for (int idx = index; idx < rspan.Length; idx++){
   char c = rspan[idx];
   num = (c - '0') + num * 10;
  }
  return num * sign;
 }
}

四、最后

上述两段代码100000次调用的时间如下：

String Substring Convert:
  Time Elapsed: 18ms
ReadOnlySpan Convert:
  Time Elapsed: 4ms

目前Span的相关支持还够，它只是最基础架构，之后CoreFx会对很多API使用Span进行重构和实现。可见.Net Core的性能日后会越来越强大。