NIO 和 TCP 非常适合用于许多连接。由于需要为每个新客户端打开一个新连接，因此每个客户端通常都需要自己的线程来阻塞 I/O 操作。 NIO 通过允许数据在可能的时候被读取而不是阻塞直到数据可用来解决这个问题。但是 UDP 呢？
我的意思是，由于协议(protocol)的设计方式(发送它并忘记它，基本上)，无连接 UDP 不具有与其相关的 TCP 的阻塞性质。如果我决定将一些数据发送到某个地址，那么它将这样做，没有延迟(在服务器端)。同样，如果我想读取数据，我可以只接收来自不同来源的单个数据包。我不需要使用多个线程与许多地方建立许多连接来处理它们中的每一个。
那么，NIO和选择器是如何增强UDP的呢？更具体地说，什么时候人们更愿意将 UDP 与 NIO 一起使用而不是旧的 java.net 包？
最佳答案
好吧，DatagramSocket.receive(...) 方法被记录为一个阻塞 操作。因此，例如，如果您有一个线程试图处理来自 N 个不同套接字的数据包，您将需要使用 NIO 和选择器。类似地，如果线程必须多路复用检查新数据包和其他 Activity ，您可以这样做。
如果您没有这些或类似的要求，那么选择器将无济于事。但这与 TCP 情况没有什么不同。如果不需要，则不应将选择器与 TCP 一起使用，因为它可能会添加额外的系统调用。
(在 Linux 上，在数据报的情况下，您将执行 select 系统调用，然后执行 recv ... 而不仅仅是 recv.)
But if you're only dealing with one DatagramSocket, wouldn't the receive method read packets immediately as they arrive, regardless of the fact that they're from a different computer?
如果您正在一个套接字上监听来自“每个人”的数据报，那么是的。如果不同的计算机有不同的 socket ，那就不行。
And for the TCP comment, sometimes the use of a selector is justified simply by the fact that it is very resource demanding to have thousands of threads, as it would be required by a blocking TCP server.
我们没有讨论那个案例。但是，是的，这是真的。如果您有数千个线程阻塞 UDP 接收，情况也是如此。
我的观点是，如果您没有有很多线程，或者如果线程阻塞无关紧要，那么 NIO 就无济于事。事实上，它可能会降低性能。
关于java - 将 UDP 与 NIO 一起使用有什么意义？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16048284/