final类和方法的作用解析

`final` 关键字在Java中并非性能优化技巧，而是一种明确、强制的设计契约：用`final`修饰类可彻底禁止继承（如`String`），编译期即报错，连反射也无法绕过；修饰方法则锁定重写行为，保障核心逻辑不被意外覆盖，同时仍允许正常调用；值得注意的是，`final`类中的非`private`方法虽未显式声明`final`，但因类不可继承而天然具备不可重写性。真正决定是否使用`final`的，应是“该类或方法是否允许被扩展”的设计判断，而非对速度的模糊期待——滥用它会阻碍测试与灵活设计，而善用它则能清晰传达作者意图，提升系统健壮性与可维护性。

final修饰类会阻止继承

被 final 修饰的类无法被其他类继承，编译器会在 extends 处直接报错。这是最彻底的继承限制方式，适用于不希望行为被修改的核心类，比如 String、Integer 等 JDK 中的包装类。

常见错误现象：

class MyString extends String { }

• 子类定义时只要出现 extends 就会触发检查，与是否重写方法无关
• 接口实现（implements）不受影响，final 类仍可实现接口
• 反射也无法绕过该限制——Class.forName("...").getDeclaredConstructor().newInstance() 不会报错，但继承本身在编译期就被拦住

final修饰方法会阻止重写

被 final 修饰的方法不能在子类中被 @Override，但可以正常继承并调用。这常用于保护关键逻辑不被意外覆盖，比如模板方法模式中的骨架方法。

示例：

class Base {
    final void template() {
        init();
        process();
    }
    void init() { /* 可被重写 */ }
    void process() { /* 可被重写 */ }
}

• 子类能继承 template() 并调用，但不能声明同签名的 template() 方法
• 若子类试图重写，编译器报错：Cannot override the final method from Base
• 静态方法加 final 没有意义——静态方法本来就不可重写，只可隐藏（hide），而 final static 仅限制隐藏（即子类不能定义同名 static 方法）

final类里的所有方法默认隐式final

虽然语言规范没强制要求，但 JVM 层面将 final 类的所有实例方法视为不可重写。即使你没显式写 final，子类也无法继承该类，自然也就谈不上重写其任何方法。

注意点：

• 这不是语法糖，而是语义约束：final 类的字节码中，其方法不会出现在子类的虚方法表（vtable）查找路径中
• 反编译可见：javac 对 final 类中非 private 方法自动添加 ACC_FINAL 标志位
• private 方法本身不可见，所以是否 final 对继承无实际影响；但显式加上更明确

性能与设计意图要分开看

有人认为 final 能提升性能，因为 JIT 可能内联方法。这在极端场景下成立，但现代 JVM（如 HotSpot）已极少依赖 final 做激进优化——它更依赖运行时分析（如去虚拟化）。别为了“可能快一点”而滥用 final。

真正该问的是：这个类/方法的契约是否允许被扩展？如果答案是否定的，再加 final。

• 加 final 是一种设计决策，不是性能调优手段
• 过度使用会提高测试难度（无法 mock final 类/方法，需依赖 PowerMock 或改用接口）
• Lombok 的 @RequiredArgsConstructor 等注解对 final 字段有特殊处理，但和继承限制无关

final 关键字的继承限制效果是编译期强制的，不是靠约定或文档。最容易忽略的是：它不阻止组合，只阻止继承；也不影响字段初始化顺序或线程安全——那是 final 字段自己的事。

终于介绍完啦！小伙伴们，这篇关于《final类和方法的作用解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！