密封类switch不生成lookupswitch指令，而是编译期基于子类静态信息生成tableswitch或优化if-else链；真正触发lookupswitch的是字符串switch或稀疏int值switch。
密封类（sealed class）本身不直接生成 lookupswitch 指令。Java 的 switch 语句对密封类实例的匹配，是在编译期通过其具体子类的 enum 或 int 常量索引间接实现的，而非运行时靠 lookupswitch 查找密封类对象本身。
密封类 switch 实际依赖的是编译期类型分发
Java 编译器将密封类 switch（尤其是配合 instanceof 模式匹配或 record 模式）转化为基于子类静态信息的跳转逻辑。例如：
- 若密封类有 3 个 final 子类，编译器可能为其分配固定 ordinal 值（类似枚举），再生成
tableswitch——前提是这些子类在编译期可穷举且顺序稳定； - 若子类数量少、结构简单，也可能直接展开为优化后的 if-else 链，不生成任何 switch 指令；
-
lookupswitch不会出现在密封类直接作为 switch 表达式条件的字节码中，因为它只处理整型键值对，而密封类是引用类型。
真正能观察到 lookupswitch 的场景是字符串或稀疏整型 switch
如果你在密封类相关代码中反编译出 lookupswitch，那大概率是以下情况之一：
- 你在 switch 中用了
someSealedInstance.getClass().getSimpleName()这类字符串表达式——此时触发的是字符串 switch 机制，底层调用hashCode()后走lookupswitch； - 你手动把子类映射成稀疏 int 值（如用 static final int CODE_A = 1001; CODE_B = 2048;），再 switch 这些值——这时才可能因范围过大、密度低而触发
lookupswitch； - 混淆或反编译工具误标指令，实际是
tableswitch或其它分支逻辑。
验证密封类 switch 效率应关注模式匹配字节码结构
要确认密封类 switch 是否高效，更应检查：
- 是否启用
--enable-preview（Java 17+）或使用 Java 21+ 正式版，确保记录模式和密封类模式匹配被正确编译； - 用
javap -v查看是否生成了checkcast+goto或紧凑的tableswitch，而非大量if_acmpne； - 是否存在重复的
instanceof判定——高效实现应只做一次类型检查并复用结果； - 是否避免了
toString()或name()等运行时字符串操作，这类操作会引入lookupswitch和哈希碰撞校验开销。
密封类 + 记录模式才是现代高效写法
例如：
switch (obj) {
case Person(String n, int a) -> System.out.println(n);
case Animal(String kind) -> System.out.println(kind);
case null -> throw new NullPointerException();
}
这段代码编译后不会产生 lookupswitch，而是：
- 先判断
obj是否为Person或Animal类型（instanceof指令）； - 类型匹配后直接字段解构（
getfield）； - 整个流程无哈希计算、无字符串比较、无 equals 调用——这才是密封类 switch 的性能优势所在。
