Java方法重载只看参数列表(个数、类型、顺序),返回类型、修饰符、throws等均无关;需避免varargs与固定参数冲突、泛型擦除导致的歧义,以及重载与重写的混淆。

Java 中方法重载(Overloading)不是“能不能做”,而是“怎么写才被编译器认作不同方法”——关键不在名字,而在 参数列表 的结构是否可区分。
方法重载只看参数列表,返回类型无关
编译器判断两个方法是否构成重载,**完全忽略返回类型**。哪怕 int add(int a, int b) 和 String add(int a, int b) 同时存在,编译直接报错:duplicate method add(int, int)。
- 必须改变:参数个数、参数类型、参数顺序(如
(int, String)vs(String, int)) - 不能仅靠:返回类型不同、访问修饰符不同、
throws声明不同 - 注意:自动拆箱/装箱可能引发意外匹配,比如
void foo(Integer i)和void foo(int i)不能共存(调用foo(5)时编译器无法确定选哪个)
常见错误:重载与重写的混淆
重载发生在同一个类中,是编译期行为;重写(Override)是子类改写父类方法,是运行期行为。二者规则互不干扰,但容易因命名习惯误踩坑:
-
@Override注解只能用于重写,加在重载方法上会编译报错:method does not override or implement a method from a supertype - 若父类有
void print(Object o),子类定义void print(String s)——这是重载,不是重写,@Override不合法 - 重载方法之间无继承关系,JVM 不参与分派;重写才涉及动态绑定和多态
可变参数(varargs)的重载陷阱
void log(String... msgs) 看似灵活,但和 void log(String msg) 共存时,编译器优先选择更具体的匹配,即单个 String 参数版本。但以下组合会出问题:
立即学习“Java免费学习笔记(深入)”;
void handle(int... nums) void handle(int n, int... rest)
调用 handle(1) 时编译失败:reference to handle is ambiguous,因为两个方法都可接受单个 int 参数。
- varargs 必须是参数列表最后一个元素
- 避免让 varargs 方法与“相同前缀 + 更少固定参数”的方法共存
- 必要时用明确类型(如
List)替代 varargs,提升可读性和可重载性
泛型方法重载的特殊限制
Java 泛型是类型擦除实现,所以 和 可以重载,但 和 void process(String s) 就不行——擦除后都是 process(Object) 和 process(String),看似不同,实则第一个泛型方法擦除后变成 process(Object),而 String 是 Object 子类,调用 process("hi") 时编译器可能选错,甚至报错。
- 泛型方法的重载安全边界:依赖参数类型是否在擦除后仍可区分
- 推荐做法:优先用具体类型方法覆盖常见场景,泛型方法作为兜底,而非并列重载
- IDE(如 IntelliJ)常标黄提示 “Unchecked generic call”,这往往是重载歧义的前兆
重载真正的复杂点不在语法,而在调用时的解析逻辑——编译器要从所有候选方法中选出最具体的那个,而这个过程受自动类型转换、装箱拆箱、varargs 展开、泛型擦除共同影响。写的时候看着没问题,一调用就报错或走错分支,往往是因为没把参数类型的“实际可匹配路径”想全。










