Grizzly RoundRobinConnectionDistributor 的变化

最新推荐文章于 2025-01-19 10:49:41 发布

原创最新推荐文章于 2025-01-19 10:49:41 发布 · 1.1k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#咨询

java 同时被 2 个专栏收录

57 篇文章

订阅专栏

grizzly

2 篇文章

订阅专栏

探讨Grizzly1.9与Grizzly2在SelectorRunner实现上的差异与优化策略，重点对比了接受与读写操作的区分处理及性能考量。

grizzly1.9:

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.