final方法不能被子类重写，JVM对其静态绑定；常见错误是子类试图覆盖父类final方法；适用于模板方法模式中需锁定执行顺序的场景。
final方法不能被子类重写
这是final修饰方法最直接、唯一的作用：一旦某个方法被声明为final，任何继承该类的子类都不允许用@Override重新定义它。JVM在运行时会跳过对该方法的虚方法表（vtable）查找，直接绑定到具体实现——也就是“静态绑定”或“早期绑定”。
常见错误现象：javac报错 error: method xxx() cannot override xxx() in YYY; overridden method is final，通常是因为子类试图覆盖父类中带final的方法。
- 不是为了“防止误改”——IDE 和代码审查更管用；也不是为了“提升可读性”——
final本身不传达设计意图，需靠文档或命名补充 - 真正适用场景：框架/SDK 中暴露给用户的钩子方法（hook）必须稳定，比如
Spring Framework中AbstractApplicationContext.refresh()是final，确保启动流程不可篡改 - 性能影响极小，现代 JVM（如 HotSpot）对非
final方法也常做去虚拟化（devirtualization），所以别单纯为“性能”加final
final方法和private方法的区别
private方法默认不可见、不可继承，因此天然不能被重写；而final方法是显式开放可见（public/protected），但禁止重写。二者语义完全不同。
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 把一个本该是
private的方法写成public final，结果意外暴露了内部实现细节，破坏封装 - 误以为
final能阻止反射调用——其实AccessibleObject.setAccessible(true)仍可绕过访问控制，final不提供运行时安全 -
final方法里调用的其他非final方法，依然可能被子类改变行为，所以“不可变性”只限于该方法自身签名与主体
什么时候该用final修饰方法
关键判断标准不是“这个方法很重要”，而是“它的行为契约必须由父类完全掌控，子类不得参与定制”。这往往出现在模板方法模式（Template Method Pattern）中。
典型例子：
public abstract class DataProcessor {
// 模板方法：final，保证执行顺序
public final void process() {
validate();
transform();
save();
}
protected void validate() { /* 子类可重写 */ }
protected abstract void transform();
protected void save() { /* 子类可重写 */ }}
- 只有当整个算法骨架必须锁定时，才将模板方法设为
final；若只是某一步逻辑稳定，应提取为独立private或static工具方法 - 接口中不能使用
final修饰方法（Java 8+ 接口支持default和static，但不允许final） - 记录类（
record）的所有 accessor 方法（如getName()）自动是public final，这是语言强制，无需手动加
final方法对继承体系的实际约束力
final只限制语法层面的重写，不阻止逻辑等价替换。子类仍可通过组合、代理、重载（overload）甚至字节码增强（如 Byte Buddy）绕过限制。
真正难处理的是隐式依赖：
- 如果一个
final方法内部调用了static工具类，而该工具类行为可变，那“不可变”的假象就容易被打破 - 多线程环境下，
final方法不提供同步保障——它不等于synchronized，也不保证内部状态可见性 - 测试时若依赖 mock 框架（如 Mockito），
final方法默认无法被 mock（除非启用 inline mock 模式），这点常被忽略
所以加final前，先确认你真正想锁住的是什么：是调用入口？执行路径？还是语义契约？三者并不总是一致。
