Java网络编程详解_Java套接字开发技术文章与入门到精通教程-java教程-PHP中文网

socket不是万能通信接口，初学者80%调试失败源于选错协议、忽略资源释放、混淆流式与数据报语义；new socket("localhost", 8080)卡住或抛connectexception主因是服务端未监听、端口被占或ipv4/ipv6绑定不一致；serversocket.accept()阻塞时可通过setsotimeout或close()中断实现优雅退出；udp收不到数据常因datagrampacket未设目标地址端口；关闭socket必须先关流再关socket，否则缓冲数据丢失。

java网络编程详解_java套接字开发技术文章与入门到精通教程 - php中文网

Socket 不是万能的通信接口，它只是 Java 网络编程的起点；选错协议类型、忽略资源释放、混淆流式与数据报语义，这三类问题占了初学者调试失败的 80% 以上。

为什么 new Socket("localhost", 8080) 会卡住或抛 `ConnectException`

这不是代码写错了，而是服务端根本没在监听，或者防火墙/端口被占用。TCP 的 Socket 构造函数默认会阻塞直到完成三次握手——如果目标 ServerSocket 未启动、端口被其他进程占着、或本地启用了 IPv6 但服务端只绑定了 IPv4 地址，都会导致超时或直接失败。

先用命令行确认端口状态：netstat -an | grep 8080（Linux/macOS）或 netstat -ano | findstr :8080（Windows）
服务端必须已调用 serverSocket.bind(new InetSocketAddress("0.0.0.0", 8080)) 或直接 new ServerSocket(8080)，且未被 close()
客户端连接时若指定 "localhost"，而服务端绑定的是 "127.0.0.1"，在某些 JDK 版本下可能因 IPv6 解析行为不一致导致失败；统一用 "127.0.0.1" 更稳妥

`ServerSocket.accept()` 阻塞时，程序还能响应 Ctrl+C 吗？

能，但前提是没把 accept() 放在 main 线程里死循环且没做任何中断处理。JVM 默认会响应 SIGINT（Ctrl+C），但如果你的主线程卡在 accept() 上，且没设置 setSoTimeout() 或使用 Thread.interrupt() 配合 isClosed() 检查，那么进程不会优雅退出。

Java JDK 25

Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。

下载

加超时：在 accept() 前调用 serverSocket.setSoTimeout(5000)，这样每 5 秒检查一次是否该退出
配合中断：启动一个守护线程监听关闭信号，然后调用 serverSocket.close() —— 这会立即让阻塞的 accept() 抛出 SocketException，可捕获后 clean exit
别在 accept() 外层套 try-with-resources：它只在 try 块结束时关闭，而 accept() 是无限阻塞的，资源永远不会释放

UDP 用 `DatagramSocket` 发送数据，为什么对方收不到？

最常见原因是没指定目标地址和端口，或者发送方用 send() 时传入的 DatagramPacket 没正确设置 address 和 port。UDP 是无连接的，DatagramSocket 本身不保存远端信息，每次发送都得靠 packet 携带完整目的地。

发送前务必检查：packet.getAddress() != null && packet.getPort() > 0，否则发到 0.0.0.0:0，等同于丢弃
接收方若用 new DatagramSocket(9999)，要确保没被系统保留端口限制（如 macOS 对低端口限制严格），建议用 10000 以上
防火墙常默认拦截 UDP 入站流量，测试时临时关闭或添加规则；Wireshark 抓包看是否有 UDP 包发出比看 Java 日志更可靠

关闭 `Socket` 和 `ServerSocket` 时最容易漏掉什么？

关闭顺序和异常吞并。很多人只关 Socket，却忘了关它的 InputStream 和 OutputStream；或者在 finally 块里 catch 了所有异常却不 re-throw，导致后续 close 失败被静默吞掉。

必须按反向顺序关闭：先关流（in.close(), out.close()），再关 socket.close()；否则流内部可能仍有缓冲未刷出
ServerSocket.close() 会自动关闭所有已 accept 的 Socket，但不会等它们传输完——所以业务逻辑中需自行控制连接生命周期
不要在 catch 中只写 e.printStackTrace()：它不抛异常，也不记录日志级别，生产环境等于没处理

真正麻烦的从来不是“怎么连上”，而是“连上之后怎么不崩、断开之后怎么不漏”。Java 的 Socket API 表面简单，但每个方法背后都连着操作系统网络栈的状态机，稍有错位，就会出现连接半开、端口 TIME_WAIT 堆积、或 SocketException: socket closed 这类让人反复怀疑人生的问题。