nio框架中的多个Selector结构

核心提示： publicFuture<RegisterChannelResult>registerChannelAsync(SelectableChannelchannel,intinterestOps,Objectattachment,CompletionHandlercompletionHa

　public　Future<RegisterChannelResult>　registerChannelAsync(
　　　　　　　　　　　　SelectableChannel　channel,　int　interestOps,　Object　attachment,
　　　　　　　　　　　　CompletionHandler　completionHandler)　
　　　　　　　　　　　　throws　IOException　{
　　　　　　　　SelectorRunner　runner　=　getSelectorRunner(interestOps);
　　　　　　　　
　　　　　　　　return　transport.getSelectorHandler().registerChannelAsync(
　　　　　　　　　　　　　　　　runner,　channel,　interestOps,　attachment,　completionHandler);
　　　　}
　　　　
　　　　private　SelectorRunner　getSelectorRunner(int　interestOps)　{
　　　　　　　　SelectorRunner[]　runners　=　getTransportSelectorRunners();
　　　　　　　　int　index;
　　　　　　　　if　(interestOps　==　SelectionKey.OP_ACCEPT　||　runners.length　==　1)　{
　　　　　　　　　　　　index　=　0;
　　　　　　　　}　else　{
　　　　　　　　　　　　index　=　(counter.incrementAndGet()　%　(runners.length　-　1))　+　1;
　　　　　　　　}
　　　　　　　　
　　　　　　　　return　runners[index];
　　　　}

getSelectorRunner这个方法道出了秘密，如果是OP_ACCEPT，那么都使用数组中的第一个SelectorRunner，如果不是，那么就通过取模运算的结果+1从后面的SelectorRunner中取一个来注册。

分析完mina2.0和grizzly2.0对Selector的管理后我们可以得到几个启示：

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默认的策略并非合适，幸好可以设置这个数值。