单线程UDP服务器未开多线程为何能同时处理多客户端？

你观察到的这个现象，本质是把TCP面向连接的处理模型套用到了UDP上——你的服务端根本没有做任何并发处理，只是刚好UDP的内核处理机制，让单线程顺序处理的过程看起来像在并行响应所有客户端。

核心机制拆解 #

• UDP无连接的特性，从根本上避免了TCP的连接阻塞问题
  很多人对单线程网络服务的印象来自TCP阻塞模型：单线程TCP服务端一旦和某个客户端建立连接，卡在读写流程上，就完全没法响应其他新连接。但UDP没有“连接”的概念，每个数据报是独立的寻址单元，客户端发完包就完成了整个交互流程，不需要和服务端维持长期绑定的会话状态，自然不会出现某个客户端把整个服务端堵死的情况。
• 操作系统内核会为每个UDP socket维护专属的入站请求队列
  当你通过datagramSocket = new DatagramSocket(port)把服务端socket绑定到3741端口时，内核会自动给这个socket分配一块环形缓冲区，用来存放所有发往这个端口的UDP数据报。不管包来自哪个客户端的哪个临时端口，只要目的端口和你绑定的端口匹配，内核就会自动把包追加到队列末尾——整个缓存、排队的过程完全不需要用户态的服务端线程参与。
• 你的服务端逻辑本质是严格的顺序处理
  你写的服务端循环流程非常简单：
  1. 调用datagramSocket.receive(packet)，从内核队列的队首取出一个已经缓存好的数据包
  2. 打印客户端的IP和端口信息
  3. 把收到的字节原样打包，发回给数据包来源的地址和端口
  4. 回到第一步，取下一个队列里的包
     整个流程没有任何并发逻辑，完全是按到达顺序挨个处理。你之所以产生“服务端同时处理了多个客户端”的错觉，是因为每个包的处理耗时极短——仅涉及用户态和内核态之间的内存拷贝，单包处理耗时通常在微秒级别，哪怕同时有上百个客户端的包被内核缓存，服务端也能在几毫秒内全部处理完，人根本感知不到顺序处理带来的微小延迟。
     另外你在客户端用多线程拆分发送和接收逻辑的设计，服务端是完全感知不到的——服务端看到的只是一个个独立寻址的UDP包，根本不会在意这些包是客户端的哪个线程发出来的。

这种“并发感”是有明确边界的 #

单线程UDP服务端看起来能同时响应多个客户端，只是低负载下的感知错觉，本质上和真的并发处理有核心区别：

• 如果服务端处理某个数据包的过程中出现阻塞（比如收到包之后强制等待10秒再回发），这10秒里所有其他客户端发过来的包，只会被内核暂存在接收队列里，等阻塞结束后再按到达顺序挨个处理，所有客户端都会感受到明显的延迟，完全不存在并行响应的效果。
• 当内核接收队列的缓存被占满时，新到达的UDP包会被内核直接丢弃，不会给用户态抛任何错误，这也是UDP不可靠传输的典型表现。

和单线程TCP服务端的核心差异 #

你可以对比下单线程阻塞TCP服务端的流程：服务端循环调用accept()等待新连接，一旦和某个客户端建立连接，就会卡在这个连接的读写逻辑上，其他新客户端的连接请求会一直堵在内核的连接队列里，直到当前连接的业务处理完才会被accept拿到，这时候你会非常直观地感受到“同一时间只能处理一个客户端”。而UDP因为没有连接建立的步骤，所有请求都被内核提前缓存到同一个队列里，单线程顺序处理的延迟感知就会弱很多。

内容的提问来源于stack exchange，提问作者duh ikal