同步Socket高并发下因线程阻塞和资源耗尽而卡死；异步Socket应复用SocketAsyncEventArgs和ArrayPool缓冲区，避免GC与上下文切换，吞吐量可达5–10倍提升。
同步Socket在高并发下会迅速卡死
同步调用 Socket.Receive() 或 Socket.Send() 时，线程会一直阻塞直到数据收发完成。哪怕只是处理几百个长连接，用 Thread 每连接起一个线程，很快就会耗尽线程池资源，出现大量 ThreadAbortException 或响应延迟飙升。这不是代码写得不好，而是模型本身无法横向扩展。
异步Socket真正靠的是 SocketAsyncEventArgs 复用
很多人以为用 BeginReceive/EndReceive 就算“异步”了，其实那是基于线程池的伪异步，开销不小。真正高性能的做法是预分配一批 SocketAsyncEventArgs 实例，反复 SetBuffer + AcceptAsync/ReceiveAsync，避免每次收发都 new 对象、触发 GC。关键点：
-
SocketAsyncEventArgs必须手动调用Dispose()（通常在连接关闭时） - 缓冲区最好用
ArrayPool<byte>.Shared.Rent()</byte>管理，而不是每次都new byte[8192] -
ReceiveAsync返回false表示同步完成，true才进回调 —— 别默认以为一定异步
吞吐量差距在真实场景中可达 5–10 倍
用相同硬件压测一个回显服务（单机 4 核 8G）：
同步模式（每连接一线程）：约 1200 QPS，CPU 95% 时连接数卡在 300 左右 异步模式（单线程 EventLoop + SocketAsyncEventArgs 池）：稳定 8500+ QPS，CPU 利用率 65%~75%
差距主要来自三方面：
- 内存分配：同步模式每连接至少多出 1MB 线程栈 + 频繁 buffer new；异步模式 buffer 复用后 GC 压力极低
- 上下文切换：300 个线程调度开销远高于 1 个线程处理 3000 个 socket 的 I/O 完成通知
- 系统调用密度：异步模式下
WSARecv调用更紧凑，更容易被 IOCP 批量投递
别忽略 IOCompletionPort 的隐式绑定成本
.NET 的 Socket 异步方法底层走 Windows IOCP，但首次调用 ReceiveAsync 时才会把 socket 关联到线程池的完成端口 —— 这个过程有微小延迟。如果连接建立后立刻发数据，可能因端口未就绪导致第一次收包稍慢。解决办法很简单：
- 在
AcceptAsync成功后，立即对新 socket 调用一次空 buffer 的ReceiveAsync（不等回调返回），强制绑定 - 或改用
ThreadPool.UnsafeQueueUserWorkItem启动一个轻量初始化任务，提前触发绑定
这个细节在压测初期不容易暴露，但上线后偶发的首包延迟，往往就卡在这里。
