之前几天说过，因为经典iocp实现（以下简称经典实现）多个io线程绑定在一个iocp上，这样内部管理了iocp队列的处理，内部决定是不是需要线程切换，我上次修改的一个版本（以下简称实现2），用了多个io线程，每个iocp队列仅绑定一个io线程，一组用户共享一个io线程，这和经典的多线程epoll模型的做法是很相似的，这样每个io线程是可以独立控制了，但理论上这种做法没有发挥iocp自动管理线程切换的优势，昨晚没事用这两种实现分别做了个echoserver测试了一下，这两套实现代码仅40行左右不同，其他完全一样，效果真的是差很多，测试仅用一个进程模拟了4000个客户端，每秒1个包，先看实现2的，cpu占14%，2个io线程，1个accept线程，1个主线程，其他线程都没干活闲置。

再看经典实现，cpu几乎一直是0%，2个io线程，accept也是在io线程里面处理，其他跟实现2一样，测试客户端也一样。

说实话，在测试之前我也没想到有这么大的差距，经典实现就是1.2w个连接连上来还是这样，就是内存占用多一点：

习惯上总有人喜欢拿epoll和iocp来对比，我到现在也没看到真正公平的对比，就算是相对公平的也没见到，因为在我看来，要对比硬件应该是一样的，os都应该是最新的，最重要的是，server端程序应该都是发挥了各自优势的，如果拿我这里的实现2去代表iocp的水平和epoll对比，势必造成比epoll差很多的结果，然而这显然是不正确的。

epoll经典多线程模式实际实现和实现2很相似，理论上也有类似的线程切换问题，不知道效率怎样。

之前设计了一套网络框架，持续改进了很多年，使用在很多项目上，综合效率还行，也很稳定，一直以来对这套东西信心满满，总以为啥问题都好解决，但最近就有个需求让我选择还是改了下这个框架。

之前的框架是这样的，可以开一组N个io线程，可以开一组N个同步线程（默认1个），可以开一组N个异步线程（默认1个），可以开一组N个timer线程（默认1个），可以开一组N个异步线程（默认cpu个），每组可独立受控，每组可支持自定义消息，可支持timer，一组N个如果N大于1则无法直接给这组里面的特定线程发消息，只能给一组发消息，这个组里面会选择某个合适的线程处理这个消息，这也是iocp高效和典型的用法了，但这也正是问题的结症所在。

Linux下的多线程服务器更常见的做法跟这个不大相似，一般都是将某些socket分配到某些线程epoll，分好之后就是固定的，不再变化，跟Iocp将socket绑定到一组线程的做法不同，由于某个socket直接绑定到了某个线程，所以有些问题就变得简单了，如同一个连接的在同一个线程内消息进行了同步，要跟io线程绑定私有化数据也简单了，而且每个线程可独立受控，所以很容易实现一组io各自挂tls（线程局部存储）数据，而我现在做的这套框架就是这方面不好控了，其实也很难说这两种意义上的框架到底谁更优，如用在web型应用上这种socket被一组io线程管理的模式很方便效率也高，但我现在的需求需要某个socket使用线程相关数据，以避免数据之间的锁，我用内存换时间，由于在原来的框架上增逻辑难以实现可直接控制io线程的框架的，所以花了一个晚上重新改写了一套框架，在原来iocpframe的基础上派生了一组带2名称的类，除替换类名之外只修改了几十行代码就做好了，总的来说花的时间还是比较少的。修改后io线程一组，但独立受控，外部可对这组线程中的某一个直接发消息，基本满足了需求，现在要给每个io线程绑定私有数据并触发特定消息比之前简单多了，而且绝对无锁。