如何以DRY风格高效编写方法的异步版本？

你的直觉是对的——用Task.Run把整个同步方法包装成异步的做法存在效率问题，甚至在高并发场景下会引发性能瓶颈。这种方式本质是假异步：它只是把同步阻塞的IO操作放到线程池线程里执行，并没有利用异步IO的优势，反而会浪费线程资源。

原实现的核心问题 #

• Task.Run会占用线程池线程，而同步的ReadExactly是阻塞调用，线程在等待IO完成时完全空闲，无法处理其他任务。在IO密集型场景下，这种做法会快速耗尽线程池，导致请求排队、响应变慢。
• 没有利用Stream原生的异步API，违背了异步编程的初衷。

正确的实现模式：拆分IO逻辑与共享业务逻辑 #

遵循DRY原则的正确做法是：将IO操作和共享的业务处理逻辑拆分开，同步版本使用同步IO API，异步版本使用异步IO API，两者复用同一套业务处理代码。

示例代码如下：

public abstract class Reader
{
    public abstract int Length { get; }

    // 同步读取：使用Stream的同步IO方法
    public bool TryRead(Stream stream, byte[] buffer)
    {
        if (stream.Length - stream.Position < Length)
        {
            return false;
        }

        // 同步读取数据
        stream.ReadExactly(buffer);

        // 复用共享的业务处理逻辑
        ProcessBuffer(buffer);

        return true;
    }

    // 异步读取：使用Stream的原生异步IO方法
    public async Task<bool> TryReadAsync(Stream stream, byte[] buffer, CancellationToken cancellationToken = default)
    {
        if (stream.Length - stream.Position < Length)
        {
            return false;
        }

        // 异步读取，不会阻塞线程池线程
        await stream.ReadExactlyAsync(buffer, cancellationToken).ConfigureAwait(false);

        // 复用共享的业务处理逻辑
        ProcessBuffer(buffer);

        // 如果ProcessBuffer是CPU密集型操作，可以用Task.Run异步执行（可选）
        // await Task.Run(() => ProcessBuffer(buffer), cancellationToken).ConfigureAwait(false);

        return true;
    }

    // 提取共享的业务处理逻辑，避免代码重复
    protected abstract void ProcessBuffer(byte[] buffer);
}

关键说明 #

1. 原生异步IO的优势：ReadExactlyAsync是Stream的原生异步方法，它在等待IO完成时不会阻塞线程，线程可以被线程池调度去处理其他任务，这才是真正的异步IO，能大幅提升高并发场景下的性能。
2. 复用业务逻辑：将后续的"lengthy stuff"提取到ProcessBuffer方法中，同步和异步版本都调用这个方法，完全遵循DRY原则，没有重复代码。
3. CPU密集型处理的异步化：如果ProcessBuffer是CPU密集型操作，异步版本中可以用Task.Run将其放到线程池执行，但注意不要把IO操作也包进去——IO部分必须用原生异步API。

额外建议 #

• 始终优先使用.NET类库提供的原生异步API，而不是用Task.Run包装同步方法。
• 异步方法中建议添加CancellationToken参数，支持取消操作，提升代码的健壮性。

内容的提问来源于stack exchange，提问作者aybe