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免费学习笔记（深入）”；
- 接口中不能声明
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 List<string> list = new ArrayList();</string>），外部仍可修改 list 内容——final 只保证引用不变，不保证对象状态不变。 
