Java动态绑定、枚举单例和密封类分别在运行时方法调用、类加载期实例化、编译期继承控制三个层面实现精准类型约束：动态绑定依赖vtable/ITABLE查表机制；枚举单例由JVM类初始化锁和序列化特殊处理保障唯一性；密封类通过编译器校验+字节码标记+JVM加载验证构成全闭合体系。
Java 的动态绑定、枚举单例和密封类，三者看似独立，实则共同服务于一个目标：在运行时或编译期对类型行为施加精准控制。它们分别作用于方法调用、实例生命周期和继承边界，理解其底层机制的关键不在于死记规则，而在于看清 JVM 如何在不同阶段“做决定”。
接口方法调用走的是 ITABLE 查找，不是 vtable
接口的动态绑定和类的动态绑定表面相似，但实现路径完全不同。当调用 obj.interfaceMethod() 时，JVM 不查该对象所属类的 vtable，而是查找其类型对应的 ITABLE（Interface Method Table）。
- ITABLE 是每个类在加载时为它实现的所有接口单独生成的一张表，每张表记录该类对该接口中每个默认/抽象方法的具体实现地址
- 因为一个类可实现多个接口，且接口方法可能同名同签名（如多个接口都定义了 run()），JVM 必须先定位到目标接口的 ITABLE，再从中取方法入口——这比 vtable 多一层间接寻址，开销略高
- 接口的 default 方法参与动态绑定，但 static 接口方法仍是静态绑定；接口本身不能被实例化，所以所有接口方法调用都依赖实际运行时对象的真实类型
枚举常量是类加载阶段完成的线程安全单例
枚举单例不是靠代码逻辑“防重”，而是 JVM 在类初始化阶段天然保障的不可变事实。
- 每个枚举常量都被编译为 public static final 字段，在 <clinit> 方法中按顺序初始化，而 JVM 对类初始化实行全局锁，确保同一枚举类只执行一次 <clinit>
- 反编译可见其构造器为 private，且无 public 构造途径；反射调用 Enum.valueOf() 返回的也是已有常量，不会新建实例
- 序列化机制对枚举有特殊处理：反序列化时直接返回原常量引用，绕过构造过程，彻底杜绝“伪造单例”可能
密封类通过编译期校验+运行时类型检查实现全闭合
密封（sealed）不是运行时约束，而是一套由编译器强制、字节码标记、JVM 验证协同完成的封闭体系。
立即学习“Java免费学习笔记（深入）”；
- 父类必须用 sealed 声明，并显式列出所有允许的子类（permits），这些子类必须标注为 final、sealed 或 non-sealed
- 编译器在编译子类时会检查其是否在父类的 permits 列表中；若缺失或拼写错误，直接报错，不生成 class 文件
- JVM 加载类时会验证密封关系：若发现某类声称 extends 一个 sealed 父类，但未被列在 permits 中，抛出 IncompatibleClassChangeError
- 这种机制让 switch 表达式可穷举所有子类型（无需 default 分支），也让 IDE 和静态分析工具能准确推导类型覆盖范围
这三者共同体现了 Java 类型系统演进的方向：从运行时多态（动态绑定），到加载期不可变性（枚举单例），再到编译期可验证封闭性（密封类）。它们不是替代关系，而是分层加固——越早约束，越少意外。
