Server(Iocp)的那些烦恼
自G-Socket0.88版开源以来，得到很多朋友的支持。从1.0版本至2.0之前，内核几乎没有改变，经过多处的应用其稳定性和效率表现是相当不错的。这几年的经验总结成一句话：服务器程序不是有了一个好的Iocp通信组件就能玩转的。
很多情况下，我们都会遇到下面的问题：
1 致命的锁
又死锁了，怎样高效而又不死锁？是不是使用无锁算法就能解决？
2 无序的数据
为什么服务器接收的数据包会丢包？为什么客户端收到的数据乱序了？
3 野指针
别说多线程了，我都单线程了，为什么还有野指针？
4 低效的IO
为什么CPU使用率这么低，服务器怎么还这么卡？
5 恶劣的网络环境
为什么客户端都已经断线了，服务器端的客户链接数量不是0？
6 该死的客户端
我服务器都是IOCP了，怎么客户端接收的效率还这么低？
7 巨大数据积压
为什么通信模块有这么大的数据积压耗费这么多的内存？
8 莫名的异常
不能实时调式不能24小时监视，怎么分析这些服务程序异常？
下面解决问题的提示点，有些只有“资深”才能发现了：
1不是使用无锁算法就能解决死锁问题，而是良好的线程架构体系。
2 多线性并不是完全的多线程，它是针对多个连接而言，不是针对单个的连接对象，起码在粘包处理和数据发送这方面。
3 复杂的服务端程序有很多队列，必须要保证所有网络和用户请求等事件能被有序（按发生的事件先后顺序）被处理！
4 你是不是在逻辑线程里面直接IO操作了？
5 要有应用层面的心跳包，不要完全信任Socket底层的下的心跳机制。
6 你是不是在客户端使用了Window Message Mode的通信组件了，而且在消息事件里面解密处理数据了？
7 但凡是异步通信的都会有Copy和List，要么是接收快处理慢，要么是发送快客户端接收慢，或者客户连接的网络环境恶劣，导致数据队列积压，也就是生产和消费不平衡。
8 除了日志，还是日志，一个再牛X的程序员，也要写完善的日志体系。
