Java异常处理底层原理：异常对象由JVM在运行时动态创建，含类型、消息和堆栈；JVM通过查异常表匹配catch位置，未匹配则向调用栈上传；finally由编译器硬插入所有出口分支，确保执行。
Java异常处理的底层原理，核心是JVM如何用对象化、结构化的方式“中断流程 + 传递错误信息”。不用讲字节码指令细节，重点说清三点：异常是谁创建的、怎么找处理位置、为什么finally总能执行。
异常对象由JVM在运行时动态创建
当代码出错（比如除零、空指针），JVM不是简单打印报错就退出，而是立即构造一个异常对象——例如 ArithmeticException(" / by zero") 或 NullPointerException。这个对象不是普通类实例，它自带三样关键东西：
- 异常类型（class名），用于后续匹配catch块
- 详细消息（detailMessage），说明发生了什么
- 完整堆栈轨迹（stackTrace），记录从出错行一直回溯到main方法的每一层调用
注意：fillInStackTrace() 是 native 方法，开销很大，这也是频繁抛异常影响性能的根本原因。
try-catch 的匹配靠JVM实时扫描异常表
编译后的class文件里，每个try块都对应一段“异常表”（exception table），里面存着：起始指令偏移、结束偏移、处理代码起始位置、以及能捕获的异常类型。
立即学习“Java免费学习笔记（深入）”；
一旦异常抛出，JVM不走常规执行流，而是暂停当前方法，拿着异常对象的类型，去查这张表——找到第一个类型匹配且指令范围覆盖当前出错点的catch项，就跳转过去执行。没找到？就弹出当前栈帧，把异常往调用者传，继续查它的异常表。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
所以多个catch必须子类在前、父类在后，否则子类永远匹配不到——这不是语法糖，是异常表查找机制决定的硬规则。
finally 不是“最后执行”，而是被编译器拆进所有分支
你写的 finally 块，javac 在编译时就把它复制粘贴到了每个可能的出口处：try末尾、每个catch末尾、甚至try/catch里的return之前。
也就是说，finally 的代码实际出现在字节码的多个位置，不是靠运行时调度“保证执行”，而是靠编译期硬插入。这也是为什么即使try里写了return，finally仍能先跑——因为return指令被挪到了finally代码之后。
throw 和 throws 不是关键字魔法，而是契约声明
throw 就是主动触发上面说的JVM异常创建+抛出流程；throws 则是在方法签名里向调用方声明：“我可能会抛出这些受检异常，请你做好准备”。这个声明会被编译器检查——没处理或没声明，直接编译失败。
它本质是一种编译期强制的“错误接口协议”，让异常传播路径在写代码时就清晰可见，而不是等运行时才暴露。
