OpenJDK中Throwable.fillInStackTrace实现存疑：清空stackTrace仍能获取栈信息？

1. 核心原理：栈跟踪的存储与延迟加载 #

你之前的误解在于native方法fillInStackTrace(int)并没有直接操作Java层的stackTrace数组，它是将栈跟踪信息存储在native层的backtrace字段（Java代码未直接暴露的native侧变量）。Java层的stackTrace只是一个延迟加载的缓存，并非栈信息的最终存储位置。

当调用printStackTrace()时，实际执行逻辑是：

• 检查stackTrace是否为UNASSIGNED_STACK
• 如果是，则调用getOurStackTrace()方法，从native层的backtrace中提取数据，生成StackTraceElement数组并赋值给stackTrace作为缓存
• 最后用缓存的stackTrace输出栈跟踪信息

这就是为什么fillInStackTrace()把stackTrace设为UNASSIGNED_STACK后，printStackTrace()依然能正常输出的原因。

2. 对fillInStackTrace()逻辑的重新理解 #

带synchronized修饰的fillInStackTrace()方法逻辑：

if (stackTrace != null || backtrace != null /* "Out of protocol state" */ ) {
    fillInStackTrace(0);
    stackTrace = UNASSIGNED_STACK;
}

这段代码的作用是：

• 当stackTrace已有缓存（非null），或者native层的backtrace已存在时，调用native方法刷新native层的栈跟踪信息
• 将stackTrace重置为UNASSIGNED_STACK，目的是清空Java层的缓存，让后续调用printStackTrace()等方法时，重新从native层加载最新的栈信息

3. 注释"Out of protocol state"的含义 #

这个注释指：当backtrace不为null时，当前Throwable对象的状态已经偏离了设计的"正常协议"。正常情况下，Throwable的栈跟踪信息应该是要么仅存在于native层的backtrace，要么缓存到Java层的stackTrace，两者不会同时处于有效状态。当backtrace不为null时，说明对象处于需要重新同步栈信息的异常状态，此时需要调用native方法刷新栈信息并重置缓存。

内容的提问来源于stack exchange，提问作者Antonio Noack