final类本身不直接触发JVM内联，但其方法因不可重写而省去虚方法查表，内联与否取决于方法大小、调用频率和JIT阈值，而非是否final。
final类真能被JVM内联吗
不能。JVM的内联决策基于方法调用热点和是否可被重写，final类本身不触发额外内联——但它的所有方法自动成为final方法，这消除了虚方法调用（virtual call）的间接跳转开销。真正起作用的是方法不可重写这一事实，而非类加了final这个修饰符。
常见错误现象：final类里一个大方法没被内联，有人就以为“加了final怎么还不优化”。其实JVM只对频繁执行的小方法内联，比如String.length()这种，跟类是否final无关；而final带来的收益是让JIT不用检查子类覆盖，省掉一次查表（vtable lookup）。
- 内联与否看方法大小、调用频率、JIT编译阈值（默认10000次），不是看
final -
final类的方法在字节码层面就是ACC_FINAL，JIT看到后跳过动态绑定流程 - 如果方法体超过35字节（HotSpot默认），大概率不会内联，哪怕它是
final
不加final反而可能影响性能
非final类的方法默认可被继承重写，JIT必须为每次调用预留“可能被子类覆盖”的路径。即使当前没子类，JIT初期也会按虚方法处理，直到确认无子类加载（通过Class.forName或动态代理等触发类加载时才可能改变判断）。
使用场景：高频调用的工具类，如Objects.equals()、Collections.emptyList()，它们都是final类——不是为了“强制不可继承”，而是让JIT早一点放弃虚调用假设。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 子类在运行时才加载？JIT可能已按虚方法编译，后续需去优化（deoptimization），带来卡顿
- 使用
-XX:+PrintCompilation能看到类似123 b java.lang.String::hashCode (67 bytes)，带b表示已内联；若没b且方法是final的，说明它太大或不够热 - Android ART上
final类还有AOT预编译优势，但OpenJDK HotSpot主要靠JIT阶段受益
final类的真正代价在扩展性上
加final不是性能开关，是设计契约。一旦加了，别人没法继承、没法Mock（除非用PowerMock）、没法做装饰器包装——这些在测试和框架集成中比“少一次vtable查表”现实得多。
容易踩的坑：为了一点理论上的JIT优势，把StringUtils这类工具类设为final，结果单元测试里想打桩isBlank()却只能改用ReflectionTestUtils绕过去，或者被迫改成静态方法+接口抽象，反而更重。
- Spring、Guava、Apache Commons里大量工具类没加
final，性能没差，维护性更好 - 只有当类明确“绝不该被继承”且方法极小、极热（如
ImmutableList的get()），final才值得 - 现代JVM（JDK 17+）对未
final但实际无子类的类，也能做“推测性内联”（speculative inlining），失败时再退回去——所以收益进一步收窄
要不要加final，看三点
别凭感觉，盯住这三个具体信号：
- 这个类有没有被继承的需求？比如
AbstractList必须非final，而EmptyList可以是final - 它的方法是否在循环/IO密集路径里被高频调用？用
jstack -l或async-profiler确认热点 - 项目是否禁用反射/动态代理？如果用了Lombok
@Data或MyBatis，非final类更安全
性能差异通常在纳秒级，而改错一个final带来的重构成本可能是小时级。真要榨干性能，不如先看GC日志和锁竞争。
