Java栈帧是JVM方法调用时的基本执行单元，包含局部变量表、操作数栈、动态链接、方法返回地址及附加信息，遵循后进先出原则，每个方法对应唯一栈帧，仅栈顶帧有效。
这个问题存在根本性概念混淆，需要先厘清几个关键点：
多重捕获（multi-catch）和栈帧物理存储没有直接关系
Java 的 catch (IOException | SQLException e) 是编译器层面的语法糖，编译后会生成多个独立的 exception table 条目，指向同一段字节码。JVM 在执行时依据抛出异常对象的实际运行时类型（instanceof 语义）匹配这些条目，不涉及对 catch 参数 e 在栈帧中“如何存储子类”的控制或优化。e 在栈帧里就是一个普通局部变量槽（local variable slot），其静态类型是所有列出异常的最近公共父类（如 Exception），JVM 不为每个“可选类型”分配独立空间。
栈帧中不存储“各个子类”
栈帧保存的是：
- 局部变量（含
e这个引用） - 操作数栈
- 动态链接、方法返回地址等
它不保存类型列表、不区分“这个槽位本可以是 A 或 B”。所谓“多重捕获的子类”，只是源码写法和编译期检查规则，不是运行时数据结构。
高性能错误处理的关键不在栈帧布局，而在设计与实践
真正影响性能与健壮性的，是以下可操作方向：
精准捕获，避免泛化兜底
直接catch (IOException e)比catch (Exception e)更快——前者跳过对其他异常类型的匹配判断；后者强制 JVM 尝试匹配整个继承链，且极易掩盖问题。减少异常发生频次（预防优于捕获）
Files.exists(path)比Files.readAllBytes(path)后捕获NoSuchFileException更高效；校验参数（如Objects.requireNonNull）比放任NullPointerException抛出再捕获更轻量。异常对象创建本身有开销
new RuntimeException()会填充堆栈（fillInStackTrace）。若用于流程控制（反模式），应改用状态码或 Optional；若必须抛出，可考虑复用静态异常实例（仅适用于无上下文的简单场景，如Collections.EMPTY_LIST风格）。日志与传播要克制
logger.error("msg", e)记录完整堆栈是必要的，但频繁打印或在循环内捕获后重复记录，会拖慢 I/O 和 GC。生产环境避免e.printStackTrace()。善用 try-with-resources
它由编译器重写为带 finally 的显式 close 调用，JVM 对AutoCloseable的调用有优化路径，比手动管理更可靠且无额外性能损失。
所以，与其关注“子类在栈帧中怎么存”，不如聚焦：
- 写具体
catch，删掉无意义的catch (Exception) - 用防御性编程减少异常产生
- 让异常真正用于“异常”情况，而非常规控制流
- 日志带上下文，不丢堆栈，不滥打
这才能写出高性能、易维护、真健壮的错误处理结构。
