作者回复: 是多余的，你理解的非常到位，确实可以这么简单对应起来，就是按端口来对应，就因为多余，所以可以直接上来就显式设置为1，不过多余坏处不大，因为其他的不启动多余的线程。

作者回复: 关键点不是性能提升问题，因为做事情的人的总数没变，只是从无分工变成了有分工，假设不独立出单独接受连接的话，等于所有的事都是一样优先级的，那在繁忙的时候，接受连接的处理可能就会延迟很久，导致连接超时，很明显连接比一次业务处理更重要，所以才把最重要的事独立处理，所以举例说大饭店都是有迎宾的。另外，反过来说，目标不是性能提升，因为分工了。只是说问题少了。

作者回复: 这个当时课程设计的时候，稍微底层点的东西我都过滤了，因为怕跑题太远，这个问题我记录下来了，回头我做问题汇总小册子的时候，把这个问题总结出来发您。

作者回复: 那个参数是1还是多少是控制是否多线程，而是否分2组是区别是否采用主从，你这样的话，还是主从，只不过是主是单线程，从是多线程。非主从只有一个group。

作者回复: NIO也不需要“自己”去扫描事件啊，AIO的优点在于，不需要自己去读数据了，NIO还要自己去读，但是这两个都是事件驱动的，在linux下实现也都是epoll。

作者回复: 是的

作者回复: 不是太看懂您的表达，反正上来用主从就对了。

作者回复: Reactor应该不是Doug Lea首创，只是我们都看了他的那个经典的《scalable io in java》，所以觉得好像他首创，另外，查了很久，也没有找到到底是谁第一次提出的，但是可以追溯到90年代是肯定的，比如： Reactor - an Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Synchronous events; Douglas C Schmidt; 1995 Proactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events, Irfan Pyarali, Tim Harrison, Douglas C. Schmidt, Thomas D. Jordan, 1997

作者回复: 前面您都说的挺好的，后面为什么会有疑问呢？感觉你自我解释了，做的事情不同，有分工了，连接请求专门的nio event loop处理，数据读写又有不同的nio event loop处理，否则假设放一起，一个或者大多数据特别大，导致错过或者说很久没有接受连接怎么办？核心还是分工思想

作者回复: netty还是很全面的，除用cpu计算默认的线程数，还有其他两个参数，分别考虑了docker等因素，后面会提到。