Closeable接口语义是“对象持有需显式释放的系统资源，关闭具备幂等性、仅抛IOException、与try-with-resources强绑定”；它标识文件描述符等OS资源占用，要求close()多次调用等效一次且不抛非法状态异常，限定异常为IOException以明确I/O环境故障，并作为try-with-resources自动关闭的契约基础。

Closeable接口在IO变量操作中表达的通用语义是：“该对象持有一个需显式释放的系统级资源，且关闭行为具备幂等性、异常可预期、与I/O错误强关联”。它不是简单的“清理方法”，而是对资源生命周期终点的契约式声明。

资源持有性：明确标识“我占着操作系统资源”

实现Closeable的IO变量（如FileInputStream、Socket、BufferedReader）本质上都封装了底层操作系统资源：文件描述符、网络连接句柄、内存映射区等。这些资源数量有限，不关闭会导致泄漏——进程可能因“too many open files”崩溃。Closeable就是向调用方发出明确信号：“我不是普通Java对象，我背后连着OS。”

• 不是所有流都需要Closeable（例如ByteArrayInputStream/ByteArrayOutputStream不涉及OS资源，但为统一编程模型仍实现了它）
• JDBC中的Connection、Statement、ResultSet也实现Closeable，逻辑同源：它们持有数据库服务端的会话和游标资源

幂等性保证：多次close不引发状态错乱

Closeable要求close()方法具备幂等性——无论调用一次还是十次，效果等价于调用一次，且不会抛出非法状态异常（如IllegalStateException）。这是为应对复杂场景下的防御性编码：

• try-with-resources自动调用close()，但业务代码里又手动调了一次
• 异常分支中提前close，finally块再执行一次
• 多线程环境下多个线程尝试关闭同一资源

典型实现方式是内部维护一个volatile boolean closed标记，close()开头先检查，已关闭则直接返回。

IOException专属契约：错误类型即语义

Closeable重写了AutoCloseable的close()方法，强制声明throws IOException。这个细节极具语义重量：

• 关闭过程本身可能触发I/O动作（如刷新缓冲区、发送FIN包、等待磁盘落盘），这些操作天然可能失败
• 把异常限定为IOException，让调用方清楚：这不是编程错误，而是外部环境问题（磁盘满、网络中断、权限不足）
• 避免笼统的Exception或RuntimeException掩盖真实故障域

与try-with-resources的语义绑定：自动即责任

Closeable被设计为try-with-resources的“原生公民”。当一个变量声明在try(…)括号内，JVM保证其close()会在作用域退出时被调用——无论正常结束还是异常跳出。这种自动性不是便利性糖衣，而是将“资源释放”从可选最佳实践升级为编译器强制的语义义务：

• 资源声明必须是final或等效final（编译器隐式添加）
• 多个资源用分号隔开，关闭顺序与声明顺序相反（后声明的先关闭，保障依赖关系）
• 即使构造时就抛异常，JVM仍会跳过未成功初始化的资源，只处理已赋值的对象