EOFException 不是正常结束信号，而是异常
Java 的 ObjectInputStream 在流末尾调用 readObject() 时抛出 EOFException，但它**不是设计用来判断“读完了”的手段**——这是个常见误解。它本质是 I/O 异常，表示底层字节流意外终止，比如网络断连、文件被截断、或写端提前关闭，而不仅仅是“自然读到结尾”。直接 catch 它来控制循环，容易掩盖真实问题。
- 真实场景中，
EOFException往往意味着数据损坏、协议不匹配或资源未正确关闭 -
ObjectInputStream本身不提供hasNext()类方法，无法预判是否还有对象可读 - 若写端用
ObjectOutputStream写入多个对象后正常关闭，读端仍会触发EOFException——这不是 bug，是 Java 序列化协议的限制
推荐方案：写端主动发送长度/计数，读端按需读取
最稳的方式是绕过依赖流状态判断，改由应用层约定协议。比如写端先写入对象总数（int），再逐个写对象；读端先读 int，再循环 readObject() 指定次数。
- 写端示例：
out.writeInt(list.size()); for (var obj : list) out.writeObject(obj); - 读端示例：
int count = in.readInt(); for (int i = 0; i - 优势：不依赖 EOF，无异常干扰，兼容网络和文件，且能提前校验数据完整性
- 注意：
readInt()本身可能抛IOException，需单独处理，但不会混淆为“读完”
不得已用 try-catch 时，必须区分 EOFException 和其他 IOException
如果协议已固定、无法加计数头（如对接遗留系统），只能捕获异常，但绝不能把所有 IOException 都当 EOF 处理。
- 只捕获
EOFException，不要 catchIOException或其父类 - 确保外层流（如
FileInputStream或SocketInputStream）确实已关闭，而非中途断开——后者可能抛SocketException或IOException带不同 message - 在 catch 块里，不要再调用
readObject()，也不要试图“重试”，因为流已处于不可恢复状态 - 示例片段：
try { while (true) { Object obj = in.readObject(); // 处理 obj } } catch (EOFException e) { // 正常退出：仅在此处处理“读完”逻辑 } catch (ClassNotFoundException | InvalidClassException e) { // 序列化兼容性问题，不应忽略 }
替代方案：改用 DataInputStream + 自定义序列化，或换 JSON/Protobuf
原生 Java 序列化耦合深、脆弱、不跨语言。EOFException 频繁出现，往往是架构层面该升级了。
立即学习“Java免费学习笔记（深入）”；
- 对简单结构，用
DataInputStream+ 手写writeUTF()/readUTF()等，配合明确长度前缀，完全规避EOFException干扰 - 需要跨语言或长期存储，直接弃用
ObjectInputStream，改用JSON（Jackson/Gson）或Protobuf——它们都有明确的解析失败机制，且不依赖流末尾异常 - 性能上，JSON/Protobuf 通常比 Java 序列化更快更省空间，尤其在网络传输中
真正麻烦的不是怎么 catch EOFException，而是它一出现，往往说明你已经在和不可靠的流边界、不清晰的协议、或过时的序列化方式较劲。越早把“读多少个对象”这个信息显式带上，后面就越少半夜被一个空指针或 class not found 拉起来查日志。
