eofexception不是正常结束信号，而是表示流被意外截断，如网络断开、文件被删或序列化中断；将其当作正常退出会掩盖真实故障，仅在可控且允许非对称结束的极少数场景下才可捕获处理。
Java里EOFException到底是不是“正常结束”的信号？
不是。它明确表示流被意外截断——数据还没读完，输入源就没了。比如网络连接突然断开、文件被其他程序删掉、或序列化对象写了一半就中断。把它当正常退出条件，会掩盖真实故障。
常见错误现象：ObjectInputStream.readObject() 在反序列化中途抛 EOFException，但业务代码却当成“读完了”继续执行，导致后续逻辑用到 null 或不完整对象。
- 只在明确知道流可能提前终止（如自定义协议中带长度头但未校验）时，才考虑捕获并处理
- 绝不要在
while ((obj = in.readObject()) != null)这类循环里靠捕获EOFException来退出——readObject()本就不返回null，这个写法本身就有问题 - 如果真要支持“可中断读取”，应该用带超时的通道（如
Socket.setSoTimeout()）配合IOException分支判断，而不是依赖EOFException
什么时候该捕获EOFException？
极少数场景：你完全控制读写两端，且协议允许“非对称结束”。例如一个日志传输工具，发送端可能因 crash 没发完，接收端需容忍并保存已收到的部分。
使用场景举例：用 DataInputStream 读固定格式二进制块，每块前4字节是长度，但最后一块可能缺损。
立即学习“Java免费学习笔记（深入）”；
- 必须先检查流是否真的到了物理末尾（比如
in.available() == 0），再结合上下文判断是否可接受 - 捕获后应记录 warn 级日志，包含当前偏移量和期望读取长度，方便事后排查是网络抖动还是上游 bug
- 不要静默吞掉异常；更不要在 catch 块里直接 return 或 continue，除非你清楚每一步状态是否可恢复
EOFException 和 IOException/SocketException 的区别在哪？
EOFException 是 IOException 的子类，但它特指“读操作期望更多字节，但底层流已报告 end-of-stream”。而 SocketException: Connection reset 表示连接被对方强制关闭，IOException: Broken pipe 是写时发现对端已关连接。
关键差异在于发生时机和可恢复性：
-
EOFException只会在read()、readInt()、readObject()等阻塞读方法内部检测到流空时抛出 -
SocketException可能在读或写任意时刻触发，通常意味着连接已不可用，重试前必须重建 socket - 同一个网络错误，在不同 JDK 版本或 OS 上可能表现为不同异常类型（比如 Linux 下 FIN 包触发
EOFException，Windows 下可能报SocketException），所以生产环境建议统一捕获IOException并根据 message 做细分
用ObjectInputStream时怎么避免误判EOFException？
最常踩的坑：没配好构造顺序，或忘了调用 ObjectOutputStream.flush()，导致接收端等不到完整的序列化头，直接抛 EOFException。
实操要点：
- 服务端必须先 new
ObjectOutputStream，再 newObjectInputStream（反之会卡在握手阶段） - 每次写完对象后，必须显式调用
out.flush()——writeObject()不自动 flush - 客户端读取前，确认 socket 已完成三次握手且
isConnected()返回 true；否则可能在 readHeader 阶段就失败 - 如果只是传简单数据，优先用
DataInputStream+ 自定义协议，避开ObjectInputStream的复杂握手和兼容性问题
真正难处理的从来不是 EOFException 本身，而是它背后暴露的流生命周期管理混乱——谁负责关闭、超时怎么设、中断信号如何传递。这些不在异常里，但在每次抛出时都漏了一点。
