异常链显著增加内存开销并延长对象存活周期，导致eden区填充加速、对象过早晋升老年代；应避免混入大对象或敏感数据，并采用静态模板、惰性填充等轻量替代方案。
异常链本身会显著增加内存开销
异常链（即通过 initCause() 或带 cause 构造器创建的嵌套异常）会让多个异常对象相互引用，形成强引用链。每个异常对象都默认调用 fillInStackTrace()，生成完整堆栈跟踪——这包括数十个 StackTraceElement 实例，每个含类名、方法名、行号等字符串字段。这些数据全部分配在 Eden 区，且多数对象体积达几 KB。若链长为 3（如 A → B → C），则至少创建 3 个异常实例 + 对应的栈帧数组，内存占用呈线性增长，而非简单叠加。
异常链延长对象存活周期，加剧晋升压力
异常链中靠前的异常（如最外层 RuntimeException）若被日志框架捕获并暂存（例如 SLF4J 的 MDC、或全局异常处理器缓存），整个链上所有异常对象都会因被间接引用而无法在 Young GC 中及时回收。即使内层异常（如 cause）逻辑上已无业务用途，只要外层异常仍可达，整条链就“绑定存活”。实测显示：在高并发参数校验场景中，使用带 cause 的 ValidationException 后，Eden 区对象平均年龄从 1.2 升至 2.8，约 15% 的异常对象在第二次 Minor GC 后晋升老年代，推高 Old GC 频率。
避免在异常链中混入大对象或敏感数据
- 不要将 JSON 序列化结果、原始请求体、堆栈快照 dump 等作为异常消息或 cause 附加信息——它们极易触发 Eden 区大块连续分配，甚至逼近 -XX:PretenureSizeThreshold 阈值
- 避免把 Map、byte[]、ArrayList 等持有大量元素的容器设为异常 cause；这类对象本身不易回收，还会拖慢 GC 根扫描
- 慎用 Throwable.addSuppressed()：每调用一次都会新建一个 SuppressedExceptions 数组并复制旧内容，高频调用下产生大量短命数组对象
可观测与轻量替代方案
启用 JVM 参数 -Xlog:gc+age=debug，观察 GC 日志中异常相关对象的 age 分布；若发现大量对象在 age=1 或 age=2 被回收，说明异常链未造成严重晋升，但已带来 Eden 填充压力。更优实践是：用 static final 异常模板替代运行时构造（仅限语义允许场景）；对需携带上下文的异常，改用惰性填充机制——例如重写 getLocalizedMessage()，仅在首次调用时拼接关键字段，不预分配完整字符串；对调试用途的深层链，可考虑仅在 DEBUG 模式下启用 fillInStackTrace()，生产环境调用 setStackTrace(new StackTraceElement[0]) 清空栈帧。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
