- 在任何 TCP Server 的实现中，一定存在一个 Accept Socket Loop，用于接收 Client 端的 Connect 请求以建立 TCP Connection。
- 在任何 TCP Server 的实现中，一定存在一个 Read Socket Loop，用于接收 Client 端 Write 过来的数据。
如果 Accept 循环阻塞，则会导致无法快速的建立连接，服务端 Pending Backlog 满，进而导致 Client 端收到 Connect Timeout 的异常。如果 Read 循环阻塞，则显然会导致无法及时收到 Client 端发过来的数据，进而导致 Client 端 Send Buffer 满，无法再发送数据。
从实现细节的角度看，能够导致服务阻塞的位置可能在：
- Accept 到新的 Socket，构建新的 Connection 需要分配各种资源，分配资源慢；
- Accept 到新的 Socket，没有及时触发下一次 Accept；
- Read 到新的 Buffer，判定 Payload 消息长度，判定过程长；
- Read 到新的 Buffer，发现 Payload 还没有收全，继续 Read，则 "可能" 会导致一次 Buffer Copy；
- Payload 接收完毕，进行 De-Serialization 转成可识别的 Protocol Message，反序列化慢；
- 由 Business Module 来处理相应的 Protocol Message，处理过程慢；
1-2 涉及到 Accept 过程和 Connection 的建立过程，3-4 涉及到 ReceiveBuffer 的处理过程，5-6 涉及到应用逻辑侧的实现。
Java 中著名的 Netty 网络库从 4.0 版本开始对于 Buffer 部分做了全新的尝试，采用了名叫 ByteBuf 的设计，实现 Buffer Zero Copy 以减少高并发条件下 Buffer 拷贝带来的性能损失和 GC 压力。DotNetty，Orleans ，Helios 等项目正在尝试在 C# 中进行类似的 ByteBuf 的实现。
1 单独测试不停的有新的client连接server时：
测试方法：写个client创建软件，调用timer，每隔几秒就创建一个新的client到server之间的连接，测试时打开多个client创建软件
异步编程模式leafsoft软件所写的服务器在上百万个可时连接状态，单单只有连接没有其他数据交互时，200万、300万都没问题的，300万以上时UI界面刷新就有些吃力，而连接数目到一定程度时，此时server阻塞，无法分配新的资源给接下来的client,相当于server停止监听，此时client软件和server软件都会有异常发生，异常位置在client连接server的方法内，异常如下：
