java中多个catch块在字节码中并非并列选择，而是编译为异常表中多条独立规则；jvm按顺序匹配首个兼容类型并跳转执行，所有catch共享同一监控区间但type不同，子类必须声明在父类前，finally通过物理复制确保各路径必执行。
Java里多个catch块并列时，字节码中**没有“并列选择”结构**，而是由编译器生成多条独立的异常表（Exception table）记录，JVM运行时按顺序查表、匹配首个兼容类型后直接跳转执行。
异常表是真实存在的路由规则
每个catch语句都会在方法的字节码中登记一条异常表项，包含四个关键字段：
- from / to：对应整个try块的字节码起始与结束位置（比如0到12），所有catch共享同一监控区间
- target：该catch处理逻辑在字节码中的起始偏移（如15、24、33），指向各自独立的指令序列
- type：能捕获的异常类全限定名（如java/lang/NullPointerException）
匹配过程严格按表中顺序进行
JVM不会做类型优先级推断或最优匹配，只从上到下逐条检查：
- 先看抛出异常的位置是否落在当前项的from-to范围内
- 再判断抛出异常对象是否为该项type的实例（即满足
instanceof关系） - 一旦满足两个条件，立即跳转到target执行，不再检查后续项
这就解释了为什么catch (Exception e)必须写在最后——如果它排在前面，子类异常（如ArithmeticException）也会被父类catch捕获，导致后面的子类catch永远无法命中。
catch代码被编译成普通指令序列
字节码里不存在特殊的“catch块容器”，每个catch内的语句都被展开为标准指令，放在各自target位置：
- 第15行开始可能是
System.out.println("div by zero")+return - 第24行开始可能是
e.printStackTrace() - 这些代码彼此隔离，不共享局部变量栈帧；未在try前声明的变量，在不同catch中都不可见
finally的实现依赖物理复制
如果存在finally，编译器会把其中的代码**复制多份**，分别插入到每个可能的出口路径末尾：
- 正常执行完try后跳转到finally代码
- 每个catch执行完后也跳转到同一段finally代码（或其副本）
- 甚至try/catch中有return，JVM也会先跳入finally再决定是否返回
这种复制确保finally逻辑在任何控制流路径下都必达，但也让字节码体积略增。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
