cause是Throwable中记录引发当前异常的原始异常的字段，支持异常链追溯；Java允许自引用（如e.initCause(e)），虽不报错但调用printStackTrace()或序列化时会因无限递归触发StackOverflowError。
Throwable 中的 cause 自引用不会导致 JVM 层面的死循环，但可能在调用 printStackTrace() 或序列化时触发无限递归，最终抛出 StackOverflowError。
cause 是什么，为什么能自引用
cause 是 Throwable 的一个字段，用于记录“引发当前异常的原始异常”，支持异常链追溯。Java 允许将一个异常对象设为另一个异常的 cause，包括把自己设为自己的 cause（即自引用）。这不是 bug，而是设计上未禁止的边界情况——因为构造函数不校验 cause != this。
例如：
Exception e = new Exception("outer");
e.initCause(e); // 合法但危险
哪里会实际触发无限递归
问题不出现在抛出或捕获阶段，而集中在以下两个典型场景：
立即学习“Java免费学习笔记（深入）”；
-
调用
e.printStackTrace()：该方法内部会递归遍历 cause 链并打印每个异常的栈信息。若 cause 指向自身，就会无限调用printStackTrace()→getCause()→ 再次printStackTrace()，直到栈溢出。 -
使用 Jackson/Gson 序列化异常对象：这些库默认会尝试序列化 cause 字段。一旦遇到自引用，就会反复尝试序列化同一个对象，最终触发
StackOverflowError或JsonMappingException（如你知识库中提到的 RPC 测试平台 JSON 转换失败）。
如何避免和检测
自引用本身极少是业务所需，多由误操作或动态包装逻辑引入（比如统一异常包装器中未判空或未防重）。建议从三方面防控：
- 自定义异常构造时，显式检查：
if (cause == this) throw new IllegalArgumentException("Cause cannot be self"); - 在全局异常处理器或日志模块中，对要打印/序列化的异常做环路检测，例如用
Set<Throwable>缓存已访问对象，遇到重复则截断输出。 - 调试时若发现
StackOverflowError出现在printStackTrace或toString调用栈中，应立即检查异常的 cause 是否为自身或形成环状链（如 A→B→C→A）。
它和程序级死循环本质不同
这里的“死循环”是栈帧无限增长导致的递归崩溃，并非 CPU 空转的 while(true) 类型死循环。JVM 会在栈空间耗尽时主动抛出 StackOverflowError 并终止当前线程，不会卡死进程或占用 CPU 持续 100%。所以它更准确地说是一种“不可恢复的递归溢出”，而非运行时持续执行的死循环。
