静态分派发生在编译期，依据引用类型选择重载方法；动态分派发生在运行时，依据实际对象类型选择重写方法；二者协同工作，先静态后动态。
静态分派发生在编译期，只看引用类型
Java 的方法重载（overload）是典型的静态分派场景。编译器在编译时就决定调用哪个重载版本，依据是变量的**声明类型**（即引用类型），而不是运行时实际对象类型。
常见错误现象：NullPointerException 没抛出，但调用的却是 print(Object) 而不是你预期的 print(String)，因为传入的是 Object obj = new String("hello") —— 编译器只认 obj 是 Object 类型。
- 重载方法选择完全由参数的**编译期类型**决定，和运行时值无关
-
final修饰的引用不会改变静态分派结果；var推导出的类型也参与静态分派 - 泛型擦除后，
List<string></string>和List<integer></integer>在重载中都视为List，容易导致意外匹配
动态分派依赖运行时对象类型，只对实例方法生效
方法重写（override）触发动态分派，JVM 在运行时根据对象的实际类（而非引用类型）查找并执行对应版本的 invokevirtual 指令。
使用场景：多态接口调用、模板方法模式、策略切换等需要运行时行为变化的地方。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 只有
public/protected/ 包级可见的非static、非final、非private实例方法才参与动态分派 -
static方法看似能“重写”，实则是隐藏（hiding），调用目标由引用类型决定 —— 属于静态分派 -
private方法不能被重写，子类里同名方法是全新方法，不参与任何分派
重载 + 重写混用时，先静态再动态
当一个调用既涉及重载又涉及重写（比如父类引用指向子类对象，且多个重载方法中某个被重写），JVM 分两步走：先按参数类型选重载版本（编译期），再按对象实际类型选重写实现（运行期）。
容易踩的坑：show(List) 和 show(ArrayList) 都存在时，传 new ArrayList<string>()</string> 会进 show(ArrayList)；但如果把参数改成 Object list = new ArrayList()，就只能匹配 show(List) 或更宽泛的 show(Object) —— 因为静态分派阶段已丢失 ArrayList 类型信息。
- 重载决策永远优先于重写，二者不在同一层机制里
- 数组类型如
String[]和Object[]在重载中是不同签名，但String[]是Object的子类型，可能触发意外交叉匹配 - 自动装箱/拆箱会引入隐式重载候选，例如
int可匹配method(int)、method(long)、method(Integer)，编译器按优先级选，但容易误判
如何验证当前调用走的是静态还是动态分派
最直接的方式是看字节码：javap -c YourClass。静态分派的方法调用通常对应 invokestatic（static 方法）或 invokestatic/invokespecial（构造器、私有方法、super. 调用）；而动态分派一定是 invokevirtual（实例方法）或 invokeinterface（接口方法）。
另一个轻量方式：在各重载/重写方法里加日志，用不同引用类型调用，观察输出是否随声明类型或实际类型变化。
- 如果换引用类型（如
A a = new B()→B b = new B()）导致调用方法不同，说明是静态分派 - 如果只换实际对象类型（如
A a = new B()→A a = new C()），调用方法随之变化，说明是动态分派 - 注意 IDE 的“Find Usages”可能误导——它基于源码分析，不反映运行时绑定逻辑
