资源为 null 时 try-with-resources 会跳过 close() 调用且不抛异常，这是 java 规范明确设计的行为；多个资源中仅非 null 资源按逆序正常关闭，null 资源被静默忽略。
如果 try-with-resources 语句中声明的资源为 null，Java 不会报错，也不会自动调用 close()，但也不会抛出异常——前提是该资源变量确实被初始化为 null，且未在 try 块中被重新赋值。
资源为 null 时的行为
根据 Java 语言规范，try-with-resources 中每个资源表达式必须是实现了 AutoCloseable 的引用类型。当资源表达式求值结果为 null，JVM 会跳过对该资源的 close() 调用，不执行任何操作，也不抛出 NullPointerException。
- 这是明确设计行为，不是 bug 或例外情况
- 适用于所有
AutoCloseable子类型（如Closeable、Socket、FileInputStream等） - 即使多个资源中部分为
null，其余非空资源仍会正常关闭
常见写法与潜在风险
以下写法合法但容易引发逻辑疏漏：
InputStream is = someCondition ? new FileInputStream("a.txt") : null;
try (InputStream in = is) { // in 可能为 null
// 使用 in...
} // 如果 is == null，这里什么都不会发生
问题在于：你可能误以为资源“已安全处理”，实际却因 null 导致本该打开的文件没被读取、连接没被释放（如果后续手动用了其他方式），或掩盖了上游初始化失败的问题。
- 不会触发
close()→ 若资源本应由你创建并管理，null往往意味着初始化失败，应显式处理 - 异常不会被抑制 → 如果 try 块中抛异常，而某个资源为
null，它不会参与异常抑制机制（因为没调用close()）
推荐做法：避免让资源变量为 null
try-with-resources 的初衷是简化确定性资源清理，而不是兜底处理初始化失败。更健壮的方式是：
- 确保资源表达式不返回
null：用构造器、工厂方法或 Optional 处理前置条件 - 初始化失败时主动抛异常（如
IllegalArgumentException），而非静默返回null - 若必须支持“可选资源”，改用传统 try-finally，并显式判空
例如：
// ✅ 推荐：失败即抛异常，不传 null
InputStream in = createInputStream(); // 内部保证不返回 null，否则抛 IOException
try (in) {
// ...
}
// ❌ 不推荐：把 null 交给 try-with-resources
InputStream in = maybeCreateInputStream(); // 可能返回 null
try (in) { ... } // 关闭逻辑失效，且不易察觉
特殊情况：嵌套资源与多资源顺序
当多个资源同时声明时，null 资源不影响其他资源的关闭顺序：
try (ResourceA a = getA(); // 返回 null
ResourceB b = getB(); // 返回非 null
ResourceC c = getC()) { // 返回非 null
// ...
}
执行过程是：c.close() → b.close() → a 跳过。没有副作用，但需注意：如果 b 或 c 的创建依赖 a，而 a 是 null，那通常应在获取阶段就失败，而不是靠 try-with-resources 补救。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
