异常堆栈源于JVM冻结线程并遍历虚拟机栈中各栈帧，提取类名、方法名、文件名和行号（来自LineNumberTable），填充至Throwable的stackTrace数组。
异常堆栈从哪来：JVM如何捕获调用链
当Java代码抛出异常（无论是throw new NullPointerException()还是运行时触发的空指针），JVM不会只记录“发生了什么”，而是立即冻结当前线程的执行状态，回溯整个方法调用路径。这个过程依赖于每个线程私有的虚拟机栈——它不是普通数据结构，而是一连串按时间顺序压入的栈帧（Stack Frame），每个栈帧对应一次方法调用。
栈帧里保存着关键信息：局部变量表、操作数栈、动态链接、方法返回地址。更重要的是，每个栈帧都隐含了它所属的方法在字节码中的位置（PC计数器值）和源码映射（如果编译时带-g调试信息）。JVM顺着栈顶往下逐帧读取这些元数据，就自然拼出了从异常点到main或线程启动处的完整调用链。
堆栈信息怎么组织：从抛出点到底层入口的逆序排列
打印出来的堆栈轨迹（stack trace）是反向的：第一行是异常类型和消息，紧接着的每一行代表一个栈帧，但顺序是从最新调用往最早调用排。比如：
java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null
at com.example.Util.process(Util.java:12)
at com.example.Service.handle(Service.java:25)
at com.example.Main.main(Main.java:8)
这说明异常实际发生在Util.process第12行，但它被Service.handle调用，而handle又被Main.main调用。JVM生成时就是按这个“异常点→上一层→再上一层…”的方式收集，所以日志天然可读。
立即学习“Java免费学习笔记（深入）”；
注意：若方法是本地方法（native）、JIT已内联、或编译时未保留调试信息，对应行可能显示Unknown Source或省略行号——这不是丢失，而是原始信息本就不可得。
关键字段怎么填充：类名、方法、文件、行号的来源
堆栈中每行的四个核心字段并非运行时计算得出，而是在类加载阶段就固化在字节码里：
-
类名：来自常量池中的
CONSTANT_Class_info项，解析后得到全限定名； -
方法名：对应栈帧中
method->name指针，指向常量池的CONSTANT_Utf8_info； -
文件名与行号：由
LineNumberTable属性提供，该属性是编译器根据源码生成的映射表，记录字节码偏移量到源码行号的对应关系；
没有LineNumberTable（如生产环境常关闭调试信息），JVM仍能生成堆栈，但行号会缺失。类名和方法名则始终存在，因为它们是方法调用的必要标识。
异常对象怎么携带堆栈：fillInStackTrace()的作用
所有Throwable子类在构造时，默认会调用fillInStackTrace()方法。这个方法不是简单地“记下当前栈”，而是：
- 遍历当前线程的Java虚拟机栈，提取每个活动栈帧的类、方法、行号等信息；
- 将结果存入
Throwable对象的stackTrace字段（类型为StackTraceElement[]）； - 该数组后续被
printStackTrace()或日志框架序列化输出。
你可以手动调用setStackTrace(...)覆盖它，也可以在构造时传入enableSuppression = false, writableStackTrace = false来跳过填充——这对高频抛出的性能敏感异常（如某些状态检查）有实际意义。
