Java原生Socket实战：TCP与UDP三种传输模式深度解析-平芜编程栈

1. 项目概述：为什么TCP和UDP不是“二选一”，而是“各守一岗”

刚接触Java网络编程的人，常把Socket和ServerSocket当成“客户端连服务器”的万能钥匙，再顺手加个DatagramSocket就以为吃透了网络通信——结果写完发现：发出去的消息对方收不到、服务端卡死不响应、多线程一上就乱序、丢包了还查不出在哪丢的。我带过不少刚学完IO流就急着写聊天程序的开发者，他们踩的第一个坑，几乎都出在没真正理解TCP和UDP在Java层面的行为边界上。

这个标题里说的“三种数据传输方式”，其实不是指“TCP一种+UDP两种”，而是UDP通信中实际落地的三类典型模式：单包直传（最基础）、请求-应答式交互（如DNS查询模拟）、以及带简易重传机制的可靠化封装（非TCP，但比裸UDP稳）。很多人误以为UDP只能“发了就不管”，其实只要控制好包大小、超时逻辑和应用层确认，它在局域网文件分片、实时音视频心跳、设备状态上报等场景里，比TCP更轻、更快、更可控。

关键词“TCP通信”“UDP通信”“Socket”“ServerSocket”“数据传输方式”背后，真正要解决的是三个现实问题：
第一，连接建立与释放的成本感知——你写的那个while(true) accept()循环，真能扛住500个并发连接吗？线程池怎么配？连接空闲多久该断开？
第二，数据边界意识缺失——TCP是字节流，没有天然消息头；你send("hello") + send("world")，对方recv()一次可能拿到"helloworld"，也可能分两次拿，也可能一次拿"hell"下一次拿"oworld"；而UDP每个DatagramPacket就是一条完整消息，但超过65507字节直接被内核截断；
第三，错误归因混乱——客户端连不上，到底是防火墙挡了，还是ServerSocket绑定的端口被占用，还是bind时用了127.0.0.1导致外网无法访问？日志里只打印“Connection refused”，根本没法定位。

这篇文章不是讲API怎么调用，而是还原一个真实项目从设计到上线过程中，我和团队在某嵌入式设备远程监控系统里，如何基于Java原生Socket体系，把TCP长连接管理、UDP广播发现、以及UDP可靠传输这三块拼图严丝合缝地搭起来。所有代码、参数、线程模型、异常处理策略，都来自实测压测后的稳定方案，不是教科书里的理想路径。

适合谁看？

写过HelloWorld Socket但一上线就崩的初级开发者；
正在做物联网设备接入、局域网协同工具、或轻量级RPC框架的中级工程师；
需要给学生讲清“为什么不用Netty也要懂原生Socket”的高校导师；
或者只是想搞明白“微信发文字走TCP，语音通话却用UDP”底层逻辑的技术爱好者。

接下来的内容，全部围绕Java SE原生API展开，不依赖任何第三方框架，所有代码可直接编译运行，所有参数都有实测依据，所有坑我都替你踩过了。

2. 核心设计思路拆解：为什么必须区分“连接型”与“报文型”通信模型

2.1 TCP通信的本质：不是“管道”，而是“状态机驱动的双向字节流通道”

很多教程说“TCP是面向连接的”，但没说清楚：这个“连接”在Java层面到底是什么？它既不是内存里一个对象，也不是操作系统里一个固定资源，而是一组由内核维护、JVM通过Socket API间接操作的状态集合。ServerSocket.bind()成功，只代表内核答应帮你监听某个端口；accept()返回一个Socket实例，才是真正从内核队列里取出一个已完成三次握手的连接描述符，并在JVM侧创建对应句柄。

这就决定了TCP通信的设计起点必须是状态生命周期管理。我们曾在一个设备管理后台中，让ServerSocket监听9090端口，初期用单线程accept+阻塞read，结果当第37台设备同时上线时，整个服务卡死——因为read()阻塞在某台设备的半关闭连接上，后续所有accept都被堵住。后来改成：

ServerSocket设置setSoTimeout(5000)，避免accept无限等待；
每个accept到的Socket，立即交给固定大小的线程池（核心线程数=CPU核心数×2，最大线程数=50）；
每个处理线程内，Socket设置setSoTimeout(30000)，读取超时后主动close()；
关键：在finally块里显式调用socket.close()，而不是依赖GC——因为Socket底层关联着文件描述符，JVM不保证及时回收。

提示：不要迷信“try-with-resources自动关闭”。在高并发场景下，如果read()阻塞在内核态，try块根本执行不完，资源就泄漏了。必须在超时捕获后强制close()，并记录warn日志。

2.2 UDP通信的真相：不是“不可靠”，而是“不承诺交付，但可自主定义可靠性”

UDP常被贴上“不可靠”标签，这是对协议职责的误解。UDP的职责非常清晰：把应用层给的数据报，尽最大努力投递到目标IP+端口，不保证顺序、不保证到达、不重传。但它从不阻止你在应用层加控制逻辑。我们做的设备发现服务，就基于UDP实现了“准可靠”广播：

客户端每2秒发送一个含时间戳、设备ID、校验码的UDP包到255.255.255.255:8888；
服务端收到后，不立即回复，而是将请求存入内存队列（ConcurrentLinkedQueue），由独立线程每100ms批量处理；
回复包里携带原始请求的时间戳，客户端收到后计算RTT，若RTT>500ms则认为网络差，降频发送；
连续3次未收到回复，才触发TCP备用通道发起注册。

这种设计下，UDP承担了“轻量探测”角色，TCP只在关键注册环节兜底，整体资源消耗比全程TCP低60%以上。而所谓“三种数据传输方式”，正是对应这三种控制粒度：

单包直传：无状态、无反馈，适用于传感器周期性上报（如温湿度每30秒发一次）；
请求-应答式：有简单ACK，但无重传，适用于DNS风格查询（如“请告诉我网关IP”→“网关IP是192.168.1.1”）；
应用层可靠化：带序列号、超时重传、滑动窗口（极简版），适用于小文件分片传输（如固件升级包拆成1KB分片，按序接收并校验）。

2.3 为什么绝不混用TCP Socket和UDP DatagramSocket来实现同一业务逻辑？

曾有同事提议：“既然TCP太重，UDP又怕丢包，不如用TCP传控制指令，UDP传数据流？”——这看似合理，实则埋下巨大隐患。我们在测试中发现：当网络抖动时，TCP指令可能延迟到达，而UDP数据包已先到，服务端因未收到指令而丢弃数据；反之，指令到了但数据包丢失，客户端又无法判断是数据没发还是服务端没处理。最终统一为：同一业务会话，只用一种传输层协议。控制信令和业务数据要么全走TCP（如SSH），要么全走UDP可靠化封装（如QUIC早期实验），绝不交叉。

这个原则直接决定了整个通信模块的架构分层：

最底层：NetworkTransport接口，有两个实现类TcpTransport和UdpTransport；
中间层：SessionManager，根据业务类型（device_register / firmware_update / heartbeat）决定实例化哪种Transport；
上层：ApplicationProtocol，只跟SessionManager交互，完全不知道底层是TCP还是UDP。

这样，当某天需要把UDP可靠化模块替换成KCP（一种用户态快速重传协议）时，只需新增KcpTransport实现，其他层零修改。

3. 核心细节解析与实操要点：从代码行到生产环境的每一处陷阱

3.1 TCP ServerSocket的初始化：bind()前必须想清楚的四件事

ServerSocket构造方法看似简单：new ServerSocket(port)，但背后藏着四个必须决策的关键点，漏掉任何一个都会导致上线后故障。

第一，端口号选择。
不能硬编码8080或9090。我们规定：

开发环境用8080+项目编号（如设备管理项目用8081）；
测试环境用9000~9999区间，由CI脚本动态分配（避免多个服务冲突）；
生产环境必须配置化，且启动前校验端口是否被占用（用netstat -an | grep :${port}或Java的new ServerSocket(port).close()试探）。

第二，backlog参数的意义。
new ServerSocket(port, backlog)中的backlog，不是“最多接受多少连接”，而是内核已完成三次握手但JVM还没调用accept()取走的连接队列长度。Linux默认是50，但高并发时这个队列会满，新连接直接被RST拒绝。我们实测：当QPS>200时，backlog设为128才能避免连接拒绝。计算公式：

backlog = 平均每秒新建连接数 × 平均accept处理耗时（秒） × 2

例如：每秒新建100连接，每个accept后创建线程+初始化平均耗时10ms，则backlog ≥ 100 × 0.01 × 2 = 2。

第三，地址绑定范围。
new ServerSocket(port)默认绑定0.0.0.0，即所有网卡；但若只想内网访问，必须指定new ServerSocket(port, backlog, InetAddress.getByName("192.168.1.100"))。曾有个安全审计发现，某服务因绑定0.0.0.0，导致数据库管理端口意外暴露在公网——根源就是ServerSocket没指定InetAddress。

第四，setReuseAddress(true)的必要性。
TCP连接关闭后会进入TIME_WAIT状态（默认2MSL=4分钟），此时端口不可重用。若服务频繁重启，就会报“Address already in use”。调用serverSocket.setReuseAddress(true)后，内核允许新Socket重用处于TIME_WAIT的端口。注意：此设置必须在bind()前调用，否则无效。

ServerSocket serverSocket = new ServerSocket(); serverSocket.setReuseAddress(true); // 必须在bind前！ serverSocket.bind(new InetSocketAddress("192.168.1.100", 9090), 128);

3.2 TCP Socket的读写陷阱：为什么BufferedReader.readLine()在生产环境是定时炸弹

几乎所有入门教程都用BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream()))配合readLine()读取，这在演示时很优雅，但在生产环境极其危险。

问题根源有三：

readLine()以\n、\r\n或\r为结束符，但网络协议往往用自定义分隔符（如|或0x00），或用定长头+变长体（前4字节是长度，后N字节是内容）；
BufferedReader内部缓冲区默认8KB，若对方发送超大文本（如日志dump），缓冲区溢出会导致OutOfMemoryError；
readLine()是阻塞调用，且不支持超时——一旦对方不发换行符，线程永久挂起。

我们的解决方案是彻底抛弃readLine()，改用带长度校验的字节流读取：

// 定义消息格式：4字节长度 + N字节内容 DataInputStream dis = new DataInputStream(socket.getInputStream()); int length = dis.readInt(); // 阻塞读取4字节整数 if (length > 1024 * 1024) { // 长度超1MB，视为恶意包 throw new IOException("Message too large: " + length); } byte[] data = new byte[length]; int totalRead = 0; while (totalRead < length) { int read = dis.read(data, totalRead, length - totalRead); if (read == -1) break; totalRead += read; } String message = new String(data, StandardCharsets.UTF_8);

注意：dis.read()可能返回0，表示暂时无数据，但连接未断；返回-1才表示流结束。所以必须用while循环确保读满length字节。

3.3 UDP DatagramSocket的三大生死线：广播、接收缓冲区、线程安全

DatagramSocket比ServerSocket更“脆弱”，三条规则必须刻进DNA：

第一，广播权限不是默认开启的。
socket.setBroadcast(true)必须显式调用，否则send()到255.255.255.255会被静默丢弃。而且，Linux下还需确保网卡开启了broadcast flag（ifconfig eth0 | grep BROADCAST），Windows则需管理员权限。

第二，接收缓冲区大小直接影响丢包率。
socket.setReceiveBufferSize(64 * 1024)默认只有8KB，当UDP包洪泛时（如100台设备同时发心跳），内核接收队列溢出就会丢包。我们实测：将缓冲区设为64KB后，万级包洪泛下的丢包率从12%降至0.3%。注意：此值不能无限增大，Linux有net.core.rmem_max上限，需同步调整系统参数。

第三，DatagramSocket本身线程不安全，但DatagramPacket是线程安全的。
可以复用同一个DatagramSocket实例供多线程send()，但每个线程必须用独立的DatagramPacket对象。曾因共用packet对象，导致A线程刚setAddress，B线程就覆盖了，结果包发到了错误地址。

// ✅ 正确：每个线程new自己的packet DatagramPacket packet = new DatagramPacket(buffer, 0, buffer.length, address, port); // ❌ 错误：全局static packet，多线程并发修改 private static final DatagramPacket SHARED_PACKET = ...;

3.4 UDP“可靠化”的最小可行实现：序列号+超时重传的朴素智慧

不引入复杂协议，仅用Java原生API，就能让UDP接近TCP的可靠性。我们设备固件升级模块就用此方案，成功率99.99%，比纯TCP快40%。

核心思想只有三点：

每个UDP包带2字节序列号（0~65535循环）；
发送方维护一个待确认队列（ConcurrentHashMap<Short, SendTask>），SendTask包含packet、重传次数、下次重传时间；
接收方收到包后，立即回一个ACK包（仅含序列号），发送方收到ACK则从队列移除；超时未收到则重发，最多3次。

关键代码片段：

// 发送方：添加到重传队列 short seq = currentSeq++; SendTask task = new SendTask(packet, System.currentTimeMillis(), 0); retryMap.put(seq, task); // 后台线程：扫描重传队列 ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(() -> { long now = System.currentTimeMillis(); Iterator<Map.Entry<Short, SendTask>> it = retryMap.entrySet().iterator(); while (it.hasNext()) { Map.Entry<Short, SendTask> entry = it.next(); SendTask task = entry.getValue(); if (now - task.sendTime > 2000) { // 超时2秒 if (task.retryCount < 3) { socket.send(task.packet); // 重发 task.sendTime = now; task.retryCount++; } else { it.remove(); // 放弃 log.warn("Packet {} failed after 3 retries", entry.getKey()); } } } }, 0, 100, TimeUnit.MILLISECONDS);

实操心得：重传间隔不能固定。首次200ms，二次500ms，三次1500ms，呈指数退避。否则网络拥塞时，所有客户端同时重发，形成风暴。

4. 实操过程与核心环节实现：从零搭建一个可验证的通信系统

4.1 环境准备与依赖：纯Java SE，零外部依赖

本项目严格限定在Java SE 8+范围内，不使用Maven或Gradle，所有代码用javac和java命令直接编译运行，确保你能100%复现。所需工具仅三样：

JDK 8u202或更高版本（验证过OpenJDK 11/17）；
一个终端（Linux/macOS）或CMD/PowerShell（Windows）；
网络工具：netstat（查端口）、ping（测连通）、tcpdump（抓包分析，可选）。

目录结构极简：

network-demo/ ├── tcp/ │ ├── TcpServer.java // TCP服务端 │ └── TcpClient.java // TCP客户端 ├── udp/ │ ├── UdpBroadcaster.java // UDP广播发现 │ ├── UdpResponder.java // UDP响应端 │ └── UdpReliableSender.java // UDP可靠发送端 └── common/ └── PacketUtils.java // 序列化/反序列化工具

编译命令（Linux/macOS）：

mkdir classes javac -d classes tcp/*.java udp/*.java common/*.java

运行命令（启动服务端）：

java -cp classes tcp.TcpServer 9090 java -cp classes udp.UdpResponder 8888

注意：Windows用户请将:改为;，即-cp classes。

4.2 TCP通信全流程：从三次握手到优雅关闭的12个关键节点

我们以TcpServer.java和TcpClient.java为例，逐行解析生产级TCP通信的12个关键节点。这不是API罗列，而是每个节点背后的决策理由。

节点1：ServerSocket创建与配置

ServerSocket serverSocket = new ServerSocket(); serverSocket.setReuseAddress(true); // 避免TIME_WAIT端口占用 serverSocket.bind(new InetSocketAddress("0.0.0.0", port), 128); // backlog=128 serverSocket.setSoTimeout(5000); // accept超时5秒，防阻塞

理由：setSoTimeout(5000)让accept()变成“轮询式”，配合线程池可实现连接数弹性伸缩。

节点2：accept()后的Socket配置

Socket clientSocket = serverSocket.accept(); clientSocket.setSoTimeout(30000); // 读超时30秒 clientSocket.setKeepAlive(true); // 启用TCP keepalive，2小时无数据自动探活 clientSocket.setTcpNoDelay(true); // 关闭Nagle算法，小包立即发出（实时性要求高时必开）

理由：setTcpNoDelay(true)禁用Nagle算法，避免小包（如心跳）被缓存合并，这对实时交互至关重要。

节点3：输入输出流获取

DataInputStream dis = new DataInputStream(clientSocket.getInputStream()); DataOutputStream dos = new DataOutputStream(clientSocket.getOutputStream());

理由：DataInputStream/DataOutputStream提供readInt()/writeInt()等原子操作，避免字节序和长度解析错误。

节点4：消息头解析（4字节长度）

int len = dis.readInt(); // 阻塞读取，但有超时保护 if (len < 0 || len > 1024 * 1024) throw new IOException("Invalid length"); byte[] buf = new byte[len]; dis.readFully(buf); // readFully确保读满，内部已处理循环

理由：readFully()比手动while循环更健壮，且是JDK内置优化。

节点5：业务逻辑处理

String msg = new String(buf, StandardCharsets.UTF_8); if (msg.startsWith("REGISTER:")) { handleRegister(msg); } else if (msg.startsWith("HEARTBEAT:")) { handleHeartbeat(msg); }

理由：用前缀而非JSON解析，降低CPU开销，适合嵌入式设备。

节点6：响应发送

String response = "OK:" + System.currentTimeMillis(); byte[] respBytes = response.getBytes(StandardCharsets.UTF_8); dos.writeInt(respBytes.length); dos.write(respBytes); dos.flush(); // 必须flush，否则可能滞留在缓冲区

理由：flush()强制刷出缓冲区，确保对方能及时收到。

节点7：异常处理与连接清理

} catch (SocketTimeoutException e) { log.warn("Client timeout, closing: {}", clientSocket.getRemoteSocketAddress()); } catch (IOException e) { log.error("IO error on client {}", clientSocket.getRemoteSocketAddress(), e); } finally { try { if (clientSocket != null && !clientSocket.isClosed()) { clientSocket.close(); // 显式关闭 } } catch (IOException ignored) {} }

理由：isClosed()检查避免重复close抛异常，ignored日志不打印，减少干扰。

节点8：客户端连接重试

int retry = 0; while (retry < 3) { try { socket = new Socket(); socket.connect(new InetSocketAddress("127.0.0.1", 9090), 5000); break; } catch (IOException e) { retry++; if (retry == 3) throw e; Thread.sleep(1000 * retry); // 指数退避 } }

理由：客户端必须有重试，网络瞬断时避免直接失败。

节点9：客户端发送带重试

for (int i = 0; i < 3; i++) { try { dos.writeInt(msgBytes.length); dos.write(msgBytes); dos.flush(); break; // 成功则跳出 } catch (IOException e) { if (i == 2) throw e; Thread.sleep(100); } }

理由：发送失败可能是对方刚断开，重试100ms后大概率恢复。

节点10：优雅关闭服务端

Runtime.getRuntime().addShutdownHook(new Thread(() -> { try { if (serverSocket != null && !serverSocket.isClosed()) { serverSocket.close(); } } catch (IOException e) { log.error("Failed to close server socket", e); } }));

理由：JVM退出前强制关闭，避免端口残留。

节点11：连接数监控

AtomicInteger activeConnections = new AtomicInteger(0); // accept后：activeConnections.incrementAndGet(); // finally中：activeConnections.decrementAndGet(); // 单独线程每10秒打印：log.info("Active connections: {}", activeConnections.get());

理由：实时掌握连接负载，是容量规划的基础。

节点12：日志分级

DEBUG：每条消息收发详情（含时间戳、长度）；
INFO：连接建立/断开、注册成功；
WARN：超时、重试、长度异常；
ERROR：IO异常、空指针。
理由：生产环境日志必须可追溯、可过滤，DEBUG日志在上线前关闭。

4.3 UDP三种传输方式的代码实现与对比验证

4.3.1 单包直传：设备心跳广播（UdpBroadcaster.java）

这是最轻量的UDP用法，代码仅30行：

public class UdpBroadcaster { public static void main(String[] args) throws Exception { DatagramSocket socket = new DatagramSocket(); socket.setBroadcast(true); String msg = "HEARTBEAT|" + System.currentTimeMillis() + "|DEVICE-001"; byte[] data = msg.getBytes(StandardCharsets.UTF_8); // 发送到255.255.255.255:8888（全网广播） DatagramPacket packet = new DatagramPacket( data, data.length, InetAddress.getByName("255.255.255.255"), 8888 ); while (true) { socket.send(packet); System.out.println("Broadcast: " + msg); Thread.sleep(5000); // 每5秒一次 } } }

验证方法：

启动UdpResponder（监听8888端口）；
运行UdpBroadcaster；
在另一台机器用nc -u -l 8888监听，即可看到心跳包。
注意：若在同一台机器测试，需确保UdpResponder绑定0.0.0.0而非127.0.0.1，否则收不到广播。

4.3.2 请求-应答式：设备发现协议（UdpResponder.java + UdpClient.java）

UdpResponder监听8888端口，收到DISCOVER包即回复FOUND:192.168.1.100:9090：

public class UdpResponder { public static void main(String[] args) throws Exception { DatagramSocket socket = new DatagramSocket(8888); socket.setSoTimeout(10000); byte[] buffer = new byte[1024]; DatagramPacket packet = new DatagramPacket(buffer, buffer.length); while (true) { try { socket.receive(packet); String request = new String(packet.getData(), 0, packet.getLength(), StandardCharsets.UTF_8); if (request.trim().equals("DISCOVER")) { String response = "FOUND:" + getLocalIp() + ":9090"; byte[] respData = response.getBytes(StandardCharsets.UTF_8); DatagramPacket respPacket = new DatagramPacket( respData, respData.length, packet.getAddress(), packet.getPort() ); socket.send(respPacket); System.out.println("Responded to " + packet.getAddress() + ": " + response); } } catch (SocketTimeoutException ignored) {} } } private static String getLocalIp() { try { return InetAddress.getLocalHost().getHostAddress(); } catch (UnknownHostException e) { return "127.0.0.1"; } } }

UdpClient发送DISCOVER并等待响应：

public class UdpClient { public static void main(String[] args) throws Exception { DatagramSocket socket = new DatagramSocket(); socket.setSoTimeout(3000); // 等待响应最多3秒 byte[] reqData = "DISCOVER".getBytes(StandardCharsets.UTF_8); DatagramPacket reqPacket = new DatagramPacket( reqData, reqData.length, InetAddress.getByName("255.255.255.255"), 8888 ); socket.send(reqPacket); System.out.println("Sent DISCOVER"); byte[] buffer = new byte[1024]; DatagramPacket respPacket = new DatagramPacket(buffer, buffer.length); socket.receive(respPacket); // 阻塞等待 String response = new String(respPacket.getData(), 0, respPacket.getLength(), StandardCharsets.UTF_8); System.out.println("Received: " + response); } }

4.3.3 UDP可靠化：固件分片传输（UdpReliableSender.java）

这是最复杂的部分，但核心逻辑清晰：

将1MB固件文件切分为1024字节分片；
每片加2字节序列号、2字节校验码（CRC16）；
发送后启动定时器，超时未收到ACK则重发；
接收方按序列号重组，收到完整序列后通知上层。

关键结构体：

public class UdpPacket { public short seq; // 序列号 public short crc; // CRC16校验码 public byte[] payload; // 有效载荷，≤1024字节 public byte[] toBytes() { ByteBuffer bb = ByteBuffer.allocate(4 + payload.length); bb.putShort(seq); bb.putShort(crc); bb.put(payload); return bb.array(); } }

发送逻辑（简化）：

public void sendFirmware(File firmware) throws Exception { byte[] fileBytes = Files.readAllBytes(firmware.toPath()); int sliceSize = 1024; int totalSlices = (int) Math.ceil((double) fileBytes.length / sliceSize); for (int i = 0; i < totalSlices; i++) { int start = i * sliceSize; int end = Math.min(start + sliceSize, fileBytes.length); byte[] slice = Arrays.copyOfRange(fileBytes, start, end); UdpPacket packet = new UdpPacket(); packet.seq = (short) i; packet.payload = slice; packet.crc = crc16(slice); sendWithRetry(packet); // 带重传的发送 } }

实操心得：分片大小不能超过1400字节（以太网MTU 1500减去IP+UDP头）。我们选1024是为留足余量，避免IP分片——一旦分片，任意一片丢失，整包就报废。

4.4 性能压测与参数调优：用真实数据说话

我们用Apache JMeter对TCP和UDP模块进行压测，硬件环境：4核8G云服务器，千兆内网。

TCP Server压测结果（线程池=50）：

并发用户数	TPS（事务/秒）	平均延迟(ms)	错误率
100	1850	22	0%
500	2100	48	0.02%
1000	2050	85	0.15%

结论：TPS在500并发时达到峰值，之后因线程上下文切换开销增大，性能微降。错误率始终低于0.2%，符合预期。

UDP广播压测（1000台设备模拟）：

使用netcat -u -w1 -b 255.255.255.255 8888发送1000个包；
UdpResponder接收率99.7%，丢包集中在第1-3个包（内核队列初始填充）；
将setReceiveBufferSize(64*1024)后，丢包率降至0.03%。

关键调优参数总结：

TCP backlog：128（计算依据见3.1节）；
UDP receive buffer：64KB（net.core.rmem_max需同步设为65536）；
Socket timeout：accept=5s，read=30s（心跳类业务可设为10s）；
线程池大小：CPU核心数×2（I/O密集型），非CPU密集型。

5. 常见问题与排查技巧实录：那些让你熬夜到凌晨三点的Bug

5.1 “Connection refused”：不只是端口没开，还有五种可能

这个错误日志满天飞，但原因远不止“服务没启动”。我们整理了真实生产环境中出现的六种根因：

现象	根因	排查命令	解决方案
本地telnet 127.0.0.1 9090失败	ServerSocket绑定127.0.0.1，但客户端连0.0.0.0	`netstat -tuln	grep 9090`
telnet 192.168.1.100 9090失败	防火墙拦截（iptables/ufw）	`sudo ufw status`or`sudo iptables -L`	`sudo ufw allow 9090`
外网telnet失败，内网正常	云服务器安全组未开放端口	控制台查安全组规则	添加入方向规则：端口9090，源0.0.0.0/0
启动时报“Address already in use”	端口被其他Java进程占用	`lsof -i :9090`or `netstat -ano	findstr :9090`
启动成功，但客户端连不上	ServerSocket.setSoTimeout(0)导致accept阻塞，线程池耗尽	`jstack <pid> \| grep "accept"`	设置合理timeout，或用非阻塞模式
Docker内服务连不上	容器未暴露端口或host网络模式未启用	`docker run -p 9090:9090 ...`	添加`-p`参数或`--network host`