Java中所有非static、非final、非private的实例方法默认采用动态绑定，即虚调用，通过invokevirtual指令在运行时根据实际类型查找方法实现；private、static、final方法不参与虚分派。
Java里没有叫“虚方法”的东西，但所有非static、非final、非private的实例方法都是虚的
Java语言规范里压根没提“virtual method”这个词——那是C++/C#里的说法。Java的设计就是默认开启动态绑定：只要方法能被子类重写（override），调用时就一定查运行时类型，也就是“虚调用”。你不用加任何关键字，public void draw()、protected String toString()，甚至没写访问修饰符的包级方法，只要不是static、final或private，统统走虚分派。
常见错误现象：private void helper()在子类里“重写”，结果父类构造器里调用的还是父类版本，以为是虚方法失效了——其实是它根本不可见、不可重写，压根不参与动态绑定。
-
private方法：编译期绑定，连继承关系都不成立，更别说虚了 -
static方法：看声明类型，不是运行时类型；Parent p = new Child(); p.staticMethod()调的是Parent.staticMethod() -
final方法：可继承但不可重写，JVM仍按虚方法流程走，但实际不会跳转到子类实现（因为不存在）
为什么toString()、equals(Object)这些方法总像“自动变”一样
因为它们是典型的可重写实例方法，且常被框架或容器间接调用（比如System.out.println(obj)、list.contains(obj)）。你没显式写obj.toString()，但JVM在打印时会自动触发虚方法查找。
使用场景很直接：日志、调试、集合操作、JSON序列化——只要对象进了通用逻辑，它的行为就由实际类型决定，不是声明类型。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 参数差异无关紧要：虚调用只看方法签名（名称+参数类型），返回类型协变不影响分派
- 性能影响极小：现代JVM对热点虚调用会内联优化，除非频繁反射或接口多态爆炸
- 兼容性没问题：从Java 1到21，虚分派语义完全一致，没变过
invokespecial和invokevirtual指令的区别，决定了是不是“真虚”
字节码层面，虚方法调用对应invokevirtual指令；而super.xxx()、构造器、private方法用的是invokespecial——它不查运行时类型，只按字节码里写的符号引用去调。
容易踩的坑：在子类构造器里调super()之后立即调this.overridableMethod()，如果该方法被子类重写，此时子类字段可能还没初始化（父类构造器中调子类方法），导致NPE或脏数据——这不是虚方法的问题，而是构造顺序陷阱。
-
invokevirtual：查vtable，找运行时类型的最新实现 -
invokespecial：跳转到指定类的指定方法，绕过重写逻辑 - 反编译一个简单继承类就能看到这两种指令混用，比如
javap -c Parent
别被“所有普通方法都是虚的”带偏，真正关键的是“能不能被重写”
虚方法机制本身不难，难的是判断哪些方法真的开放给了子类。比如Object.clone()是protected且没实现深拷贝，Thread.run()是空方法，它们虽是虚的，但用错时机或没重写到位，问题就出在语义理解上，而不是分派机制。
最易被忽略的一点：接口默认方法（default）也是虚的，但多实现冲突时编译器强制你解决，运行时不会随机选一个——这和类继承的单继承虚调用逻辑不同，得留神。
