三种开源网络框架比较

mina selector模型：
1.在Mina 2.0中，Selector的管理是由org.apache.mina.transport.socket.nio.NioProcessor来处理，每个NioProcessor对象保存一个Selector，负责具体的select、wakeup、channel的注册和取消、读写事件的注册和判断、实际的IO读写操作等等
2.
SimpleIoProcessorPool默认是cpu+1的  大小；这样一来，每个连接都关联一个NioProcessor，也就是关联一个Selector对象，避免了所有连接共用一个Selector负载过高导致 server响应变慢的后果。

3.但是注意到NioSocketAcceptor也有一个Selector，这个Selector用来干什么的呢？那就是集中处理OP_ACCEPT事件的Selector，主要用于连接的接入，不跟处理读写事件的Selector混在一起，因此Mina的默认open的 Selector是cpu+2个。

4.由此看出，mina2仍然是reactor多线程模型；

netty5.0 selector模型：
1. 每个NioEventLoop拥有一个selector对象；
2. ServerBootstrap b = new ServerBootstrap();
b.group(bossGroup, workerGroup); 服务端启动的时候创建了2个NioEventLoopGroup，他们实际上是2个独立的Reactor线程池；一个用于接收客户端的TCP连接建立和关闭；另一个用于IO相关的读写操作，或者执行系统task,定时任务task;
3.由此可以看出netty是  主从线程池模型；


Grizzly:
Grizzly还是比较保守，它默认就是启动两个Selector，其中一个专门负责accept，另一个负责连接的IO读写事件的管理


1、在处理大量连接的情况下，多个Selector比单个Selector好
2、多个Selector的情况下，处理OP_READ和OP_WRITE的Selector要与处理OP_ACCEPT的Selector分离，也就是说处理接入应该要一个单独的Selector对象来处理，避免IO读写事件影响接入速度。
3、Selector的数目问题，mina默认是cpu+2，而grizzly总共就2个，我更倾向于mina的策略，但是我认为应该对cpu个数做一个判断，如果CPU个数超过8个，那么更多的Selector线程可能带来比较大的线程切换的开销，mina默认的策略并非合适，幸好可以通过API设置这个数值。


4.netty学习
  ChannelFuture f = b.bind(PORT).sync();
1.bind中执行了  获取一个ServerSocketChannel  并将其注册到EventLoop中的Seclector中取；
2.将ServerSocketChannel  绑定到指定的IP和端口
EventLoopGroup bossGroup = new NioEventLoopGroup()发生了以下事情：
      1、 为NioEventLoopGroup创建数量为：处理器个数 x 2的，类型为NioEventLoop的实例。每个NioEventLoop实例 都持有一个线程，以及一个类型为LinkedBlockingQueue的任务队列
      2、线程的执行逻辑由NioEventLoop实现
      3、每个NioEventLoop实例都持有一个selector，并对selector进行优化
doug lea个人网站：
http://gee.cs.oswego.edu/dl/