getSuppressed()返回Throwable[]数组，仅当异常在try-with-resources中因close()失败且try块已抛出未捕获异常时非空；此时被抑制异常来自资源关闭过程，主异常代表根本原因，抑制异常反映善后失败。
getSuppressed() 返回什么，什么时候不为空
getSuppressed() 返回一个 Throwable[]，仅当该异常是在 try-with-resources 语句中被“压制”（suppressed）时才可能非空。它不会包含主异常本身，也不会在手动调用 addSuppressed() 之外的场景自动填充——比如普通 catch 块里抛出新异常，旧异常不会被自动压制。
关键前提：必须使用 try-with-resources，且资源关闭过程中抛出异常，同时 try 块内已发生异常。此时关闭异常会被压制，追加到主异常的 suppressed 列表中。
- 主异常（try 块中抛出的）是
getCause()或直接 throw 的那个 - 被压制的异常来自
AutoCloseable.close()方法内部 - 若 try 块没异常，
close()抛异常则正常向上冒泡，不会被压制
真实代码里怎么触发并拿到被压制的异常
写一个故意在 close() 中抛异常的资源类，再在 try 块中主动抛异常：
static class BrokenResource implements AutoCloseable {
public void close() throws IOException {
throw new IOException("close failed");
}
}
public static void main(String[] args) {
try (BrokenResource r = new BrokenResource()) {
throw new RuntimeException("main exception");
} catch (RuntimeException e) {
System.out.println("Suppressed count: " + e.getSuppressed().length); // 输出 1
if (e.getSuppressed().length > 0) {
System.out.println("Suppressed: " + e.getSuppressed()[0].getMessage());
// 输出 "close failed"
}
}
}
注意：getSuppressed() 返回的是副本数组，修改它不影响原异常；也不支持添加新压制异常（除非手动调用 addSuppressed()）。
立即学习“Java免费学习笔记（深入）”；
为什么有时 getSuppressed() 是空数组，但明明 close 失败了
常见误判点：以为只要 close() 抛异常就一定被压制。其实取决于“主异常是否已存在”：
- try 块静默执行完毕 →
close()异常直接抛出，getSuppressed()为空 - try 块抛异常 A，A 未被捕获 → 进入 finally 阶段关闭资源 → 若
close()抛异常 B，则 B 被压制进 A 的 suppressed 列表 - try 块抛异常 A，但被外层
catch捕获并吞掉 → 后续不再有“主异常”，close()异常会变成新的抛出点，不被压制
所以，只有未捕获的主异常 + 关闭异常，才会触发压制机制。这也是为什么日志里偶尔看不到 close 错误——它被藏在了主异常的 getSuppressed() 里，不显式打印就容易漏掉。
实际排查时容易忽略的细节
压制异常默认不会出现在 printStackTrace() 的标准输出里（JDK 7+ 默认会打印，但某些日志框架或自定义 toString() 可能省略）。如果你只看异常消息或第一行堆栈，大概率错过被压制的异常。
- 调试时别只信
e.getMessage()，务必检查e.getSuppressed() - 日志记录建议显式遍历：
for (Throwable s : e.getSuppressed()) { log.warn("Suppressed: ", s); } - IDE 调试时，
getSuppressed()数组内容常被折叠，需手动展开查看元素 - 某些老版本 JDK（如早期 7u）对多层压制支持不完善，升级到 8u20+ 更稳妥
压制异常不是装饰，它是资源关闭失败的真实信号——尤其在数据库连接、文件句柄、网络流等场景下，close 失败往往意味着资源泄漏或状态不一致，比主异常更值得警惕。
