DatagramSocket是JDK原生UDP最小可用单元，轻量低延迟，但线程不安全；需防端口占用、缓冲区溢出、编码不一致；connect()仅作地址过滤；高并发应选DatagramChannel或Netty。
Java UDP通信为什么首选 DatagramSocket？
因为它是 JDK 原生支持 UDP 的最小可用单元，不依赖第三方库，适合轻量、低延迟场景（如心跳包、DNS 查询、局域网设备发现）。它不维护连接状态，也不保证送达，但开销极小——创建快、发送快、GC 压力小。
注意：DatagramSocket 是线程不安全的；多个线程共用一个实例时，send() 和 receive() 可能互相干扰，甚至抛出 IOException: Socket closed，哪怕你没主动 close。
- 单线程收发最稳妥；多线程建议每个线程独占一个
DatagramSocket - 绑定端口失败常见原因是端口被占用或权限不足（Linux 下 1024 以下端口需 root）
-
setSoTimeout(5000)必须在receive()前调用，否则阻塞永不超时
如何避免 DatagramPacket 缓冲区溢出和乱码？
DatagramPacket 的字节数组容量是硬限制：超出部分直接截断，不会报错。接收方看到的是“被砍掉尾巴”的数据，而发送方毫无感知。
典型错误是用 new byte[1024] 接收，但对方发了 2048 字节 UDP 包——后半截永远丢弃。UDP 协议本身不限制包长，但 IPv4 实际 MTU 通常为 1500 字节，超过会分片，而分片丢失一个就整包失效。
立即学习“Java免费学习笔记（深入）”；
- 推荐接收缓冲区设为
new byte[65536]（UDP 最大理论载荷），足够覆盖绝大多数场景 - 务必用
packet.getLength()读取实际收到字节数，而不是packet.getData().length - 字符串编解码统一用
StandardCharsets.UTF_8，避免平台默认编码差异（如 Windows 的 GBK）
byte[] buf = new byte[65536]; DatagramPacket packet = new DatagramPacket(buf, buf.length); socket.receive(packet); String msg = new String(packet.getData(), 0, packet.getLength(), StandardCharsets.UTF_8);
为什么 DatagramSocket 不支持连接状态但还能调用 connect()？
connect(InetAddress, int) 并不建立真实连接，只是设置地址过滤器：此后该 socket 只收发指定 IP+端口的数据，其他来源的包会被内核静默丢弃，receive() 不会返回；向非连接目标 send() 会直接抛 IllegalStateException。
这个机制本质是简化编程模型，省去每次 send 都要传 DatagramPacket 目标地址的麻烦，也提升一点安全性（防伪造源地址包）。
- 调用
connect()后，DatagramPacket构造时可只传data和length，无需指定地址和端口 - 已 connect 的 socket 仍可通过
disconnect()解除绑定 - 同一个 socket 不能多次
connect()到不同地址——会抛IllegalArgumentException
Netty 或 java.nio.channels.DatagramChannel 比 DatagramSocket 强在哪？
原生 DatagramSocket 是阻塞 I/O，一个线程只能干一件事。高并发 UDP 服务（比如万级终端上报）用它就得开一堆线程，CPU 和内存吃紧。
DatagramChannel 支持非阻塞模式 + Selector 多路复用，一个线程管成百上千个 UDP 端口；Netty 在其之上封装了事件驱动、内存池、编解码器等，更适合生产级部署。
- 若只需单点 P2P 或定时广播，
DatagramSocket足够，代码行数少、调试直观 - 若需处理海量无状态请求（如 IoT 网关）、要求吞吐/稳定性/可观测性，直接上 Netty 的
DatagramChannel实现 - 注意：
DatagramChannel必须用configureBlocking(false)，且bind()后需注册到Selector才能 work
UDP 的无连接特性让很多开发者低估了边界问题：包序错乱、重复、丢失全得自己兜底。选类库不是比功能多寡，而是看谁把“怎么兜底”这件事藏得更稳、暴露得更少。
