高性能 on 纪伟的个人博客

深入 .NET Stream：从 byte[] 拉取到 Pipelines 推回，一次抽象的演进史

Mon, 15 Jun 2026 09:00:00 +0800

Stream 是 .NET 里"最古老又最常用"的抽象之一——从 1.0 时代就在那儿，每一版 .NET 都在给它打补丁：Read(byte[]) → ReadAsync(byte[]) → Read(Span<byte>) → ReadAsync(Memory<byte>) → ReadByte → PipeReader。如果它真的设计好了，根本不需要这么多补丁。

把 Stream 的所有坑摊开看，背后其实就是同一个设计张力的不同投影：

Stream 试图用"统一抽象"覆盖所有 IO（文件、网络、内存、加密、压缩），但同一个抽象对"高性能网络"和"简单文件读写"是天然矛盾的——前者要零拷贝、背压、内存池，后者只要简单 API。

理解了这层张力，就能看清 .NET 流式 API 二十年的演进：每一层补丁（Span、Memory、ValueTask、Pipelines）都是在重新回答"统一抽象到底要做到什么程度"。本文围绕这条主线把 Stream 从底层机制到选型陷阱彻底讲透。

一、Stream 是什么：抽象基类的雄心与代价

1.1 统一 IO 抽象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


public abstract class Stream : MarshalByRefObject, IAsyncDisposable, IDisposable
{
 public abstract bool CanRead { get; }
 public abstract bool CanWrite { get; }
 public abstract bool CanSeek { get; }
 public abstract long Length { get; }
 public abstract long Position { get; set; }

 public abstract int Read(byte[] buffer, int offset, int count);
 public abstract void Write(byte[] buffer, int offset, int count);
 public abstract long Seek(long offset, SeekOrigin origin);
 public abstract void SetLength(long value);
 public abstract void Flush();
}

1
2
3
4
5
6
7
8
9


设计意图：
 让"读文件 / 读网络 / 读内存 / 读加密"用同一套 API
 → 业务代码只依赖 Stream，不依赖具体实现
 → 可以层层包装（装饰器模式）

代价：
 → 抽象被迫提供所有方法，但每个子类都不一定能实现
 → CanRead / CanWrite / CanSeek 标志位遍布 API
 → 不支持的操作直接抛 NotSupportedException

1.2 四维能力（实际只有三维常用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


能力 属性 典型实现
─────────────────────────────────────────────────
Read CanRead FileStream / NetworkStream / MemoryStream
Write CanWrite FileStream / NetworkStream / MemoryStream
Seek CanSeek FileStream ✅ / NetworkStream ❌ / MemoryStream ✅
Timeout CanTimeout NetworkStream ✅ / FileStream ❌

CanSeek = false 时：
 - Position / Length / SetLength / Seek 都抛 NotSupportedException
 - Position 是"游标"概念，对网络流没意义

CanTimeout = true 时：
 - ReadTimeout / WriteTimeout 控制读写超时（毫秒）
 - 实际效果因实现而异（FileStream 在 Windows 上有 native 重叠 IO）

1.3 一个 Stream 可以"什么都不支持"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


public class NullStream : Stream // 实际叫 Stream.Null
{
 public override bool CanRead => true;
 public override bool CanWrite => true;
 public override bool CanSeek => true;
 public override long Length => 0;
 public override long Position { get; set; }

 public override int Read(byte[] buf, int off, int count) => 0; // EOF
 public override void Write(byte[] buf, int off, int count) { /* 丢弃 */ }
 public override long Seek(long off, SeekOrigin org) => off;
 public override void Flush() { }
 public override void SetLength(long v) { }
}

Stream.Null 是"黑洞"——读立刻 EOF，写什么都不存。这种"无所不接"的抽象，让 Stream 可以做单元测试替身。

二、最坑的"暗契约"：Read 不保证读满

这是新手最容易踩的雷，也是 Stream 抽象的"原罪"。

2.1 反模式：以为一次 Read 能读满

1
2
3
4
5
6
7


// ❌ 高风险写法
public async Task<byte[]> ReadNAsync(Stream s, int n)
{
 byte[] buf = new byte[n];
 int read = await s.ReadAsync(buf, 0, n); // ⚠️ read 可能 < n
 return buf; // ⚠️ 后半段可能是 0
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


为什么 Read 可能返回少于请求？
 - FileStream：通常能读满（除非到 EOF）
 - NetworkStream：可能 1 字节就返回！
 * TCP 是字节流，每次 Read 看到的是"当前缓冲区到达的数据"
 * 没有"凑够 N 字节"的概念
 * 如果对方写 4 字节后 sleep，下次 Read 就只有 4 字节

 - CryptoStream：可能解一帧就返回
 - GZipStream：可能解一 chunk 就返回

→ 契约：Read 返回"实际读到的字节数"，可能是 0（EOF）到 count

2.2 正确做法：循环到 N 或 EOF

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


public static async Task<int> ReadExactAsync(Stream s, byte[] buf, int offset, int count)
{
 int total = 0;
 while (total < count)
 {
 int read = await s.ReadAsync(buf, offset + total, count - total);
 if (read == 0) break; // EOF
 total += read;
 }
 return total;
}

// .NET 6+ 已经原生提供：
await s.ReadExactlyAsync(buf); // 读满，否则抛 EndOfStreamException
await s.ReadAtLeastAsync(buf, 100); // 至少 100 字节

1
2
3
4
5
6
7


ReadExactly 的实现：
 .NET 6 引入的"长痛不如短痛"API
 替代手写循环（手写循环是 .NET 头号反模式之一）

注意：ReadExactly 在网络流上"卡住"直到读满或 EOF
 → 必须配合 CancellationToken
 → 否则恶意对端可以让调用永久阻塞

2.3 Read 返回 0 的意义

1
2
3
4
5
6
7
8


0 = EOF（流结束）
1~count = 实际读到
异常 = IO 错误

注意：
 - NetworkStream 上对端关连接 → Read 返回 0
 - 永远不会"Read 返回 0 然后又读到数据"
 - 收到 0 后再调 Read 还是 0

三、API 演进史：从 byte[] 到 PipeReader

每一代 .NET 都在补 Stream 的洞。

3.1 第一代：同步 byte[] API（.NET 1.0）

1
2
3


byte[] buf = new byte[1024];
int read = stream.Read(buf, 0, 1024);
stream.Write(buf, 0, read);

1
2
3
4


问题：
 - 同步阻塞 → 高并发下线程爆炸
 - byte[] 必须分配 → GC 压力
 - offset + count 三参数 → 容易越界

3.2 第二代：APM 异步（.NET 1.1+）

1
2


stream.BeginRead(buf, 0, 1024, callback, state);
// 在 callback 里调 EndRead 拿到字节数

1
2
3
4


问题：
 - 回调地狱
 - 状态对象装箱
 - 异常处理复杂

3.3 第三代：TAP 异步（.NET 4.5）

1

int read = await stream.ReadAsync(buf, 0, 1024);

1
2
3


问题：
 - 仍然 byte[] 分配
 - Task<int> 装箱（每个 await 一个 Task 对象）

3.4 第四代：Span / Memory（.NET Core 2.1+）

1
2
3
4
5
6
7
8
9


// 同步版本
int read = stream.Read(buf.AsSpan(0, 1024));

// 异步版本（基于 ValueTask）
int read = await stream.ReadAsync(buf.AsMemory(0, 1024));

// stackalloc 友好
Span<byte> stackBuf = stackalloc byte[256];
stream.Read(stackBuf);

1
2
3
4
5
6
7
8


改进：
 - Span 零分配
 - ValueTask<int> 避免每次 await 创建 Task
 - 可以用 stackalloc

遗留：
 - 仍然要"主动拉"（pull）
 - 仍然要循环到 N 字节

3.5 第五代：ReadExactly / ReadAtLeast（.NET 6+）

1
2


await stream.ReadExactlyAsync(buf); // 自动循环
await stream.ReadAtLeastAsync(buf, 100, throwOnEndOfStream: false);

3.6 第六代：Pipelines（.NET Core 2.1+，命名空间 System.IO.Pipelines）

1
2
3
4
5
6
7
8
9


PipeReader reader = PipeReader.Create(stream);
ReadResult result = await reader.ReadAsync();
ReadOnlySequence<byte> buffer = result.Buffer;

// 处理 buffer（多段 Memory 拼接）
ProcessProtocol(buffer);

// 告诉 reader "我处理了多少"
reader.AdvanceTo(buffer.Start, buffer.End);

1
2
3
4
5
6
7
8


革命性：
 1. 不用自己分配 buffer（Pipe 内部池化）
 2. 不用循环到 N 字节（Pipe 自动缓冲）
 3. 多段连续内存（ReadOnlySequence<byte>）
 4. 背压（Pipe 满了写不动）
 5. 零拷贝（数据停留在 Pipe 池里）

ASP.NET Core / Kestrel / SignalR 全部用 Pipelines

四、同步 vs 异步：FileStream 的"假异步"陷阱

这是另一个高频坑。

4.1 默认 FileStream 异步是"假的"

1
2
3
4


// 看起来是异步
using var fs = new FileStream("data.bin", FileMode.Open);
byte[] buf = new byte[4096];
int read = await fs.ReadAsync(buf, 0, 4096);

1
2
3
4
5
6
7
8
9


实际行为：
 - 默认构造的 FileStream，ReadAsync 是"假异步"
 - 内部用一个线程池线程做同步 Read
 - 异步调用反而多了线程切换开销

为什么？
 - Windows 文件 IO 默认是同步的
 - 要真正异步需要 FILE_FLAG_OVERLAPPED + 完成端口
 - .NET 默认不开（兼容性、性能权衡）

4.2 真异步：FileOptions.Asynchronous

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// ✅ 真异步
using var fs = new FileStream(
 "data.bin",
 FileMode.Open,
 FileAccess.Read,
 FileShare.Read,
 bufferSize: 4096,
 options: FileOptions.Asynchronous // ← 关键
);

int read = await fs.ReadAsync(buf, 0, 4096);
// 这才是真正的异步（Windows 用 IOCP，Linux 用 io_uring）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


FileOptions.Asynchronous 的效果：
 - Windows：内部用 OVERLAPPED + IOCP
 - Linux：内部用 io_uring（.NET 6+）
 - 不占用线程池线程
 - 大量并发 IO 时差距巨大

FileSteam 静态方法：
 File.OpenRead("...") // 没开 Asynchronous
 File.Open("...", FileMode) // 没开

 → 想要真异步，必须用完整 FileStream 构造

4.3 性能对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


场景：1 个进程同时读 1000 个文件，每文件 1MB

 默认（假异步）：
 1000 个线程池线程阻塞
 CPU 跑满，实际 IO 不快
 → 12 秒

 FileOptions.Asynchronous（真异步）：
 0 个线程池线程阻塞
 IOCP / io_uring 工作
 → 2 秒

→ 6 倍差距，这只是开了个开关

4.4 同步 ReadAsync 反而慢

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 真异步下，单线程顺序读：
await fs.ReadAsync(buf);
await fs.ReadAsync(buf);
await fs.ReadAsync(buf);
// 比同步：
fs.Read(buf);
fs.Read(buf);
fs.Read(buf);
// 慢一点（每次有 IOCP 唤醒开销）

// 但高并发下，真异步完胜

五、装饰器模式：Stream 的灵魂

Stream 是 GoF《设计模式》里 Decorator（装饰器）的教科书案例。

5.1 经典装饰器组合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 三层包装：加密 + 压缩 + 文件
using var fs = new FileStream("data.gz.enc", FileMode.Create);
using var gz = new GZipStream(fs, CompressionMode.Compress);
using var cs = new CryptoStream(gz, aes.CreateEncryptor(), CryptoStreamMode.Write);

byte[] data = Encoding.UTF8.GetBytes("Hello, World!");
cs.Write(data, 0, data.Length);

// 数据流：
// Write → cs 加密 → gz 压缩 → fs 落盘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


图示：
 ┌─────────────────────┐
 │ CryptoStream │
 │ - 加密 │
 └──────────┬──────────┘
 ▼
 ┌─────────────────────┐
 │ GZipStream │
 │ - 压缩 │
 └──────────┬──────────┘
 ▼
 ┌─────────────────────┐
 │ BufferedStream │
 │ - 缓冲 │
 └──────────┬──────────┘
 ▼
 ┌─────────────────────┐
 │ FileStream │
 │ - 落盘 │
 └─────────────────────┘

5.2 装饰器的"自动 dispose 链"

1
2
3
4
5
6
7


using var fs = new FileStream(...);
using var gz = new GZipStream(fs, ...);
// gz.Dispose() 内部会调用 fs.Dispose()
// 所以只 using 外层就够

// 但很多人不知道这点
// 容易在 finally 里手动 dispose 所有层

5.3 装饰器的所有权陷阱

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 假设你有一个"共享底层流"
using var fs = new FileStream(...);

// 包装两个装饰器，都接管 fs
using var cs1 = new CryptoStream(fs, enc1, Write);
using var cs2 = new CryptoStream(fs, enc2, Write);

cs1.Write(...); // 内部调 fs.Write
cs2.Write(...); // 也调 fs.Write！
// 实际写入是混乱的（fs 是有状态的）

// 正确做法：每个底层流只对应一个装饰器链

5.4 BufferedStream：什么时候有用

1
2
3
4
5
6
7
8
9


using var fs = new FileStream(...);
using var bs = new BufferedStream(fs, 8192); // 8KB 缓冲

// 现代 FileStream 默认就有 bufferSize
// NetworkStream 默认 64KB Socket 缓冲
// → BufferedStream 在大多数情况下是冗余的

// 但 CryptoStream / GZipStream 没有 buffer
// → 包在它们外面有用

六、CopyTo / CopyToAsync：被低估的 API

6.1 自实现 vs 内置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// ❌ 手写循环
public async Task CopyAsync(Stream src, Stream dst)
{
 byte[] buf = new byte[8192];
 int read;
 while ((read = await src.ReadAsync(buf, 0, 8192)) > 0)
 await dst.WriteAsync(buf, 0, read);
}

// ✅ 内置（已经做了优化）
await src.CopyToAsync(dst, bufferSize: 8192);

6.2 CopyTo 的实现细节

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 简化版
public virtual async Task CopyToAsync(Stream dest, int bufferSize, CancellationToken ct)
{
 byte[] buffer = ArrayPool<byte>.Shared.Rent(bufferSize);
 try
 {
 int read;
 while ((read = await ReadAsync(buffer, ct)) > 0)
 await dest.WriteAsync(buffer.AsMemory(0, read), ct);
 }
 finally
 {
 ArrayPool<byte>.Shared.Return(buffer);
 }
}

1
2
3
4
5


内置的优势：
 - 用 ArrayPool（零分配）
 - 自适应 bufferSize
 - Stream 重写时有优化路径（如 MemoryStream → MemoryStream 直接拷贝）
 - 取消支持

6.3 FileStream → FileStream 的最优写法

1
2
3
4
5
6
7
8
9


// ❌ 慢
await src.CopyToAsync(dst);

// ✅ 快（用底层 Windows API CopyFile）
if (src is FileStream fs1 && dst is FileStream fs2)
{
 // .NET Core 内部已经针对 FileStream 优化
 // 直接调 Windows CopyFileEx
}

七、Pipelines：Stream 的接班人

7.1 为什么需要 Pipelines

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Stream 抽象的根本问题：
 1. 应用必须分配 buffer（byte[]）
 2. 应用必须循环 Read
 3. 应用必须处理"读不满"的情况
 4. 没有背压（写太快时 Stream 不阻塞）
 5. 单段 buffer（数据可能跨段）

 → 写一个高性能 HTTP 服务器，光是处理"读满 N 字节"就要 100 行代码

Pipelines 重新设计：
 1. Pipe 内部管理 buffer（池化）
 2. Pipe 自动累积数据
 3. 调用方一次拿到"已经够多"的数据
 4. Pipe 满了写不动（背压）
 5. ReadOnlySequence<byte> 支持多段

7.2 PipeReader / PipeWriter

1
2
3
4
5
6
7
8
9


var pipe = new Pipe(new PipeOptions(
 pool: ArrayPool<byte>.Shared,
 readerScheduler: PipeScheduler.ThreadPool,
 writerScheduler: PipeScheduler.ThreadPool,
 pauseWriterThreshold: 1024 * 1024, // 写暂停阈值（背压）
 resumeWriterThreshold: 512 * 1024)); // 写恢复阈值

PipeWriter writer = pipe.Writer;
PipeReader reader = pipe.Reader;

7.3 协议解析示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


// 解析"4 字节长度 + N 字节 body"协议
async Task ProcessAsync(PipeReader reader)
{
 while (true)
 {
 ReadResult result = await reader.ReadAsync();
 ReadOnlySequence<byte> buffer = result.Buffer;

 while (TryReadMessage(ref buffer, out var message))
 {
 ProcessMessage(message);
 }

 // 告诉 reader：消费到哪，下次从哪开始
 reader.AdvanceTo(buffer.Start, buffer.End);

 if (result.IsCompleted) break;
 }
}

bool TryReadMessage(ref ReadOnlySequence<byte> buffer, out ReadOnlySequence<byte> message)
{
 if (buffer.Length < 4) { message = default; return false; }

 Span<byte> lengthBytes = stackalloc byte[4];
 buffer.Slice(0, 4).CopyTo(lengthBytes);
 int length = BitConverter.ToInt32(lengthBytes);

 if (buffer.Length < 4 + length) { message = default; return false; }

 message = buffer.Slice(4, length);
 buffer = buffer.Slice(4 + length);
 return true;
}

1
2
3
4
5


对比 Stream 版本：
 - 没有手动 buffer 分配
 - 没有手动"读满 4 字节"循环
 - 处理"半个消息"自动等下次数据
 - 多段 Sequence 天然支持

7.4 Stream 与 Pipe 的桥接

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 从 Stream 创建 PipeReader
PipeReader reader = PipeReader.Create(stream, new StreamPipeReaderOptions(
 bufferSize: 4096,
 leaveOpen: false));

// 从 Stream 创建 PipeWriter
PipeWriter writer = PipeWriter.Create(stream, new StreamPipeWriterOptions(
 leaveOpen: false));

// 或者反过来：把 Pipe 当 Stream 用
Stream stream = pipe.Writer.AsStream();

1
2
3
4
5


ASP.NET Core 的请求体就是 PipeReader：
 HttpContext.Request.BodyReader : PipeReader
 HttpContext.Response.BodyWriter : PipeWriter

 → 不再是 Stream，而是 Pipeline

八、常见误用清单

8.1 不 Dispose 流

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// ❌ 流泄漏
public byte[] Read(string path)
{
 var fs = new FileStream(path, FileMode.Open);
 var ms = new MemoryStream();
 fs.CopyTo(ms);
 return ms.ToArray(); // fs 和 ms 都没 Dispose
}

// ✅ using
public byte[] Read(string path)
{
 using var fs = new FileStream(path, FileMode.Open);
 using var ms = new MemoryStream();
 fs.CopyTo(ms);
 return ms.ToArray();
}

8.2 异步方法不 await

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// ❌ 火并忘记（fire and forget）
public void BadWrite(Stream s, byte[] data)
{
 s.WriteAsync(data, 0, data.Length); // ⚠️ 没 await
 // 方法立即返回，写还没完成
}

// ✅ await 或显式处理
public async Task WriteAsync(Stream s, byte[] data)
{
 await s.WriteAsync(data);
}

8.3 不开 Asynchronous

1
2
3
4
5
6
7
8


// ❌ 假异步
using var fs = File.OpenRead("data.bin"); // 默认 options
await fs.ReadAsync(buf); // 实际是线程池阻塞

// ✅ 真异步
using var fs = new FileStream("data.bin", FileMode.Open, FileAccess.Read,
 FileShare.Read, 4096, FileOptions.Asynchronous);
await fs.ReadAsync(buf);

8.4 不用 ArrayPool

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


// ❌ 每次 new
public async Task<byte[]> ReadAsync(Stream s)
{
 byte[] buf = new byte[4096]; // ⚠️ GC 压力
 using var ms = new MemoryStream();
 int read;
 while ((read = await s.ReadAsync(buf)) > 0)
 ms.Write(buf, 0, read);
 return ms.ToArray();
}

// ✅ ArrayPool
public async Task<byte[]> ReadAsync(Stream s)
{
 byte[] buf = ArrayPool<byte>.Shared.Rent(4096);
 try
 {
 using var ms = new MemoryStream();
 int read;
 while ((read = await s.ReadAsync(buf.AsMemory(0, 4096))) > 0)
 ms.Write(buf, 0, read);
 return ms.ToArray();
 }
 finally
 {
 ArrayPool<byte>.Shared.Return(buf);
 }
}

// ✅✅ CopyToAsync（最简）
public async Task<byte[]> ReadAsync(Stream s)
{
 using var ms = new MemoryStream();
 await s.CopyToAsync(ms);
 return ms.ToArray();
}

8.5 信任 CanSeek

1
2
3
4
5
6
7
8
9


// ❌ 假设 stream 可 Seek
stream.Position = 0;
stream.Read(...);

// ✅ 检查
if (stream.CanSeek)
 stream.Position = 0;
else
 throw new InvalidOperationException("Stream is not seekable");

8.6 CryptoStream 不 FlushFinalBlock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// ❌ 加密数据不完整
using var cs = new CryptoStream(ms, enc, CryptoStreamMode.Write);
cs.Write(data, 0, data.Length);
// 没有 cs.FlushFinalBlock() 或 Dispose → AES 填充没写

// ✅ Dispose 自动 flush
using (var cs = new CryptoStream(ms, enc, CryptoStreamMode.Write))
{
 cs.Write(data, 0, data.Length);
} // ← Dispose 触发 FlushFinalBlock

九、性能基准

9.1 Read 模式对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


[MemoryDiagnoser]
public class StreamBench
{
 private MemoryStream _stream;

 [GlobalSetup]
 public void Setup()
 {
 var data = new byte[1_000_000];
 new Random().NextBytes(data);
 _stream = new MemoryStream(data);
 }

 [Benchmark]
 public int ReadAll_Array()
 {
 _stream.Position = 0;
 byte[] buf = new byte[4096];
 int total = 0;
 int read;
 while ((read = _stream.Read(buf, 0, buf.Length)) > 0) total += read;
 return total;
 }

 [Benchmark]
 public async Task<int> ReadAllAsync_Array()
 {
 _stream.Position = 0;
 byte[] buf = new byte[4096];
 int total = 0;
 int read;
 while ((read = await _stream.ReadAsync(buf, 0, buf.Length)) > 0) total += read;
 return total;
 }

 [Benchmark]
 public async Task<int> ReadAllAsync_Pooled()
 {
 _stream.Position = 0;
 byte[] buf = ArrayPool<byte>.Shared.Rent(4096);
 try
 {
 int total = 0;
 int read;
 while ((read = await _stream.ReadAsync(buf.AsMemory(0, 4096))) > 0) total += read;
 return total;
 }
 finally
 {
 ArrayPool<byte>.Shared.Return(buf);
 }
 }

 [Benchmark]
 public async Task<int> ReadAll_CopyToAsync()
 {
 _stream.Position = 0;
 using var ms = new MemoryStream();
 await _stream.CopyToAsync(ms, 4096);
 return (int)ms.Length;
 }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


典型结果（.NET 8）：
 ReadAll_Array : ~280 μs, 4096 B allocated
 ReadAllAsync_Array : ~320 μs, 5 KB allocated
 ReadAllAsync_Pooled : ~300 μs, 0 B allocated ← 推荐
 ReadAll_CopyToAsync : ~280 μs, 0 B allocated ← 最简洁

观察：
 - CopyToAsync 性能与最优手写持平
 - ArrayPool 版几乎零分配
 - 普通 byte[] 分配每秒万次 → GC 噪音

十、Stream 子类速查

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


按用途分类：

 文件：
 FileStream - 文件 IO（默认 buffered）
 FileStream(FileOptions.Asynchronous) - 真异步
 UnmanagedMemoryStream - 内存映射文件 / 非托管内存

 网络：
 NetworkStream - Socket 包装
 SslStream - SSL/TLS 加密层
 AuthenticatedStream - 基类，可继承做认证

 内存：
 MemoryStream - byte[] 包装
 ReadOnlyMemoryStream - 不可变切片
 RecyclableMemoryStream - Microsoft.IO.RecyclableMemoryStream 库，池化版

 管道：
 AnonymousPipeServerStream / ClientStream - 父子进程
 NamedPipeServerStream / ClientStream - 命名管道

 装饰器：
 BufferedStream - 缓冲
 CryptoStream - 加密
 GZipStream / DeflateStream / BrotliStream - 压缩

 其他：
 Stream.Null - 黑洞
 IsolatedStorageFileStream - 沙盒存储

十一、选型决策

11.1 读文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


默认：
 using var fs = new FileStream(path, FileMode.Open, FileAccess.Read,
 FileShare.Read, 4096, FileOptions.Asynchronous);

 → 读大文件 / 高并发必开 Asynchronous
 → 简单一次性读取：File.ReadAllBytesAsync（内部就是上面的封装）

需要 seek：
 ✅ FileStream 默认支持

需要内存映射：
 MemoryMappedFile.CreateFromFile(...)

11.2 写文件

1
2
3
4
5
6
7
8
9


默认：
 using var fs = new FileStream(path, FileMode.Create, FileAccess.Write,
 FileShare.None, 4096, FileOptions.Asynchronous);

 → 加 BufferedStream 收益不大（FileStream 已有 buffer）
 → FileOptions.WriteThrough 用于关键数据（绕过 OS 缓存，直接落盘）

追加：
 File.AppendAllTextAsync / AppendAllBytesAsync

11.3 网络 IO

1
2
3
4
5
6
7


服务器：
 Socket → NetworkStream → 用 PipeReader 包装
 → 高性能场景直接用 Pipelines API

客户端：
 HttpClient（已经用 Pipelines 内部）
 → 不要手动 new NetworkStream

11.4 压缩 + 加密

1
2
3


写：CryptoStream → GZipStream → FileStream
读：FileStream → GZipStream → CryptoStream
注意 dispose 顺序（外层先 dispose，自动级联）

十二、小结

本文讲了 Stream 抽象从 .NET 1.0 到 9 的演进：

Stream 的"统一抽象"雄心：用基类覆盖所有 IO，代价是 CanXxx 标志遍布
最大的暗契约：Read 不保证读满，循环到 N 字节是基本功
API 六代演进：同步 → APM → TAP → Span/Memory → ReadExactly → Pipelines
FileStream 的"假异步"陷阱：必须显式开 FileOptions.Asynchronous
装饰器模式：GZipStream(CryptoStream(FileStream)) 的级联与 dispose
CopyToAsync 内部已经用 ArrayPool + Span 优化，优先用
Pipelines 是 Stream 的"接班人"：池化 buffer + 背压 + 多段 Sequence
ASP.NET Core 内部已经从 Stream 迁移到 PipeReader/Writer
6 类常见误用：不 Dispose / 不 await / 不开 Async / 不用 Pool / 信任 CanSeek / 不 Flush
子类速查与选型决策

1
2
3
4


记住三句话：
 1. Stream 是"拉"模式 + "同步"基础，Pipelines 是"推"模式 + 背压原生
 2. FileStream 不开 Asynchronous 等于自废武功
 3. Stream.Read 返回值永远不能假设"读满"——这是抽象的代价

下次写文件/网络代码时，先问自己：要不要直接用 Pipelines？不需要的话至少开 FileOptions.Asynchronous + ArrayPool + CopyToAsync。性能立刻上一个台阶。

深入 .NET Memory：Span 之后，为什么还需要一个 Memory？

Mon, 15 Jun 2026 08:30:00 +0800

.NET 高性能编程里有一对孪生兄弟——Span<T> 和 Memory<T>。两个看起来都在"包一段内存"，性能都说自己是"零拷贝、零分配"，但只要写到一处 await，IDE 就开始抱怨："Span<T> 是 ref struct，不能在这里用。"

这就是 Memory<T> 存在的全部动机——

Span<T> 是栈上的极致性能，但它有枷锁；Memory<T> 是它的"跨边界护照"，让零拷贝内存能安全地穿越 await、字段、IEnumerable<T> 这些"危险区域"。

理解这层关系，比记住一堆 API 重要。本文围绕这条主线，把 Memory<T> 从底层布局到使用陷阱彻底讲透。

一、回到 Span：极致性能的代价

要看懂 Memory，先看 Span 解决了什么、付出了什么。

1.1 没有 Span 之前

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 想对"一段连续数据"做处理，但来源五花八门：
void ProcessArray(byte[] arr, int offset, int len) { ... }
void ProcessString(string s, int offset, int len) { ... }
void ProcessPointer(IntPtr ptr, int len) { ... }

// 调用方：
ProcessArray(buffer, 10, 5);
ProcessString(text, 1, 3);

// 问题：
// - 每种来源要写一份重复代码
// - 调用方需要传 (array, offset, length) 三元组，容易出错
// - string 内部是 UTF-16，byte[] 是字节， IntPtr 是非托管，三者之间不能互通

1.2 Span 的设计：内存的"通用切片"

Span<T> 的内部其实就是两个字段：

1
2
3
4
5


public readonly ref struct Span<T>
{
 private readonly ref T _pointer; // 对内存的引用（byref）
 private readonly int _length;
}

1
2
3
4
5
6
7


关键点：
 1. ref T _pointer：不是普通指针，是"指向 T 的引用"（managed pointer）
 → 既能指向托管数组、也能指向 stackalloc、还能指向 native heap
 → GC 知道它在引用什么，不会被错判回收
 2. int _length：长度

 Span<T> 本体只是 16 字节（64 位下两个指针大小）

1.3 ref struct 的枷锁

Span<T> 是 ref struct，这个约束带来两个硬限制：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


❌ 不能作为 class 的字段
❌ 不能装箱（box） → 不能作为 object
❌ 不能跨 await / yield
❌ 不能实现 IDisposable 之外的接口
❌ 不能作为泛型参数 T（除非加 unmanaged 约束等）
❌ 不能被 lambda 捕获

为什么这么严？
 - ref T _pointer 是"内部指针"
 - 一旦允许装箱，就可能逃逸到堆
 - 一旦逃逸到堆，引用的目标（可能是 stackalloc 的栈内存）可能已经失效
 → 引用悬空 → GC 灾难 → 类型安全崩塌

 所以 ref struct 必须"留在栈上"，编译期阻止任何逃逸。

1.4 痛点：写异步代码时处处碰壁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


public async Task ProcessAsync(byte[] buffer)
{
 Span<byte> span = buffer.AsSpan();

 // ❌ 编译错误：Span 不能作为 lambda 字段
 await Task.Run(() => {
 // ... span ...
 });

 // ❌ 编译错误：Span 不能跨 await
 await DoSomethingAsync();
 Console.WriteLine(span.Length);

 // ❌ 编译错误：Span 不能作为字段
 // class Holder { public Span<int> Data; }
}

但这正是现代 .NET 异步编程的主战场——网络、文件、Pipe、Stream 全是异步。这里性能瓶颈也最重——一次性 byte[] 分配堆内存，进 GC，进 LOH，吞吐量直接掉。

需要一个东西：像 Span 一样零拷贝、但又能在异步边界安全传递。这就是 Memory<T>。

二、Memory 的设计：可装箱的"内存护照"

2.1 一句话定义

Memory<T> 是 Span<T> 的"可装箱、可跨 await"版本。它不持有 ref T，而是持有"提取 Span 的能力"，所以可以放在堆上。

2.2 内部布局

1
2
3
4
5
6


public readonly struct Memory<T>
{
 private readonly object _object; // 内存来源（可能是 T[]、string、MemoryManager<T>）
 private readonly int _index; // 起始偏移
 private readonly int _length; // 长度
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


和 Span 的核心差别：
 Span<T>：ref T _pointer ← GC 直接跟踪
 Memory<T>：object _object ← 通过对象间接引用

为什么这样设计？
 - 不持有 ref，所以 Memory 是普通 struct（不是 ref struct）
 - 可以装箱、可以跨 await、可以作为字段
 - 但 Span 暂时拿不到 → 需要"提取"

 Span 怎么提取？
 Span<T> span = memory.Span; ← 这个 getter 内部做"安全提取"

2.3 为什么 Memory 不直接持有 ref

1
2
3
4
5
6
7


假设 Memory<T> 持有 ref T _pointer：
 - Memory 是 struct，可以装箱
 - 装箱后 ref T 留在堆上
 - 如果原数据是 stackalloc → 装箱后栈释放 → ref 悬空 → 崩溃

→ Memory 设计上就不允许持有 ref，只能持有 object
→ 真要拿 Span 时，从 object 中提取，提取时编译器/运行时知道这是同步操作，安全

2.4 三种合法的 _object 类型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Memory<T>._object 只可能是三种：

1. T[] 数组
 - new int[100].AsMemory()
 - GC 知道这是托管堆上的数组，安全

2. string（仅当 T 为 char）
 - "hello".AsMemory()
 - string 不可变 → ReadOnlyMemory<char>

3. MemoryManager<T>（自定义）
 - 例如 MemoryManager<char> 包装 native 内存
 - 自定义 Pin() 让 GC 知道何时 pin

4. null（表示空 Memory 或 default）

1
2
3
4
5
6
7
8
9


// 三种典型构造方式
byte[] arr = new byte[100];
Memory<byte> m1 = arr.AsMemory(); // _object = arr

string s = "hello";
ReadOnlyMemory<char> m2 = s.AsMemory(); // _object = s

// 自定义（不常见）
Memory<int> m3 = MemoryMarshal.CreateFromPinnedArray(arr, 0, 100);

三、Memory 与 Span 的转换：一次"安全握手"

3.1 Memory → Span

1
2


Memory<byte> memory = new byte[1024];
Span<byte> span = memory.Span; // ← 提取

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


这一步是"零拷贝"的：
 - 内部根据 _object 类型生成 Span
 - 数组：span = new Span<T>((T[])_object, _index, _length)
 - string：span = ref Unsafe.AsRef(in s.GetFirstChar()) + offset
 - MemoryManager：调用 MemoryManager.GetSpan()

为什么这次"提取"是安全的？
 - 提取发生在栈上
 - 拿到的 Span<T> 不能逃逸（ref struct 约束）
 - 一旦 Span 用完，对象引用还在 Memory 里持有

3.2 Span → Memory：不能直接转

1
2


Span<byte> span = stackalloc byte[100];
Memory<byte> memory = span; // ❌ 编译错误！

为什么不行？因为 Span 可能指向栈内存（stackalloc），如果转成 Memory 装箱到堆上，栈帧结束后引用悬空。

但如果是数组-backed 的 Span，可以转：

1
2
3
4
5


Span<byte> span = new byte[100];
Memory<byte> memory = span.ToArray(); // ⚠️ 拷贝了一份！

// 或者用 MemoryMarshal（不安全）
Memory<byte> mem = MemoryMarshal.AsMemory(span); // ⚠️ 不推荐

3.3 Memory 的 Slice：返回 Memory

1
2
3
4
5
6


Memory<byte> mem = new byte[100];
Memory<byte> slice = mem.Slice(10, 20);

// 内部就是：
// return new Memory<T>(_object, _index + 10, 20);
// 仍然不持 ref，仍然可以装箱/跨 await

而 Span 的 Slice：

1
2
3
4
5


Span<byte> span = mem.Span;
Span<byte> slice = span.Slice(10, 20);

// 内部是：return new Span<T>(ref _pointer[10], 20);
// 仍然是 ref struct

3.4 转换成本对比

操作	成本
`Memory<T>.Span` 提取	几纳秒（一次方法调用 + 类型判断）
`Memory<T>.Slice`	16 字节 struct 创建
`Span<T>.Slice`	16 字节 struct 创建
`Memory<T>.ToArray()`	拷贝整个数组（O(n)）
`Memory<T>.Pin()`	创建 MemoryHandle，pin 对象

四、Memory 的三种来源

4.1 来自托管数组

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


byte[] buffer = new byte[4096];
Memory<byte> mem = buffer.AsMemory();

// 切片
Memory<byte> slice = mem.Slice(0, 1024);

// 跨 await
await ProcessAsync(slice);

async Task ProcessAsync(Memory<byte> data)
{
 // 在 await 前后都能用
 Span<byte> span = data.Span;
 span[0] = 0xFF;
 await Task.Yield();
 Console.WriteLine(span[0]); // 0xFF
}

4.2 来自字符串（仅 char）

1
2
3
4
5
6
7
8


string text = "Hello, World!";
ReadOnlyMemory<char> mem = text.AsMemory();

ReadOnlyMemory<char> word = mem.Slice(7, 5);
Console.WriteLine(word.ToString()); // "World"

// 跨 await 安全
await ProcessAsync(word);

1
2
3
4


注意：
 - string 是不可变的 → ReadOnlyMemory<char>
 - 不能改成 Memory<char>
 - 想要可变字符串用 StringBuilder 或 char[]

4.3 来自 MemoryManager（自定义）

MemoryManager<T> 是抽象类，让你包装"非标准内存"为 Memory<T>：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


public sealed class NativeMemoryManager<T> : MemoryManager<T>
{
 private unsafe T* _ptr;
 private readonly int _length;

 public unsafe NativeMemoryManager(T* ptr, int length)
 {
 _ptr = ptr;
 _length = length;
 }

 public override Span<T> GetSpan()
 {
 unsafe => new Span<T>(_ptr, _length);
 }

 public override MemoryHandle Pin(int elementIndex = 0)
 {
 unsafe => new MemoryHandle(_ptr + elementIndex, default, this);
 }

 public override void Unpin() { /* native 内存不需要 pin */ }

 protected override void Dispose(bool disposing)
 {
 // 释放 native 内存
 }
}

// 用法：
unsafe
{
 T* ptr = (T*)NativeMemory.Allocate(size);
 var manager = new NativeMemoryManager<T>(ptr, size);
 Memory<T> mem = manager.Memory;
 // 之后像普通 Memory 一样用
}

1
2
3
4
5
6
7


MemoryManager<T> 的常见应用：
 - 包装 native 内存（malloc、mmap）
 - 包装 unmanaged 集合
 - 包装内存映射文件
 - 包装 GC pin 的对象

ASP.NET Core、Pipelines 内部都用 MemoryManager 包装底层缓冲区。

五、IMemoryOwner：所有权管理

5.1 为什么需要"所有者"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


问题：Memory<T> 是 struct，不持有"释放"概念
 谁该释放底层 buffer？

场景：
 - 你从 ArrayPool 租了一个 buffer
 - 多个方法共享 Memory<byte>
 - 用完应该归还给 Pool

 Memory<byte> 本身没有 Return() 方法
 → 需要"所有者"对象负责归还

5.2 IMemoryOwner 接口

1
2
3
4


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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


谁实现：
 - MemoryPool<T>.Shared.Rent() 返回 IMemoryOwner<T>
 - 自定义实现（包装 ArrayPool）

使用模式：
 using var owner = MemoryPool<byte>.Shared.Rent(1024);
 Memory<byte> mem = owner.Memory;

 // 传给其他方法（不需要释放责任）
 await ProcessAsync(mem);

 // using 自动释放（归还给 Pool）

5.3 IMemoryOwner 的实现示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


public sealed class ArrayPoolOwner<T> : IMemoryOwner<T>
{
 private readonly T[] _array;
 private readonly ArrayPool<T> _pool;

 public ArrayPoolOwner(T[] array, ArrayPool<T> pool)
 {
 _array = array;
 _pool = pool;
 Memory = array;
 }

 public Memory<T> Memory { get; }

 public void Dispose() => _pool.Return(_array);
}

// 用法：
public IMemoryOwner<byte> GetBuffer(int size)
{
 var array = ArrayPool<byte>.Shared.Rent(size);
 return new ArrayPoolOwner<byte>(array, ArrayPool<byte>.Shared);
}

1
2
3
4
5


设计哲学：
 - Memory<T> = "使用权"（可以读、可以切片、可以传递）
 - IMemoryOwner<T> = "所有权"（谁负责释放）

 类似 C++ 的 unique_ptr / shared_ptr 模式

六、MemoryPool 与 ArrayPool：池化是关键

6.1 为什么池化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


每次 new byte[4096] 的代价：
 1. 分配（堆上找空间）
 2. GC 跟踪
 3. 触发 GC 时回收
 4. 大数组（≥85000 字节）进 LOH，GC 代际高、回收慢

 - Web 服务器每秒 1000 请求 × 每请求 4KB buffer
 = 4MB/s 分配 → 几秒就触发一次 Gen2 GC

池化的核心：
 - 租一个 buffer（Rent）：池里有就用，没有就 new
 - 用完归还（Return）：放回池，下次复用
 - GC 完全不参与

6.2 ArrayPool：池化的底层

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 租
byte[] buffer = ArrayPool<byte>.Shared.Rent(4096);
// 注意：实际返回的数组可能比请求的大（向上取整）
// 长度看 buffer.Length，不是 4096

try
{
 // 用 buffer
 int read = await stream.ReadAsync(buffer, 0, 4096);
}
finally
{
 // 归还
 ArrayPool<byte>.Shared.Return(buffer);

 // 如果数组被修改过且不需要清理，加 clearArray: false（默认）
 ArrayPool<byte>.Shared.Return(buffer, clearArray: false);
}

1
2
3
4
5
6
7
8


ArrayPool.Shared 的实现：
 - 每个桶（bucket）对应一种大小的数组
 - 线程本地缓存 + 全局共享
 - 默认大小：16, 32, 64, ..., 16384, 32768, ..., 1GB

注意：
 - 不能保存对归还后的数组的引用（你已不再"拥有"它）
 - 不能假设 Rent 的长度正好等于请求长度

6.3 MemoryPool：池化的 Memory 包装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// MemoryPool<T> 是 ArrayPool<T> 的"Memory 化"包装
using IMemoryOwner<byte> owner = MemoryPool<byte>.Shared.Rent(4096);
Memory<byte> mem = owner.Memory;

// mem.Length 可能 > 4096（实际数组大小）
// 切片到精确大小
Memory<byte> exact = mem.Slice(0, 4096);

await ProcessAsync(exact);

// using 自动归还

1
2
3
4
5
6
7


MemoryPool<T>.Shared = MemoryPool<T>.Create ArrayPool 内部包装

实际差别：
 - ArrayPool<byte>.Rent() → byte[] （要自己管 finally）
 - MemoryPool<byte>.Rent() → IMemoryOwner<byte> （using 即可）

 推荐：MemoryPool 更现代化、更适合异步代码

6.4 池化的坑

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// 坑 1：使用了归还后的数组
byte[] buf = ArrayPool<byte>.Shared.Rent(100);
ArrayPool<byte>.Shared.Return(buf);
buf[0] = 1; // ⚠️ buf 已不属于你，可能被别人覆盖

// 坑 2：在 using 之后还使用 Memory
async Task BadAsync()
{
 Memory<byte> mem;
 using (var owner = MemoryPool<byte>.Shared.Rent(100))
 {
 mem = owner.Memory; // 拿到引用
 } // ← owner 已 Dispose，buffer 已归还！
 mem.Span[0] = 1; // ⚠️ 未定义行为
}

// 坑 3：多线程同时 Rent + Return 同一数组
// 需要协议保证只在使用期间持有

// 坑 4：忘记 Return（内存泄漏）
// ArrayPool 不会自动回收，必须显式 Return

七、实战场景

7.1 高性能 IO：Stream.ReadAsync(Span) vs ReadAsync(Memory)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


// ❌ 同步 Span 版本：不能跨 await
public byte[] ReadAll(Stream stream)
{
 using var ms = new MemoryStream();
 Span<byte> buf = stackalloc byte[4096];
 int read;
 while ((read = stream.Read(buf)) > 0)
 {
 ms.Write(buf.Slice(0, read));
 }
 return ms.ToArray();
}

// ✅ 异步 Memory 版本
public async Task<byte[]> ReadAllAsync(Stream stream)
{
 using var ms = new MemoryStream();
 using var owner = MemoryPool<byte>.Shared.Rent(4096);
 Memory<byte> buf = owner.Memory;

 int read;
 while ((read = await stream.ReadAsync(buf)) > 0)
 {
 ms.Write(buf.Span.Slice(0, read));
 }
 return ms.ToArray();
}

1
2
3
4
5
6


Stream.ReadAsync 的演进：
 .NET Framework：ReadAsync(byte[], offset, count)
 .NET Core 2.1+：ReadAsync(Memory<byte>) 扩展方法（基于 ValueTask）
 .NET Standard 2.1+：原生支持

 推荐用 Memory 重载，零分配 + ValueTask 友好

7.2 文本解析器：避免 LOH

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


// 大文件逐行解析（避免一次性 ReadAllText）
public async IAsyncEnumerable<(int Line, string Text)> ParseLinesAsync(
 Stream stream,
 [EnumeratorCancellation] CancellationToken ct = default)
{
 using var owner = MemoryPool<byte>.Shared.Rent(64 * 1024);
 Memory<byte> buf = owner.Memory;

 int buffered = 0;
 int lineNo = 0;

 while (true)
 {
 int read = await stream.ReadAsync(buf.Slice(buffered), ct);
 if (read == 0) break;
 buffered += read;

 // 找换行
 var data = buf.Slice(0, buffered);
 int idx;
 while ((idx = data.Span.IndexOf((byte)'\n')) >= 0)
 {
 lineNo++;
 var line = data.Slice(0, idx);
 yield return (lineNo, Encoding.UTF8.GetString(line.Span));
 data = data.Slice(idx + 1);
 }

 // 剩余的移到 buf 开头
 data.Span.CopyTo(buf.Span);
 buffered = data.Length;
 }
}

7.3 协议解析：Memory 切片传递

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// 解析二进制协议（如 MessagePack / Protobuf）
public class ProtocolReader
{
 private readonly Stream _stream;
 private readonly IMemoryOwner<byte> _owner;
 private Memory<byte> _buffer;

 public ProtocolReader(Stream stream, int bufferSize = 4096)
 {
 _stream = stream;
 _owner = MemoryPool<byte>.Shared.Rent(bufferSize);
 _buffer = _owner.Memory;
 }

 public async Task<ReadOnlyMemory<byte>> ReadMessageAsync()
 {
 // 读 header（4 字节长度）
 await ReadExactAsync(_buffer.Slice(0, 4));
 int length = BitConverter.ToInt32(_buffer.Span.Slice(0, 4));

 // 读 body
 if (length > _buffer.Length)
 throw new InvalidOperationException("Message too large");

 var body = _buffer.Slice(4, length);
 await ReadExactAsync(body);
 return body;
 }

 private async Task ReadExactAsync(Memory<byte> dst)
 {
 int total = 0;
 while (total < dst.Length)
 {
 int read = await _stream.ReadAsync(dst.Slice(total));
 if (read == 0) throw new EndOfStreamException();
 total += read;
 }
 }
}

7.4 ASP.NET Core 内部的 Memory

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


ASP.NET Core 大量用 Memory<T>：
 - HttpContext.Request.Body : Stream，内部用 PipeReader
 - PipeReader 读出 ReadOnlySequence<byte>（一堆 Memory 拼接）
 - Response.Body.WriteAsync(ReadOnlyMemory<byte>)
 - SignalR 传输用 Memory<byte>

System.IO.Pipelines（Pipe / PipeReader / PipeWriter）：
 - 微软的"高性能 IO 抽象"
 - 替代 Stream 的"读一点写一点"模式
 - 内部全部 Memory<T> + IMemoryOwner<T>

八、ReadOnlyMemory 与可变性

1
2
3
4
5
6
7
8
9


Memory<byte> mem = new byte[100];
ReadOnlyMemory<byte> rom = mem; // 隐式转换

// ReadOnlyMemory 不能改
rom.Span[0] = 1; // ❌ 编译错误

// 但底层是同一个数组！
mem.Span[0] = 1;
Console.WriteLine(rom.Span[0]); // 1

1
2
3
4
5
6
7
8


观察：
 - ReadOnlyMemory<T> ≠ 不可变数据
 - 只是你"看不到"修改权限
 - 实际数据可能被另一个 Memory 引用修改

真正不可变的：
 - ImmutableArray<T>
 - 用 ToArray() 拷贝出来的副本

九、常见陷阱与最佳实践

9.1 持有 Memory 实际持有大数组

1
2
3
4
5
6
7
8
9


// 危险：Memory 是"切片"，但底层对象是整个数组
byte[] big = new byte[10_000_000];
Memory<byte> small = big.AsMemory(0, 10);

// small 看起来只有 10 字节，但 big 不能被 GC 回收！
return small; // 把 small 当返回值 → 大数组泄露

// 解决：用 ToArray()（如果数据真的小）
return small.ToArray();

1
2
3
4


Memory<T>.Pin() 也会 pin 整个数组：
 var handle = mem.Pin();
 // 在 handle Dispose 之前，整个底层数组被 GC pin
 // 不能移动、不能回收

9.2 跨 Method边界传递 Span

1
2
3
4
5
6
7
8


// ❌ 高性能反模式
public void Process(Span<byte> data) { ... }

// 如果 data 来自 stackalloc，调用方的栈结束后引用悬空
// ref struct 保证不会逃逸，但每次调用要重新算

// ✅ 改用 Memory
public Task ProcessAsync(Memory<byte> data) { ... }

9.3 用 ReadOnlyMemory 表达契约

1
2
3
4
5
6


// 表达"我只读不改"的契约
public Task<int> ParseAsync(ReadOnlyMemory<byte> data);

// 调用方既能传 Memory 也能传 ReadOnlyMemory
Memory<byte> m = ...;
await ParseAsync(m); // 隐式转换

9.4 避免 Memory 装箱

1
2
3
4
5
6


// Memory 是 struct，但装箱到 object 仍然是性能损失
object boxed = (object)mem; // ⚠️ 装箱
async Task<object> GetBoxedAsync() => mem; // ⚠️ 装箱

// 直接用 Memory<T>，不要用 object
async Task<Memory<byte>> GetAsync() => mem;

9.5 验证生命周期

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


public async Task BadAsync()
{
 Memory<byte> mem;
 using (var owner = MemoryPool<byte>.Shared.Rent(100))
 {
 mem = owner.Memory;
 // ❌ 把 mem 注册到回调，回调在 using 之后执行
 RegisterCallback(() => {
 mem.Span[0] = 1; // 已归还的 buffer！
 });
 }
}

// ✅ 正确：所有使用都在 using 范围内
public async Task GoodAsync()
{
 using var owner = MemoryPool<byte>.Shared.Rent(100);
 Memory<byte> mem = owner.Memory;
 await ProcessAsync(mem); // 整个 await 都在 using 范围内
}

十、MemoryMarshal：不安全边界

MemoryMarshal 提供"破坏封装"的低级操作，只在性能关键路径上用。

10.1 AsBytes：把 Memory 当 byte 看

1
2
3
4
5
6
7


int[] ints = new int[] { 1, 2, 3 };
Memory<int> mi = ints;

Memory<byte> mb = MemoryMarshal.AsBytes(mi);
// mb 是 12 字节，包含 ints 的原始字节

// 用途：序列化、CRC、二进制协议

10.2 Cast：类型重新解释

1
2
3
4
5
6


Memory<byte> bytes = new byte[16];
Memory<int> ints = MemoryMarshal.Cast<byte, int>(bytes);
// ints 现在是 4 个 int，指向同一块内存

// 注意：TFrom 和 TTo 大小必须能整除
// byte (1) → int (4)：16/4 = 4 个 int

10.3 TryGetArray：拿到原数组引用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Memory<byte> mem = new byte[100];

if (MemoryMarshal.TryGetArray(mem, out ArraySegment<byte> seg))
{
 // seg.Array 是原数组
 // seg.Offset 是偏移
 // seg.Count 是长度

 // 用途：调用旧 API（如 Stream.Read(byte[], offset, count)）
}

1
2
3
4
5
6


TryGetArray 失败的场景：
 - Memory 来自 string（仅 char）
 - Memory 来自 MemoryManager<T>
 - 没有底层托管数组

→ 失败时需要 fallback：拷贝到临时数组

10.4 CreateFromPinnedArray：pin 住

1
2
3
4
5
6
7


byte[] arr = new byte[100];
Memory<byte> mem = MemoryMarshal.CreateFromPinnedArray(arr, 0, 100);

// 创建时数组已被 pin
// mem.Span 拿到的指针不会被 GC 移动

// 用途：与 native 代码互操作（P/Invoke）

十一、性能基准

用 BenchmarkDotNet 看 Span vs Memory vs Array：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


// 基准测试代码
[MemoryDiagnoser]
public class MemBench
{
 private byte[] _data = new byte[1024];

 [Benchmark]
 public int SumArray()
 {
 int sum = 0;
 for (int i = 0; i < _data.Length; i++) sum += _data[i];
 return sum;
 }

 [Benchmark]
 public int SumSpan()
 {
 int sum = 0;
 foreach (var b in _data.AsSpan()) sum += b;
 return sum;
 }

 [Benchmark]
 public int SumMemory()
 {
 int sum = 0;
 foreach (var b in _data.AsMemory().Span) sum += b;
 return sum;
 }
}

1
2
3
4
5
6
7
8
9


典型结果（.NET 8）：
 SumArray : ~150 ns
 SumSpan : ~120 ns ← 最快（少了边界检查）
 SumMemory : ~125 ns ← 几乎和 Span 一样（提取 Span 后循环）

观察：
 - Span 和 Memory 性能几乎一致（同步路径下）
 - Array 比 Span 略慢（边界检查开销）
 - Memory 的提取开销可忽略（仅一次方法调用）

十二、小结

本文从 Span<T> 的"栈枷锁"出发，系统讲了 Memory<T>：

Memory<T> 的内部布局：object + index + length（不持 ref）
为什么这样设计：可装箱、可跨 await、可作为字段
三种来源：T[] 数组、string、MemoryManager
与 Span 的转换：Memory.Span 提取、不能反向
IMemoryOwner<T> 的所有权语义
ArrayPool<T> 与 MemoryPool<T> 的池化机制
实战场景：异步 IO、文本解析、协议解析、ASP.NET Core 内部
常见陷阱：持有切片但底层数组泄露、生命周期错位、装箱
MemoryMarshal 的不安全操作

1
2
3
4


记住三句话：
 1. Span 是栈上的极致性能，Memory 是它的"跨边界护照"
 2. Memory<T>.Span 是一次"安全握手"，提取后 Span 仍然不能逃逸
 3. 池化（ArrayPool/MemoryPool）是高性能 .NET 的标配——少了它就是每秒万次的 GC

下次写异步 IO 或文本解析时，先用 MemoryPool<T>.Shared.Rent() + using，性能立刻上一个台阶。