final修饰方法是编译期强制禁止重写的契约保障手段，核心价值在于稳定调用路径与确保语义正确性，而非直接提升性能。

直接用 final 修饰方法，是 Java 中最硬性的手段——编译期就拒绝重写，不给运行时留任何绕过余地。它不提升“算法速度”，但能稳定调用路径，让 JVM 更早确定行为，间接支持优化。关键不在性能，而在契约落地。

哪些方法必须加 final

不是所有方法都值得锁死，重点保护那些一旦被改写，就会导致业务错乱、安全失守或兼容崩塌的逻辑：

• 支付校验入口（如 validatePayment()）：子类跳过签名验签，直接放行伪造请求
• 状态机核心跃迁（如 transitionToShipped()）：防止绕过库存扣减、物流单生成等前置检查
• 模板方法中的骨架流程（如 executeOrder()）：它调用可扩展的钩子（doNotify()、doLog()），自身必须不可动
• 已上线多年、被数十个子类依赖的旧方法：加 final 是一种兼容性兜底，避免某次重构意外破坏调用方语义

怎么写才真正生效

语法位置要准，语义边界要清：

• 写在访问修饰符之后、返回类型之前：public final BigDecimal calculateFee(...)，别写成 final public（虽不报错，但违反约定）
• 只对 public 和 protected 实例方法加 final；private 方法天然不可见，加了纯属冗余
• static 方法不用加 final——它本就不能被重写，只能被隐藏，加了无实际约束力
• 接口里不能声明 final 实例方法（Java 8+ 的 default 或 static 方法也不允许加 final）

别踩这些实战坑

加 final 不是贴封条，而是做设计决策，常见翻车点：

• 单元测试时 Mockito 默认无法 mock final 方法，需启用 mockito-inline 并配置 mock-maker-inline 文件，否则测试直接失败
• Spring 的 @Transactional、@Cacheable 在 final 方法上会静默失效——CGLIB 代理生成不了子类，JDK 代理又没接口，调用直接走原方法，事务/缓存全丢
• 加了 final 后若真要定制逻辑，子类只能复制整段代码再改，违背开闭原则；不如提前抽成策略接口 + 组合，把可变部分外移
• 和 @Override 共存会编译失败，IDE 可能不提示，但 CI 上 javac 一定拦住，建议把编译检查纳入流水线

效率提升是副产品，不是目标

JVM 对 final 方法可能做内联（inline），但这依赖热点判定和调用稳定性，不是写上就生效。现代 HotSpot 对非 final 方法同样能去虚化（devirtualize）。真正影响执行效率的是逻辑是否清晰、分支是否收敛、对象是否逃逸——而不是多一个 final 关键字。把它当作设计意图的表达，比当作性能开关更稳妥。