我知道有许多开源服务器程序可以利用java.nio的非阻塞I / O，例如Mina。许多实现使用多个选择器和多线程来处理选定的事件。这似乎是一个完美的设计。
是吗？基于NIO的服务器的瓶颈是什么？似乎不会有任何？是否需要控制连接数？怎么会这样做？
答案 0 :(得分：3)
使用传统的阻塞I / O，每个连接必须由一个或多个专用线程处理。随着连接数量的增加，所需线程的数量也会增加。这个模型在连接数量达到数百或数千的情况下工作得相当好，但它不能很好地扩展。
多路复用和非阻塞I / O反转模型，允许一个线程为许多不同的连接提供服务。它是通过选择活动连接并在保证套接字准备就绪时仅执行I / O来实现的。
这是一个更具可扩展性的解决方案，因为现在你没有成群的大多数非活动线程坐在他们的拇指周围。相反，你有一个或几个非常活跃的线程在所有套接字之间穿梭。那么这里的瓶颈是什么？
基于NIO的服务器仍受其CPU限制。随着套接字数量和I / O数量的增加，CPU将越来越繁忙。
多路复用线程需要尽快为套接字提供服务。他们一次只能使用一个。如果服务器不小心，可能会在这些线程中进行太多工作。当发生这种情况时，可能需要一些小心的，也许是困难的编程来将工作移出线程。
如果无法立即处理传入数据，则可能需要将其复制到单独的内存缓冲区，以使其不在操作系统的队列中。复制需要时间和额外的内存。
程序不能打开无限数量的文件描述符/内核句柄。每个套接字都在操作系统中有相关的读写缓冲区，因此最终会遇到操作系统的限制。
显然，您仍然受到硬件和网络基础设施的限制。服务器受其NIC，其他网络跃点的带宽和延迟等限制
这是一个非常通用的答案。要真正回答这个问题，您需要检查有问题的特定服务器程序。每个节目都不同。任何特定程序中都可能存在瓶颈，这些瓶颈不是Java NIO的“错误”，可以这么说。
答案 1 :(得分：1)
基于NIO的服务器的瓶颈是什么？
网络，内存，CPU，所有常见的东西。
好像不会有任何一种？
为什么？
是否需要控制连接数？
不是。
怎么会这样做？
将它们计入进出，并在您最多的时候取消注册OP_ACCEPT。