抽象类的构造方法在JVM中通过invokespecial指令调用，与普通类无异；JVM不区分抽象与否，只验证<init>方法是否存在、可访问及签名匹配，子类构造时必须显式或隐式调用抽象父类构造器以确保初始化链完整。
抽象类的构造方法在 JVM 中和其他普通类一样，通过 invokespecial 指令调用，**并不会因为“抽象”而跳过或特殊处理**。JVM 不关心类是否被 abstract 修饰，只关心调用目标是否满足 invokespecial 的语义要求：即必须是当前类、父类或接口中的实例初始化方法（<init>）、私有方法或被重写前的父类方法。
抽象类构造方法的本质
抽象类虽然不能被直接实例化（new AbstractClass() 编译不通过），但它仍可被继承，子类在构造时**必须显式或隐式调用父类（含抽象类）的构造方法**。这个调用最终编译为 invokespecial 指令，指向父类的 <init> 方法。
- JVM 在类加载阶段会为每个类（包括抽象类）生成
<init>方法，它和普通实例方法一样存在于常量池中，有完整的签名和字节码。 - 抽象类的
<init>方法可以包含任意逻辑（如字段初始化、参数校验等），和具体类无异。 - 编译器强制要求子类构造器第一行必须调用父类构造器（
super(...)或隐式super()），否则报错；这正是为了确保invokespecial调用链完整。
invokespecial 如何定位抽象类的 <init>
该指令执行时，JVM 根据操作数栈顶的 this 引用（即正在构造的子类实例）和常量池中符号引用（如 MyAbstractClass.<init>:(I)V），按以下规则解析：
- 查找当前类的直接父类（运行时类型确定），并在其方法表中匹配
<init>签名；抽象类作为父类时，其<init>方法必然存在且可访问（默认protected或包内可见）。 - 不进行动态绑定（即不会查子类重写版本），因为
<init>方法从不被重写——每个类的<init>是独立的，子类构造器调用的是父类自己的初始化逻辑。 - 若签名不匹配或方法不可见（如父类构造器为
private），则抛出IllegalAccessError（链接阶段）或VerifyError（验证阶段）。
字节码示例对比
假设有：
立即学习“Java免费学习笔记（深入）”；
abstract class Animal { Animal(String name) { /* ... */ } }
class Dog extends Animal { Dog() { super("dog"); } }
编译后，Dog.<init> 的字节码关键片段为：
aload_0 // 加载 this ldc "dog" // 加载字符串常量 invokespecial Animal.<init>:(Ljava/lang/String;)V // 调用抽象父类构造器
注意：invokespecial 的目标是 Animal.<init>，而非 Dog.<init> 或其他；JVM 执行时，会直接进入 Animal 类定义的 <init> 字节码，完成其初始化逻辑。
为什么不能用 invokestatic 或 invokevirtual？
这是由 JVM 规范强制约束的：
-
invokestatic只能调用静态方法，而<init>是实例方法，且必须在对象内存分配后（new+dup）才可执行，需依赖this引用。 -
invokevirtual基于运行时类型动态分派，但构造器调用必须精确到声明类型（父类），禁止多态——子类不能“绕过”父类构造器去调用祖父类，也不能被子类重写覆盖。只有invokespecial提供这种“非虚、确定目标”的语义。
不复杂但容易忽略：抽象性是 Java 语言层面的约束，JVM 字节码层只认 <init> 方法是否存在、是否可访问、签名是否匹配。只要子类构造器合法调用了抽象父类的 <init>，invokespecial 就照常执行，和具体类完全一致。
