Java DatagramChannel 怎样设置非阻塞接收

Java DatagramChannel 设置非阻塞接收的关键是调用 configureBlocking(false)，并把 receive 返回 null 当作“当前没有数据报”，不是连接断开。需要等待数据时可注册 Selector 的 OP_READ，避免反复空调用。Selector 可以等待，通道上的 receive 却仍保持非阻塞；这两件事并不矛盾。

本文以 JDK 25 文档为准，只讨论配置与接收，不讨论发送可靠性或完整 UDP 协议。官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/channels/DatagramChannel.html。

不想等待数据，为什么不能只删掉循环里的等待

如果我要把一个回环地址的 UDP 接收小程序改成事件循环，首先会区分两种等待：阻塞通道在 receive 里等待包，非阻塞通道让 receive 在没有包时返回 null。我更倾向于把等待集中交给 Selector，让同一线程还能安排其他工作。这是有条件的代码选择，不是本文在生产环境跑出的性能结论。

只删掉 sleep 或把 receive 放进更紧的 while 循环，不会改变通道模式。反过来，设成非阻塞后不停调用 receive，也只是忙轮询，不代表程序更有效率。这篇讲的是调用契约，不是某次 Java 发布引入的新规则。

三个对象分工：通道、选择器与注册键

DatagramChannel 表示数据报通道，configureBlocking(false) 决定它的非阻塞模式；Selector 维护注册关系；SelectionKey 保存通道与 Selector 的关联，OP_READ 是希望关注的读就绪类别。先改为非阻塞再注册，不能把仍阻塞的通道直接注册进去。

我会显式 bind 一个测试地址，再配置模式、注册读事件。receive 不要求先 connect；不要因为 TCP 的经验而把 UDP connect 当成接收前提。此处只保留一个接收线程和一个缓冲区，避免多线程读取使就绪提示更难推断。

有限时长示例，先把 receive 的契约写对

示例可保存为 UdpReceiveDemo.java，在 JDK 25 环境使用。它只绑定 IPv4 回环与临时端口，约十秒后退出，不发送数据、不启动永久服务。运行者可以在自己的测试环境向打印的地址发送小数据报；本文没有运行示例，也不预设一定收到数据。

import java.net.InetSocketAddress;
import java.net.SocketAddress;
import java.net.StandardProtocolFamily;
import java.nio.ByteBuffer;
import java.nio.channels.DatagramChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.util.concurrent.TimeUnit;

public class UdpReceiveDemo {
    public static void main(String[] args) throws Exception {
        // 只监听回环地址，端口由系统分配；不暴露公网服务。
        try (Selector selector = Selector.open();
             DatagramChannel channel = DatagramChannel.open(StandardProtocolFamily.INET)) {
            channel.bind(new InetSocketAddress("127.0.0.1", 0));
            channel.configureBlocking(false);
            channel.register(selector, SelectionKey.OP_READ);
            System.out.println("测试监听地址：" + channel.getLocalAddress());
            ByteBuffer buffer = ByteBuffer.allocate(2048);
            long started = System.nanoTime();

            // 示例约十秒结束；生产代码应使用明确的停止协议。
            while (System.nanoTime() - started 

这段代码让我在阅读时最在意的有两处：selectedKeys 的迭代器移除已处理的键；receive 的 sender 为 null 时退出本轮接收。前者是消费就绪集合里的通知，不会取消注册；后者是无数据时回到 select，而不是把 null 当作可解引用的地址。

isReadable 是就绪提示，并不是一定能拿到一个包的保证。就绪状态可能被 I/O 或其他事件改变，所以即使已检查可读，仍需处理 receive 返回 null。这也是我保留非阻塞配置的原因：事件通知与实际接收各自遵循契约。

空包、无包和截断不是同一种情况

ByteBuffer 的 position、limit 与剩余容量决定接收能写入多少字节。每次 receive 前 clear，让缓冲区可写；成功返回来源地址后 flip，让已接收区域可读。没有来源地址时不要把旧数据重新当成新包。

null 表示当前没有包；非 null 来源加零字节可以表示空数据报。这与 TCP 的流式结束判断不同。buffer.remaining 为零也不应被写成 UDP 对端已经关闭。示例只打印来源和长度，避免把未知二进制协议直接当 UTF-8。

缓冲区不足会让数据报剩余部分被丢弃，不是下次 receive 再补齐同一个包。示例的 2048 字节只是演示容量，不是所有 UDP 协议的安全上限。收到恰好 2048 字节也不能单凭长度判断是否截断；真实协议要定义最大数据报长度与完整性字段。

非阻塞是取舍，不是通用升级按钮

若只需要一个线程等待一个 UDP 端口，阻塞 receive 可能更简单；需要统一调度多个通道时，Selector 更贴合目标，但多出注册、就绪集合和停止条件的维护责任。我不会把它描述成必然更快，也不会承诺 UDP 因此具备可靠传输。

示例每轮最多处理 32 个包，是防止持续输入占满本轮的演示预算，不是调优推荐值。实际服务应结合处理耗时和其他通道负载确定预算，并在把数据交给异步处理者前复制或转移缓冲区所有权；不要把会被下一次 clear 的同一缓冲区当作长期消息对象。

没有 connect 可以 receive 吗？

可以。receive 能返回来源地址，本文示例没有 connect。

configureBlocking(false) 后 select 还能等待吗？

可以。通道模式与选择器等待方式分别控制不同调用。

读就绪后 receive 返回 null 是异常吗？

不应仅凭这一点判定异常。就绪是提示，实际接收仍要遵守 null 的契约。

选择器与键的官方说明：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/channels/Selector.html；https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/channels/SelectionKey.html。对我来说，先把无包、空包和数据边界写清，再考虑事件循环规模，才是这项配置真正值得采用的前提。