EOFException不是正常结束信号，而是输入流意外提前终止的异常标志；应通过read()返回-1判断流结束，避免用其控制流程，仅在数据损坏或传输中断时捕获处理，并用try-with-resources确保资源关闭。
EOFException 本身不是“文件读取结束”的正常信号，而是 异常状态的标志，它表示在预期还能读取数据时，输入流意外提前终止。因此，不能依赖 EOFException 来判断二进制流的自然结束，否则会导致逻辑混乱、资源泄漏或误判错误。
正确识别二进制流读取结束的方式
Java 中标准二进制流（如 DataInputStream、ObjectInputStream、BufferedInputStream）的读取方法对“流末尾”的响应是分层的：
- read() / read(byte[]) / read(byte[], int, int)：返回 -1 表示已到流末尾，这是合法、预期、非异常的结束信号；
- readInt() / readLong() / readUTF() 等封装方法：内部按字节读取，若未读满所需字节数（比如要读 4 字节 int，但只剩 2 字节），则抛出 EOFException；
- ObjectInputStream.readObject()：同理，反序列化中途流断开，抛 EOFException —— 这代表数据损坏或传输中断，不是“正常结束”。
避免误用 EOFException 的关键实践
不要用 try-catch EOFException 来驱动循环，而应主动检查底层 read() 返回值：
- 用 InputStream.read(byte[]) 循环读取，检查返回值是否为 -1；
- 若必须用 DataInputStream，仅在其 readFully() 或类型读取方法前，确保剩余字节足够（可通过 available() 辅助估算，但不保证 100% 准确）；
- 对网络流（如 Socket.getInputStream()），尤其不能假设一次 read() 能读完全部数据，必须循环 + 判 -1；
- 若业务协议约定以特定长度结尾（如头部含 payload 长度），优先按长度读取，而非等待异常。
何时 EOFException 确实有意义
它应在以下场景被 捕获并作为错误处理，而非流程控制：
- 从本地文件读取一个已知结构的二进制记录（如 16 字节 header + 变长 body），但文件被截断；
- RPC 或序列化通信中，对方进程崩溃导致连接关闭，本端 readObject() 中途失败；
- 校验流完整性时，发现实际字节数与元信息声明不符，EOFException 是该问题的直接体现。
闭环资源的可靠方式
无论读取是否异常，都需确保流关闭。推荐使用 try-with-resources：
- 所有 InputStream 及其装饰器（DataInputStream、BufferedInputStream 等）均实现 AutoCloseable；
- 即使发生 EOFException，try-with-resources 仍会执行 close()，避免句柄泄露；
- 若需在 catch 块中做日志或恢复操作，可配合 finally 或单独 close()，但务必判空。
