.NET高性能编程 - C#如何安全、高效地玩转任何种类的内存之Memory(三)

时间 2019-11-15

标签高性能编程 c# 如何安全高效转任种类内存 memory 栏目 C# 繁體版

原文原文链接

前言

咱们都知道，.Net Core是微软推出的一个通用开发平台，它是跨平台和开源的，由一个.NET运行时、一组可重用的框架库、一组SDK工具和语言编译器组成，旨在让.Net developers能够更容易地编写高性能的服务应用程序和基于云的可伸缩服务，好比微服务、物联网、云原生等等；在这些场景下，对于内存的消耗每每十分敏感，也十分苛刻；为了解决这个棘手问题，同时释放应用开发人员的精力，让他们可以安心地使用Net Core，而不用担忧这些应用场景下的性能问题，故从.NET Core 2.1开始引进了两个新的旗舰类型：Span<T> 、Memory<T> ，使用它们能够避免分配缓冲区和没必要要的数据复制。html

前面已经对span作了详细地讲解，因此今天主题是Memory，一样以Why、What和How的方式缓缓道来，让你知其然，更知其因此然。git

Memory<T>是Span的补充，它是为了解决Span没法驻留到堆上而诞生的，能够说Span是Memory的奠定，故在读这篇文章前，请先仔细品读前面两篇文章：github

如今，做者就当你已经阅读了前面的博客，并明白了Span的本质（ref-like type）和秉性特色（stack-only）。web

why - 为何须要memory ?

span的局限性

span只能存储到执行栈上，保障操做效率与数组同样高，并提供稳定的生命周期。
span不能被装箱到堆上，避免栈撕裂问题。
span不能用做泛型类型参数。
Span不能做为类的字段。
Span不能实现任何接口。
Span不能用于异步方法，由于没法跨越await边界，全部没法跨异步操做暂留。

下面来看一个例子：编程

async Task DoSomethingAsync(Span<byte> buffer) {// 这里编译器会提示报错，做为例子而已，请忽略。
    buffer[0] = 0;
    await Something(); // 异步方法会释放当前执行栈，那么Span也被回收了。
    buffer[0] = 1; // 这里buffer将没法继续。
}

备注：C#编译器和core运行时内部会强制验证Span的局限性，因此上面例子才会编译不过。c#

正是由于这些局限性，确保了更高效、安全的内存访问。windows

也是由于这些局限性，没法用于须要将引用数据存储到堆上的一些高级应用场景，好比：异步方法、类字段、泛型参数、集合成员、lambda表达式、迭代器等。api

仍是由于这些局限性，增长了span对于高层开发人员的复杂性。数组

因此Memory<T>诞生了，做为span的补充，它就是目前的解决方案，没有之一，也是高层开发人员往后使用最广泛的类型。安全

what - memory是什么 ?

和Span<T>同样，也是sliceable type，但它不是ref-like type，就是普通的C#结构体。这意味着，能够将它装箱到堆上、做为类的字段或异步方法的参数、保存到集合等等，对于高层开发人员很是友好，嘿嘿，而且当须要处理Memory底层缓冲区，即作同步处理时，直接调用它的Span属性，同时又得到了高效的索引能力。

备注：Memory<T>表示一段可读写的连续内存区域，ReadOnlyMemory表示一段只读的连续内存区域。

static async Task<uint> ChecksumReadAsync(Memory<byte> buffer, Stream stream)
{
    var bytesRead = await stream.ReadAsync(buffer);
    // 须要同步处理时，直接调用span属性。
    return SafeSum(buffer.Span.Slice(0, bytesRead));
    // 千万不要这样写，除非你想要先持久化分片数据到托管堆上，但这又没法使用Span<T>实现；其次Memory <T>是一个比Span<T>更大的结构体，切片每每相对较慢。
    //return SafeSum(buffer.Slice(0,bytesRead).Span());
}
static uint SafeSum(Span<byte> buffer)
{
    uint sum = 0;
    foreach (var t in buffer)
    {
        sum += t;
    }
    return sum;
}

Memory核心设计

public readonly struct Memory<T>
{
    private readonly object _object; //表示Memory能包裹的对象，EveryThing。
    private readonly int _index;
    private readonly int _length; 
    public Span<T> Span { get; } // 实际的内部缓冲区
}

如前所述，Memory的目的是为了解决Span没法驻留到堆上的问题，也就是Memory表明的内存块并不会随方法执行栈的unwind而回收，也就是说它的内部缓冲区是有生命周期的，并非短暂的，这就是为何字段_object的类型被设计成object，而不是类型化为T[]，就是为了经过传递IMemoryOwner来管理Span的生命周期，从而避免UAF（use-after-free）bug。

private static MemoryPool<byte> _memPool = MemoryPool<byte>.Shared;

public async Task UsageWithLifeAsync(int size)
{
    using (var owner = _memPool.Rent(size)) // 从池里租借一块IMemoryOwner包裹的内存。
    {
        await DoSomethingAsync(owner.Memory); // 把实际的内存借给异步方法使用。
    } // 做用域结束，存储的Memory<T>被回收，这里是返还给内存池，有借有还，再借不难，嘿嘿。
}
// 不用担忧span会随着方法执行栈unwind而回收
async Task DoSomethingAsync(Memory<byte> buffer) {
    buffer.Span[0] = 0; // 没问题
    await Something(); // 跨越await边界。
    buffer.Span[0] = 1; // 没问题
}

IMemoryOwner，顾名思义，Memory<T>拥有者，经过属性Memory来表示，以下：

public interface IMemoryOwner<T> : IDisposable
{
    Memory<T> Memory { get; }
}

因此，可使用IMemoryOwner来转移Memory<T>内部缓冲区的全部权，从而让开发人员没必要管理缓冲区。

关于如何优雅地管理Memory<T>内部缓冲区的生命周期，在设计时工程师们考虑过好几种方案，好比：联合标识、自动引用计数(ARC)等，但最后仍是选择上面这种方案，即经过实现IMemoryOwner间接地从新得到Memory<T>内部缓冲区的控制权，其实每次都是建立一个新的Span，因此能够将Memory<T>视为Span<T>的工厂。

How - 如何运用memory ?

如前所述， Memory<T>其实就是Span<T>的heap-able类型，故它的API和span基本相同，以下：

public Memory(T[] array);
public Memory(T[] array, int start, int length);
public Memory<T> Slice(int start);// 支持sliceable
public bool TryCopyTo(Memory<T> destination);

不一样的是Memory<T>有两个独一无二的API，以下：

public MemoryHandle Pin(); // 钉住_object的内存地址，即告知垃圾回收器不要回收它，咱们本身管理内存。
public System.Span<T> Span { get; }// 当_object字段为数组时，提供快速索引的能力。

和Span<T>同样，一般Memory<T>都是包裹数组、字符串，用法也基本相同，只是应用场景不同而已。

Memory<T>的使用指南：

同步方法应该接受Span 参数，异步方法应该接受Memory 参数。
以Memory<T>做为参数无返回值的同步方法，方法结束后，不该该再使用它。
以Memory<T>做为参数返回Task的异步方法，方法结束后，不该该再使用它。
同一Memory<T>实例不能同时被多个消费者使用。

因此啊，千万不要将好东西用错地方了，聪明反被聪明误，最后，弄巧成拙，嘿嘿。

总结

综上所述，和Span<T>同样，Memory<T>也是Sliceable type，它是Span没法驻留到堆上的解决方案。通常Span<T>由底层开发人员用在数据同步处理和转换方面，而高层开发人员使用Memory<T>比较多，由于它能够用于一些高级的场景，好比：异步方法、类字段、lambda表达式、泛型参数等等。二者的完美运用就可以支持无复制流动数据，这就是数据管道应用场景(System.IO.Pipelines)。

到目前为止，做者花了三篇博客终于把这两个旗舰类型讲完了，相信认真品读这三篇博客的同窗，必定会受益不浅。后面的系列将讲二者的高级应用场景，好比数据管道(Data Pipelines )、不连续缓冲区(Discontiguous Buffers)、缓冲池(Buffer Pooling)、以及为何让Aspnet Core Web Server变得如此高性能等。
一图胜千言，最新一期techempower web框架基准测试：

最后

若是有什么疑问和看法，欢迎评论区交流。
若是你以为本篇文章对您有帮助的话，感谢您的【推荐】。
若是你对.NET高性能编程感兴趣的话能够【关注我】，我会按期的在博客分享个人学习心得。
欢迎转载，请在明显位置给出出处及连接。

延伸阅读

https://en.wikipedia.org/wiki/Reference_counting

https://msdn.microsoft.com/en-us/magazine/mt814808

https://blogs.msdn.microsoft.com/oldnewthing/20040406-00/?p=39903

https://github.com/dotnet/corefxlab/blob/master/docs/specs/memory.md

https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing-net-core-2-1

https://docs.microsoft.com/zh-cn/dotnet/api/system.memory-1?view=netcore-2.2

https://frameworkbenchmarks.readthedocs.io/en/latest/Project-Information/Framework-Tests

https://blogs.msdn.microsoft.com/dotnet/2018/07/09/system-io-pipelines-high-performance-io-in-net

https://www.codemag.com/Article/1807051/Introducing-.NET-Core-2.1-Flagship-Types-Span-T-and-Memory-T

https://docs.microsoft.com/en-us/previous-versions/windows/silverlight/dotnet-windows-silverlight/khk3k17t(v=vs.95)

https://blogs.msdn.microsoft.com/mazhou/2018/03/25/c-7-series-part-10-spant-and-universal-memory-management