C#中System.Net.Sockets.Socket.AcceptAsync为何不是async修饰的异步方法

你对异步方法的初始认知对应.NET 4.0之后主推的基于任务的异步模式（TAP），这确实是当前主流的异步写法，但不是.NET生态里唯一的异步实现规范，你遇到的返回bool的AcceptAsync（通常是Socket类下的重载）是更早的异步模式实现。

1. 该方法的异步实现逻辑 #

这个AcceptAsync的完整签名一般是public bool AcceptAsync(System.Net.Sockets.SocketAsyncEventArgs e)，它的异步逻辑是围绕传入的SocketAsyncEventArgs对象实现的：

• 调用前你需要先构造SocketAsyncEventArgs实例，为它绑定Completed事件的处理回调，配置相关参数
• 调用后如果返回false：说明Accept操作已经同步完成，不会触发Completed事件，你可以直接读取SocketAsyncEventArgs对象里的结果处理即可
• 调用后如果返回true：说明Accept操作已经提交到内核异步IO队列，当前线程不会阻塞挂起，等到内核完成端口处理完连接请求后，会自动触发你提前绑定的Completed事件，你在事件回调中处理结果即可

2. 模式归属 #

它属于*.NET基于事件的异步模式（EAP）*的高性能变种，EAP是.NET Framework 2.0时代推出的异步规范，标准实现就是通过方法触发异步操作，操作完成后触发对应事件执行后续逻辑。这个重载额外加了bool返回值，是为了优化IO操作可以瞬间完成的场景，避免不必要的事件调度开销，适配Socket高并发的性能要求。

3. 和async/await异步模式的关联 #

两者核心的异步设计思想是完全一致的：都是避免调用线程阻塞等待IO完成，通过回调机制执行操作完成后的后续逻辑，只是实现形式和推出时间不同：

• EAP是更早的异步规范，回调通过事件绑定实现
• 你熟悉的带async修饰符、返回Task的是TAP模式，是.NET后续推出的简化异步开发的规范，回调被封装成了Task的延续任务，async/await是语法糖帮你省略了手动编写延续逻辑的代码
• 两类实现可以互相适配：你可以通过TaskCompletionSource把这个AcceptAsync封装成返回Task的方法，就可以直接用await调用

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