前言
我们都知道,.Net Core是微软推出的一个通用开发平台,它是跨平台和开源的,由一个.NET运行时、一组可重用的框架库、一组SDK工具和语言编译器组成,旨在让.Net developers可以更容易地编写高性能的服务应用程序和基于云的可伸缩服务,比如微服务、物联网、云原生等等;在这些场景下,对于内存的消耗往往十分敏感,也十分苛刻;为了解决这个棘手问题,同时释放应用开发人员的精力,让他们能够安心地使用Net Core,而不用担心这些应用场景下的性能问题,故从.NET Core 2.1开始引进了两个新的旗舰类型:Span<T>
、Memory<T>
,使用它们可以避免分配缓冲区和不必要的数据复制。
前面已经对span做了详细地讲解,所以今天主题是Memory,同样以Why、What和How的方式缓缓道来 ,让你知其然,更知其所以然。
Memory<T>
是Span的补充,它是为了解决Span无法驻留到堆上而诞生的,可以说Span是Memory的奠基,故在读这篇文章前,请先仔细品读前面两篇文章:
现在,作者就当你已经阅读了前面的博客,并明白了Span的本质(ref-like type)和秉性特点(stack-only)。
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的局限性,所以上面例子才会编译不过。
正是因为这些局限性,确保了更高效、安全的内存访问。
也是因为这些局限性,无法用于需要将引用数据存储到堆上的一些高级应用场景,比如:异步方法、类字段、泛型参数、集合成员、lambda表达式、迭代器等。
还是因为这些局限性,增加了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