Performance on Coding with Denglei

.NET 内存性能优化实战：Span、ArrayPool、GC 与 LOH 控制

Tue, 16 Jun 2026 17:04:23 +0800

很多服务在压测里吞吐不错，一上生产就抖。根因常常不是业务逻辑，而是内存分配模式不健康。

典型表现：

GC 频率偏高
P99 周期性尖峰
单机吞吐不稳定

这篇文章重点讲“如何减少无意义分配”，并把优化控制在团队可维护范围内。

问题背景

真实现场：一次常规版本上线后，接口平均耗时变化不大，但 P99 从 120ms 拉到 380ms，最后定位到的是字符串拼接和临时数组在高峰时段触发了更频繁的 GC。

一个日志清洗或协议解析接口，经常会写出这样的代码：

var parts = line.Split('|');
var user = parts[0].Trim();
var action = parts[1].Trim();
var ts = DateTime.Parse(parts[2]);

逻辑简单，但每次请求都在制造短命对象。高并发下，这些小分配会形成大压力。

原理解析

代际 GC

短命对象主要在 Gen0/Gen1 回收。分配速率过高时，GC 会频繁触发，吞吐被打断。

LOH（大对象堆）

大于约 85KB 的对象进入 LOH。大对象频繁创建和释放，会导致更重的回收成本和内存碎片问题。

`Span<T>` 与 `ArrayPool<T>`

Span<T> 在不额外分配的前提下切片处理内存
ArrayPool<T> 复用数组，避免重复 new 大缓冲区

示例代码

先定义记录：

public sealed record AuditLog(string User, string Action, DateTime Timestamp);

使用 ReadOnlySpan<char> 解析：

public static bool TryParseAuditLog(string line, out AuditLog? log)
{
    log = null;
    ReadOnlySpan<char> span = line.AsSpan();

    var p1 = span.IndexOf('|');
    if (p1 < 0) return false;

    var p2 = span[(p1 + 1)..].IndexOf('|');
    if (p2 < 0) return false;
    p2 += p1 + 1;

    var user = span[..p1].Trim();
    var action = span[(p1 + 1)..p2].Trim();
    var tsText = span[(p2 + 1)..].Trim();

    if (!DateTime.TryParse(tsText, out var ts)) return false;

    log = new AuditLog(user.ToString(), action.ToString(), ts);
    return true;
}

对于大文本拼接，使用池化数组：

C# 异步编程实战：Task、ValueTask、线程池饥饿与背压设计

Tue, 16 Jun 2026 17:04:23 +0800

接口慢，不一定是数据库慢。很多系统在高峰期的核心问题，是异步链路写法导致线程池被慢慢耗空。

这类问题最麻烦的地方在于：

CPU 不一定打满
错误日志不一定明显
本地压测可能复现不出来

这篇文章围绕一个目标展开：让异步代码在高并发下“稳态运行”，而不是“平时很快，高峰崩盘”。

1. 问题背景：为什么会出现线程池饥饿

常见触发方式：

在 ASP.NET Core 请求中使用 .Result / .Wait()
把 I/O 任务包进 Task.Run
下游服务抖动时无限制并发重试

你以为是在“提速”，实际上是在制造排队。

2. 原理解析

2.1 `Task` 与调度

Task 表示异步操作，不等于“新线程”。多数场景下，它复用线程池线程在不同 I/O 等待阶段切换。

2.2 `ValueTask` 的边界

ValueTask 适合高频且经常同步完成的路径，减少分配；但它有使用约束，不应随意替换所有 Task。

2.3 线程池饥饿

当大量请求线程被阻塞等待 I/O，线程池补充速度跟不上时，后续请求只能排队，RT 开始抖动。

2.4 背压

背压本质是“主动限制进入系统的工作量”，通过队列边界和并发上限把峰值削平，换取整体稳定。

3. 示例代码：有边界的后台处理模型

下面是一个可落地的最小模型：Channel + 有界队列 + 固定并发消费者。

using System.Threading.Channels;

public sealed record ExportJob(Guid JobId, long UserId, DateTime CreatedAt);

public sealed class ExportQueue
{
    private readonly Channel<ExportJob> _channel = Channel.CreateBounded<ExportJob>(
        new BoundedChannelOptions(500)
        {
            FullMode = BoundedChannelFullMode.DropWrite,
            SingleWriter = false,
            SingleReader = false
        });

    public bool TryEnqueue(ExportJob job) => _channel.Writer.TryWrite(job);
    public IAsyncEnumerable<ExportJob> ReadAllAsync(CancellationToken ct) => _channel.Reader.ReadAllAsync(ct);
}

public sealed class ExportWorker : BackgroundService
{
    private readonly ExportQueue _queue;
    private readonly ILogger<ExportWorker> _logger;
    private readonly SemaphoreSlim _concurrency = new(4);

    public ExportWorker(ExportQueue queue, ILogger<ExportWorker> logger)
    {
        _queue = queue;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var job in _queue.ReadAllAsync(stoppingToken))
        {
            _ = ProcessOneAsync(job, stoppingToken);
        }
    }

    private async Task ProcessOneAsync(ExportJob job, CancellationToken ct)
    {
        await _concurrency.WaitAsync(ct);
        try
        {
            await Task.Delay(200, ct); // 模拟 I/O
            _logger.LogInformation("export done {JobId}", job.JobId);
        }
        catch (OperationCanceledException)
        {
            // 正常退出
        }
        finally
        {
            _concurrency.Release();
        }
    }
}

API 层只负责入队，不直接做重任务：

EF Core 写入链路实战：从 ChangeTracker 到 SQL Batch 的性能诊断与优化

Tue, 16 Jun 2026 17:04:23 +0800

这篇文章讨论一个问题：一次写入请求从实体变更到数据库落盘，中间到底发生了什么，哪里最容易慢，以及应该怎么定位。

问题背景

真实场景：订单系统在白天吞吐稳定，凌晨高峰出现周期性尖峰。接口平均耗时变化不大，但 P95 从 80ms 抬到 420ms，数据库 CPU 也出现波峰。

排查后发现：

应用层每次批量处理 2000 条数据
循环中频繁触发变更检测
每条数据都单独 SaveChanges
最终生成大量碎片化 SQL 往返

这类问题看起来像“数据库有点拉，扛不住了”，实际上很多成本来自应用侧写入链路组织不当。

原理解析

`ChangeTracker` 负责记录变更

EF Core 需要知道哪些实体是新增、修改、删除，这些状态都由 ChangeTracker 管理。默认情况下，EF Core 会在多个时机触发 DetectChanges，例如：

调用 SaveChanges / SaveChangesAsync
访问部分跟踪集合
某些 Add / Attach 组合场景

如果一个 DbContext 里挂了大量实体，频繁 DetectChanges 会带来明显 CPU 开销。

`SaveChanges` 并不是“一条语句”

一次 SaveChanges 大致会经历这些步骤：

执行变更检测，确定实体状态
生成修改命令（insert/update/delete）
按提供程序规则组装批次（batch）
开启事务并执行命令
成功后调用 AcceptAllChanges

性能问题通常出在 2-4 步：命令太碎、批次太小、往返太多、事务范围不合理。

SQL Batch 决定数据库往返次数

以 SQL Server 为例，EF Core 会尽可能把多条 DML 合并到一个批次中执行，但合并能力受多种因素影响：

EF Core 慢查询排查实战：TagWith、OpenTelemetry 与执行计划

Tue, 16 Jun 2026 17:04:23 +0800

EF Core 性能问题里，最折磨人的不是“慢”，而是“慢得没规律”，线上卡，测试又无法复现。

很多小D、小W同学都经历过这种现场：

压测数据很好看
数据库 CPU 没打满
业务代码看起来也没什么大问题

你改了几个 Include，可能短期有效，但过两周又抖回来。根因往往不是某一行 LINQ 写错，而是整条排查链路没打通。

这篇文章就做一件事：给你一套能线上落地的 EF Core 慢查询定位闭环，从应用日志一路追到数据库执行计划，不靠猜。

问题背景：为什么本地快、线上慢

真实场景：订单列表接口平时 80ms 左右，高峰时段 P95 抬到 1s。你的第一反应是“数据库是不是扛不住了”，但监控显示：

数据库 CPU 长期低于 50%
连接池没有打满
磁盘 IO 没明显异常

排查下来，又遇到两个组合问题：

列表查询没有打 SQL 标签，日志里几百条 SQL 根本分不出谁是谁
某些筛选条件线上本地索引匹配不同，SQL 文本相同但参数分布不同，执行计划差异很大

也就是说，问题不是“不会优化 SQL”，而是“看不见慢点在哪”。

原理解析：慢查询定位为什么总是卡在一半

EF Core 的查询链路大致是：

LINQ 表达式翻译成 SQL
命令发送到数据库执行
结果集回传并在应用层物化

很多排查第一步都把 SQL 抓出来看看，忽略了第 2、3 步的上下文信息，比如：

这条 SQL 是哪个接口触发的
这次慢是数据库执行慢，还是返回数据太大导致物化慢
慢的是固定 SQL，还是同模板下某些参数更慢

要拿到这些信息，最实用的组合就是：

TagWith：给 SQL 打业务标签
OpenTelemetry：采集耗时、TraceId、SQL 标签并统一上报
执行计划：确认索引命中、回表、扫描和 Key Lookup

三者合起来，才能形成可服用、可验证的排查闭环。

EF Core 查询性能实战：Include、投影与跟踪策略边界

Tue, 16 Jun 2026 17:04:23 +0800

很多团队把 EF Core 的性能问题归因于“ORM 天生慢”，但线上真实情况通常是：

查询写法对 SQL 形态不敏感
默认跟踪被滥用
图省事一次 Include 到底

结果是接口能跑，但高峰时段 P95 持续抬高，数据库 CPU 和网络带宽一起被拖上去。

这篇文章聚焦一个目标：把 EF Core 查询从“能查到数据”升级到“可预测、可解释、可优化”。

1. 问题背景：列表页为什么越改越慢

一个典型场景：订单列表页需要展示订单、客户、明细、商品。

最直觉的写法是连续 Include：

var orders = await db.Orders
    .Include(o => o.Customer)
    .Include(o => o.Items)
        .ThenInclude(i => i.Product)
    .Where(o => o.CreatedAt >= from && o.CreatedAt < to)
    .OrderByDescending(o => o.CreatedAt)
    .Take(50)
    .ToListAsync();

这段代码看起来“很完整”，但常见后果是：

结果集行数被笛卡尔放大
应用端做了大量重复对象反序列化和跟踪
实际只显示 6 个字段，却把整个对象图都拉回来了

2. 原理解析：EF Core 查询成本主要花在哪里

2.1 翻译成本

LINQ 先被转换为表达式树，再翻译成 SQL。复杂投影、方法调用、局部函数容易导致翻译退化或直接失败。

2.2 执行与网络成本

Include 深度越深，JOIN 越复杂，网络回包越大。很多慢查询不是数据库“算得慢”，而是“传得多”。

2.3 跟踪成本

默认跟踪模式会创建实体快照，便于更新，但纯读场景这部分是额外开销。

2.4 物化成本

即使 SQL 很快，应用层物化大量实体和导航属性也会抬高 CPU 与内存分配。

3. 示例代码：从全量实体到精准投影

先给出推荐的读模型查询写法：

public sealed record OrderListItemDto(
    long Id,
    string OrderNo,
    string CustomerName,
    decimal TotalAmount,
    int ItemCount,
    DateTime CreatedAt);

var query = db.Orders
    .AsNoTracking()
    .Where(o => o.CreatedAt >= from && o.CreatedAt < to)
    .OrderByDescending(o => o.CreatedAt)
    .Select(o => new OrderListItemDto(
        o.Id,
        o.OrderNo,
        o.Customer.Name,
        o.Items.Sum(i => i.Quantity * i.UnitPrice),
        o.Items.Count,
        o.CreatedAt));

var page = await query.Take(50).ToListAsync();

对于高频、形态固定的查询，可以进一步使用编译查询：

从 IApplicationBuilder 到 RequestDelegate：ASP.NET Core 请求管线性能与可观测性

Tue, 16 Jun 2026 17:04:23 +0800

很多团队做性能优化时，第一反应是改 SQL、加缓存、扩机器。结果接口还是慢，而且慢得不稳定。

这类问题里，有一部分根因并不在业务代码，而在请求进入业务之前就已经产生了: 中间件顺序、重复序列化、过重日志、异常处理位置不当，都会把每个请求的固定成本悄悄抬高。

这篇文章我们不讲抽象概念，直接从一个真实工程场景出发，拆开 ASP.NET Core 请求管线，回答三个问题:

请求管线到底是怎么执行的
哪些中间件写法会稳定拉低吞吐
如何在不牺牲可观测性的前提下，把链路成本控制住

1. 问题背景: 为什么明明 CPU 不高，RT 却在抖

先看一个常见现象:

峰值时段 P95 从 35ms 涨到 90ms
CPU 只到 45%
数据库监控正常
线程池没有明显爆满

像商场收银台排队: 收银员速度没变，库存系统也没卡，但每位顾客在真正结账前都要先填两张表、复印一次小票、走一段绕路。单人多花 10 秒，队伍就会在高峰时段整体失控。

在 Web 服务里，这段“真正结账前的绕路”就是请求管线上的固定开销。

典型问题包括:

将高成本日志中间件放在链路最前面，且对所有请求都做完整 Body 记录
鉴权、异常处理、路由等中间件顺序错误，导致重复执行或额外分支判断
在中间件中做同步阻塞 I/O
将一些本该按采样写出的指标，变成了每请求都完整打点

2. 原理解析: IApplicationBuilder 如何变成 RequestDelegate

ASP.NET Core 启动时，IApplicationBuilder 会把你注册的中间件构造成一个 RequestDelegate 链。

关键点只有两个，但经常被忽略:

中间件按“注册顺序”进入，按“逆序”包裹执行。每个中间件把后续链路作为自己的 next，形成嵌套闭包。
任意中间件都可以不调用 next()，从而短路后续链路。

一个简化模型如下:

RequestDelegate app = context => Task.CompletedTask;

app = MiddlewareC(app);
app = MiddlewareB(app);
app = MiddlewareA(app);

// 实际执行顺序: A -> B -> C -> Endpoint -> C -> B -> A

这意味着:

Performance on Coding with Denglei

.NET 内存性能优化实战：Span、ArrayPool、GC 与 LOH 控制

问题背景

原理解析

代际 GC

LOH（大对象堆）

Span<T> 与 ArrayPool<T>

示例代码

C# 异步编程实战：Task、ValueTask、线程池饥饿与背压设计

1. 问题背景：为什么会出现线程池饥饿

2. 原理解析

2.1 Task 与调度

2.2 ValueTask 的边界

2.3 线程池饥饿

2.4 背压

3. 示例代码：有边界的后台处理模型

EF Core 写入链路实战：从 ChangeTracker 到 SQL Batch 的性能诊断与优化

问题背景

原理解析

ChangeTracker 负责记录变更

SaveChanges 并不是“一条语句”

SQL Batch 决定数据库往返次数

EF Core 慢查询排查实战：TagWith、OpenTelemetry 与执行计划

问题背景：为什么本地快、线上慢

原理解析：慢查询定位为什么总是卡在一半

EF Core 查询性能实战：Include、投影与跟踪策略边界

1. 问题背景：列表页为什么越改越慢

2. 原理解析：EF Core 查询成本主要花在哪里

2.1 翻译成本

2.2 执行与网络成本

2.3 跟踪成本

2.4 物化成本

3. 示例代码：从全量实体到精准投影

从 IApplicationBuilder 到 RequestDelegate：ASP.NET Core 请求管线性能与可观测性

1. 问题背景: 为什么明明 CPU 不高，RT 却在抖

2. 原理解析: IApplicationBuilder 如何变成 RequestDelegate

`Span<T>` 与 `ArrayPool<T>`

2.1 `Task` 与调度

2.2 `ValueTask` 的边界

`ChangeTracker` 负责记录变更

`SaveChanges` 并不是“一条语句”