为什么 ServerSocket accept() 会卡住，客户端连不上？

本质是服务端没真正监听成功，或者客户端连的是错地址。常见于 localhost 和真实 IP 混用、防火墙拦截、端口被占用。

• 启动前先用 netstat -an | grep :8080（Linux/macOS）或 netstat -ano | findstr :8080（Windows）确认端口空闲
• 服务端别写 new ServerSocket(8080) 就完事——得显式绑定 new ServerSocket(8080, 50, InetAddress.getByName("0.0.0.0"))，否则默认只绑 127.0.0.1，局域网其他机器访问不到
• 客户端 new Socket("192.168.1.100", 8080) 里的 IP 必须是服务端机器在局域网的真实 IP（用 ipconfig 或 ifconfig 查），不能填 localhost 或 127.0.0.1

文件传输时为什么接收端只拿到前几个字节就结束了？

根本原因是没处理 TCP 流的边界：InputStream.read() 不保证一次读满缓冲区，而很多人直接拿 read(buffer) 返回值当“已读完”信号。

• 必须循环读，直到 read() 返回 -1（流结束）——尤其对文件这种大块数据
• 别用 available() 判断是否读完，它只返回“当前可不阻塞读取的字节数”，不是文件总长
• 发送端关流顺序很重要：先 out.flush() 再 out.close()，否则最后一点数据可能卡在缓冲区里发不出去

用 DataInputStream / DataOutputStream 传文件靠谱吗？

不推荐。它们是为基本类型（int, double）设计的，底层仍调用 read()/write()，但额外加了类型校验和包装逻辑，对纯字节流反而多一层风险。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 传文件直接用 BufferedInputStream + BufferedOutputStream，性能好、无歧义
• 如果真要用 DataOutputStream.writeUTF() 发文件名，注意它最大只支持 65535 字节长度，超长路径会抛 UTFDataFormatException
• 别混用：服务端用 DataInputStream 读，客户端却用普通 OutputStream 写——协议不匹配，读操作会一直等或直接报 IOException

如何让传输过程不卡 UI，又避免多线程资源冲突？

核心是分离 I/O 和界面线程，但别裸写 Thread——容易漏关流、重复启停、状态失控。

• 用 ExecutorService 管理传输任务，比如 Executors.newSingleThreadExecutor() 控制并发数
• 每次传输新建独立的 Socket 和流对象，别复用；流对象不可跨线程共享，更不能多个线程同时 read() 同一个 InputStream
• 进度回调别直接更新 Swing/AWT 组件——用 SwingUtilities.invokeLater() 或 JavaFX 的 Platform.runLater() 包一层

实际写的时候，最常被忽略的是异常后流没关闭。哪怕加了 try-with-resources，也得确认所有分支（包括 catch 块里）都覆盖到了，不然 socket 句柄泄漏，跑几次就 bind 失败。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南