NetworkStream异步方法：未调用EndRead的影响与超时实现疑问

这是个非常务实的问题——很多人在处理.NET旧版APM异步模式时，都会在超时和资源清理的环节纠结这个点。咱们一步步拆解来看：

• 资源泄漏：APM模式的核心规则就是「每一个BeginXxx必须对应一个EndXxx」。BeginRead会在底层分配异步操作相关的资源（比如IOCP端口上下文、异步状态对象等），如果跳过EndRead，这些资源无法被.NET运行时正确回收，长期运行会导致内存泄漏，甚至耗尽系统的IO调度资源。
• 不可预测的后台操作：未收尾的异步读操作可能会在后台继续执行，哪怕你已经关闭了NetworkStream。这可能引发后续对关联资源的异常，或者让系统资源被无效占用。
• 破坏异步状态一致性：.NET的异步运行时会跟踪所有未完成的APM操作，跳过EndRead会让运行时误以为这个操作还在进行中，进而影响线程池调度效率，甚至干扰其他异步任务的执行。

答案是绝对不行。虽然你觉得捕获异常像「拙劣的临时方案」，但跳过EndRead带来的资源泄漏问题，远比捕获异常严重得多。

不过你可以优化异常处理的方式，让它更优雅：

• 提前跟踪流状态：在调用EndRead前，先判断流的状态（比如.NET Core 2.0+可用的NetworkStream.IsClosed，或者自己维护一个流关闭的标记）。但要注意：即使流已经关闭，之前发起的BeginRead可能已经在执行中，依然需要调用EndRead清理资源——这时候抛出的ObjectDisposedException是合理的，只需捕获并正常处理即可。
• 用状态对象统一管理：发起BeginRead时，把流、超时标记、操作状态等封装到自定义对象中。回调里先检查状态，如果已经超时或流关闭，再调用EndRead并捕获异常，最后统一清理资源。

你可以结合ManualResetEvent和定时器来实现超时，同时严格保证EndRead被调用：

public void ReadWithTimeout(NetworkStream stream, byte[] buffer, int timeoutMs)
{
    var resetEvent = new ManualResetEvent(false);
    var state = new { Stream = stream, Buffer = buffer, ResetEvent = resetEvent };
    
    IAsyncResult result = stream.BeginRead(buffer, 0, buffer.Length, ar =>
    {
        var stateObj = (dynamic)ar.AsyncState;
        try
        {
            // 哪怕超时，也必须调用EndRead清理资源
            int bytesRead = stateObj.Stream.EndRead(ar);
            // 这里处理读取到的数据
        }
        catch (ObjectDisposedException)
        {
            // 流因超时被关闭，属于预期情况，无需额外处理
        }
        finally
        {
            stateObj.ResetEvent.Set();
        }
    }, state);
    
    // 等待操作完成或超时触发
    if (!resetEvent.WaitOne(timeoutMs))
    {
        // 超时后主动关闭流
        stream.Close();
    }
}

这个方案既实现了超时逻辑，又严格遵守了APM模式的资源清理规则，避免了泄漏风险。

最后再强调一次：APM模式的Begin/End配对是硬性规则，跳过EndRead绝对是饮鸩止渴。捕获ObjectDisposedException在这里不是临时方案，而是符合.NET异步模型规范的正确做法。

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