grizzly1.9:
不再区分accept/read/write 的SelectRunner.
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];
}
一个SelectorRunner 负责accept,其他负责read/write
grizzly2后
private SelectorRunner getSelectorRunner() {
final SelectorRunner[] runners = getTransportSelectorRunners();
final int index = counter.getAndIncrement() % runners.length;
return runners[index];
}
不再区分accept/read/write 的SelectRunner.
咨询了作者,主要的架构权衡的问题,如果是系统的连接不多,如果区分accept和read/write,accept的 SelectRunner就会空闲,无事可做,而read/write 的SelectRunner很忙。如果连接很多,可以考虑类似1.9的实现,区分accept和read/write的 SelectRunnerSelectRunner