java的try-with-resources应管理底层流（如fileinputstream），而非objectinputstream/objectoutputstream，因后者是装饰器且不持有真实资源；关闭底层流即可释放文件句柄等系统资源。
Java 的 try-with-resources 本身不能直接用于对象序列化流的“自动关闭”，因为 ObjectInputStream 和 ObjectOutputStream 并不参与反序列化/序列化过程中的资源释放逻辑——它们真正依赖的底层流（如 FileInputStream、FileOutputStream、BufferedInputStream 等）才需要被关闭。
关键点：关闭的是底层流，不是 ObjectXxxStream 本身
ObjectInputStream 和 ObjectOutputStream 是装饰器（Decorator）模式的典型应用，它们包装一个已存在的输入/输出流，并在其基础上提供对象读写能力。它们自身不持有操作系统级别的资源（如文件句柄、socket 连接），真正的资源由被包装的流持有。因此，只要确保被包装的流实现了 AutoCloseable（绝大多数标准 I/O 流都实现了），并在 try-with-resources 中声明它，就能正确关闭。
注意：ObjectInputStream 和 ObjectOutputStream 本身也实现了 AutoCloseable，但调用其 close() 方法最终仍会委托给底层流；所以把它们放进 try-with-resources 也没错，但**必须保证底层流也在作用域内被管理**，否则可能提前关闭导致异常。
推荐写法：将底层流作为 try-with-resources 的资源
这是最清晰、最安全的方式，避免嵌套或误关中间流：
- 用
FileInputStream创建ObjectInputStream，把FileInputStream放入 try-with-resources - 用
FileOutputStream创建ObjectOutputStream，把FileOutputStream放入 try-with-resources -
ObjectInputStream/ObjectOutputStream可以在 try 块内创建，无需声明为资源
示例（反序列化）：
try (FileInputStream fis = new FileInputStream("data.obj")) {
ObjectInputStream ois = new ObjectInputStream(fis);
MyData obj = (MyData) ois.readObject();
// 使用 obj...
} catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
也可以把 ObjectXxxStream 本身作为资源（需谨慎）
如果坚持让 ObjectInputStream 或 ObjectOutputStream 出现在资源列表中，必须确保它们包装的是可关闭的流，且该流未被其他地方持有或提前关闭：
- 可以写成
try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("data.obj"))) { ... } - 这种写法合法，因为
FileInputStream是匿名创建并立即传入，其生命周期完全由ObjectInputStream管理 - 但若底层流是复用的（比如从池里取的
InputStream），就不该让ObjectInputStream关闭它，否则会破坏复用逻辑
常见错误与规避
- 只关闭
ObjectInputStream，却把FileInputStream单独声明在 try 外 → 底层流未关闭，资源泄露 - 先 close() 底层流，再用
ObjectInputStream读取 → 抛IOException: Stream closed - 在 try-with-resources 中同时声明底层流和装饰流（如
FileInputStream和ObjectInputStream）→ 关闭顺序不可控，可能重复关闭或关闭失效
只要抓住“谁持有了真实资源”这个核心，try-with-resources 在序列化场景下就和普通 I/O 一样自然可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
