throwable 的核心是异常对象构建与抛出分发的“双轨驱动机制”：前者通过 fillinstacktrace() 快照栈帧、组装消息和因果链，后者依赖字节码 exceptiontable 匹配跳转；二者协同完成异常处理。

要真正理解 Throwable 的核心源码和 JVM 异常的“双轨驱动机制”，关键在于看清两条并行路径：一条是异常对象的构建与封装路径（堆栈填充、消息组装、因果链建立），另一条是异常抛出后的查找与分发路径（字节码异常表匹配、栈帧回溯、处理器跳转）。这两条路径在运行时协同工作，缺一不可。

Throwable 对象的初始化不是简单 new，而是带状态快照的构造

Throwable 的构造方法看似普通，实则暗含 JVM 深度介入：

• fillInStackTrace() 是 native 方法，由 JVM 在对象创建瞬间执行，负责采集当前线程的完整调用栈，并存入 stackTrace 数组；它不依赖 Java 层代码，也无法被子类覆盖
• backtrace 字段为 transient，说明它不参与序列化——因为栈信息属于运行时上下文，跨进程/网络传输无意义
• cause 默认指向自身（this），只有显式传入非空 Throwable 才构成异常链；这种设计让嵌套异常（如 SQLException 包裹 IOException）可逐层追溯根源
• detailMessage 是纯字符串，不自动包含堆栈，所以 getMessage() 只返回它，而 printStackTrace() 才触发完整上下文输出

异常传播不是靠“抛”动作本身，而是靠字节码异常表驱动跳转

try-catch 不是语法糖，它在编译后会生成真实的数据结构——ExceptionTable，位于方法的字节码属性中：

• 每条表项定义了监控范围：start_pc 到 end_pc，即哪些字节码指令受保护
• 指定捕获类型：catch_type 指向常量池中的异常类符号引用（如 java/lang/ArithmeticException）
• 命中后跳转地址：handler_pc 直接指向 catch 块编译后的第一条指令偏移量
• JVM 在 throw 时并不遍历所有 try 块，而是按栈帧从顶向下查当前方法的 ExceptionTable，匹配成功即跳转，否则弹出栈帧继续查上层——这是性能关键

双轨交汇点：异常对象创建完成 + 异常表匹配成功 = 安全落地

一个异常能被正确捕获，必须同时满足两个条件：

• Throwable 实例已完整构建：栈帧快照写入、消息填充完毕、因果关系明确
• 当前执行点落在某 try 块的 start_pc～end_pc 范围内，且抛出类型与表中 catch_type 兼容（如抛 NullPointerException，表中为 RuntimeException 也匹配）
• 若任一条件失败（如栈溢出导致无法分配 stackTrace 数组，或抛出异常时不在任何 try 范围内），JVM 就终止线程并交由未捕获处理器处理

虚拟线程下双轨机制不变，但传播路径更隐蔽

虚拟线程虽轻量，但异常仍走相同双轨：

• 其 fillInStackTrace() 仍采集逻辑调用栈（非载体线程物理栈），确保业务上下文不失真
• 字节码 ExceptionTable 依然存在，JVM 虚拟线程调度器会在 carrier thread 上模拟栈帧回溯行为
• 区别在于：未捕获异常不会杀死 carrier thread，而是触发 UncaughtExceptionHandler 后，该虚拟线程直接结束，载体线程继续调度其他任务
• 因此调试时需主动设置线程名和日志上下文，否则 printStackTrace() 显示的线程名是自动生成的无意义字符串