Csharp on Coding with Denglei

.NET 中 .Result 避坑指南：不同框架下的死锁与线程池饥饿

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

这篇只讲一个知识点：在 .NET 代码里用 .Result（或 GetAwaiter().GetResult()）同步阻塞异步任务，为什么在不同框架下会触发不同类型的事故。

问题背景

同样一行代码，在两个系统里出现了完全不同的故障：

老系统（ASP.NET MVC 5）请求直接卡死，不返回
新系统（ASP.NET Core）不是直接死锁，而是高峰期吞吐突然掉到很低，请求排队超时

两边都有这段写法：

public string GetData()
{
    return GetDataAsync().Result;
}

private async Task<string> GetDataAsync()
{
    await Task.Delay(50);
    return "ok";
}

原理：同一个坑，两种后果

场景 1：ASP.NET Classic / WinForms / WPF（有 SynchronizationContext）

这类框架默认要求 continuation 回到原上下文（UI 线程或请求上下文）。

.Result 先把当前线程阻塞住，Task 完成后 continuation 又想回到这条线程，结果互相等待：

当前线程在 .Result 处阻塞
continuation 需要回到当前线程继续执行
当前线程被阻塞，continuation 进不来
死锁

所以你会看到"请求一直转圈"或"界面完全卡死"。

场景 2：ASP.NET Core（默认无 SynchronizationContext）

在默认配置下，ASP.NET Core 没有传统的请求级 SynchronizationContext，所以通常不会触发上面的经典互锁。

它会把线程池工作线程同步阻塞住。并发一上来，越来越多线程被卡在 .Result，线程池来不及补充，新请求拿不到线程，就出现线程饥饿：

CPU 不一定高
数据库不一定慢
但接口耗时和超时数暴涨

这就是"看起来不像死锁，但系统几乎不可用"的典型表现。

最小对照示例

public sealed class DemoService
{
    // ❌ 错误：同步包装异步
    public int GetNumber()
    {
        return GetNumberAsync().Result;
    }

    // ✅ 正确：异步到底
    public async Task<int> GetNumberAsync()
    {
        await Task.Delay(10);
        return 42;
    }
}

如何避坑（只保留最关键三条）

不要在任何业务调用链上使用 .Result / .Wait() / GetAwaiter().GetResult()。
API、Service、Repository 全链路改成 async，不要做"同步方法包异步"。
如果历史包袱必须保留同步签名，就让边界层同步，内部仍然异步，避免层层阻塞传染。

一句结论

.Result 在老框架里更容易直接死锁，在 ASP.NET Core 里更容易演化成线程池饥饿；表现不同，本质相同，都是"阻塞等待异步"导致的。

.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 层只负责入队，不直接做重任务：

Csharp on Coding with Denglei

.NET 中 .Result 避坑指南：不同框架下的死锁与线程池饥饿

问题背景

原理：同一个坑，两种后果

场景 1：ASP.NET Classic / WinForms / WPF（有 SynchronizationContext）

场景 2：ASP.NET Core（默认无 SynchronizationContext）

最小对照示例

如何避坑（只保留最关键三条）

一句结论

.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. 示例代码：有边界的后台处理模型

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

2.1 `Task` 与调度

2.2 `ValueTask` 的边界