final类禁止继承，编译期报错；final方法禁止重写，保障关键逻辑不被修改；二者语义独立，不影响内部成员可变性，也不提供线程安全。

final 类：子类编译报错 Cannot inherit from final 'XXX'

用 final 修饰类，就是彻底关掉继承这条路。JVM 在编译期就检查，一旦发现 extends 一个 final 类，立刻报错，不给运行机会。

典型场景是工具类、不可变类型（比如 String）、或你明确不希望被扩展的配置封装类。

• 别在抽象类或有 protected 成员的类上乱加 final——逻辑自相矛盾
• 如果类里已有 private 构造器，再加 final 是冗余的，但不冲突
• 注意 Lombok 的 @UtilityClass 默认会把类设为 final，和手写 final class 效果一致

final 方法：子类重写时报错 Cannot override final method

final 方法不能被子类覆盖，但可以被正常调用。它不是为了“封死行为”，而是防止子类无意/恶意改变关键逻辑——比如模板方法模式里的钩子点、安全校验入口、或缓存计算逻辑。

常见误用是给所有 private 方法加 final：没必要，private 方法本就不能被继承，加了也无意义。

立即学习“Java免费学习笔记（深入）”；

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 接口中不能声明 final 方法（Java 8+ 接口允许 default 和 static，但不允许 final）
• 父类方法已是 final，子类即使声明同签名方法，也会被编译器识别为“试图重写”，直接报错
• 使用 @Override 注解标注 final 方法会编译失败——注解本身要求可重写

final 与性能：JIT 优化 ≠ 你该手动加 final

有人听说 “final 方法能内联”，就挨个加，这是过时认知。现代 HotSpot JIT 对非 final 方法同样做虚函数去虚化（devirtualization），只要运行时类型稳定，内联照常发生。

真正影响性能的是语义清晰性：final 让 JVM 更早确定调用目标，但这个收益对绝大多数业务代码可忽略。

• 不要为“性能”理由给每个工具方法加 final
• 如果类/方法设计上本就不该被继承或重写，才加 final——这是契约，不是优化开关
• Spring AOP 代理（CGLIB）无法代理 final 类或方法，这点比性能更重要，容易踩坑

final 类里还能有 non-final 方法吗？当然可以

可以，而且很常见。final 修饰类只管“能不能被继承”，不管内部成员是否可变。类是 final 的，里面的方法可以是 public、protected、private，也可以带或不带 final。

比如 java.lang.Integer 是 final 类，但它的 intValue()、toString() 都没加 final——因为不需要封住这些行为，只需要确保没人能继承它改写整体语义。

• 别混淆“类不可继承”和“方法不可重写”：二者独立控制
• 如果一个 final 类里某个方法逻辑特别关键，又怕被反射篡改（极少见），才额外加 final；否则不加
• IDE 自动生成的 getter/setter，加不加 final 完全看设计意图，不是语法强制

最常被忽略的一点：final 不提供线程安全。一个 final 类的实例字段如果是可变对象（比如 final List<string> list = new ArrayList();</string>），外部仍可修改 list 内容——final 只保证引用不变，不保证对象状态不变。