Java普通方法调用开销大，需保存PC、压栈、传参、跳转、执行、弹栈、恢复上下文；add(int a,int b)类方法调用开销常超总耗时60%，虚方法因查vtable等更慢。
方法调用开销到底有多大？
Java里一次普通方法调用，不是“跳过去执行完再回来”那么简单。它要：保存当前pc（程序计数器）、压入新栈帧、传参、跳转、执行、弹栈、恢复上下文——这些加起来，在高频场景下可能比方法体本身还慢。比如add(int a, int b)这种两行代码的方法，调用开销常占总耗时 60% 以上。
- 虚方法（非
private/final/static）开销更大，因为要查虚方法表（vtable） - 小对象参数会触发逃逸分析判断，间接拖慢调用路径
- 在循环内调用，比如
for (int i = 0; i ，开销会被放大 N 倍
JIT 是怎么决定内联的？
JIT 不是“看到小方法就内联”，它有一套动态决策逻辑：先看是不是热点（调用次数或回边次数超阈值），再看是否满足内联条件。默认只对 ≤35 字节码的方法开放内联通道，且优先处理 private、final、static 方法。
-
-XX:MaxInlineSize=35是字节码长度上限，不是源码行数；return x * x;约 5 字节，但带空检查或日志语句就容易超 - 即使方法很小，若被标记为虚方法（如接口实现类），JIT 需做类层级分析（CHA），失败则放弃内联
- 内联有深度限制，默认最多嵌套 9 层（
-XX:MaxInlineLevel=9），链式调用如a().b().c()可能只内联前两层
怎么确认你的方法真被内联了？
别猜，用 JVM 自带的日志看真实决策。加 -XX:+PrintInlining 运行，输出里出现 inline (hot) 或 won't inline (too big) 就是铁证。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 常见误判：日志里写
did not inline (call site is hot)—— 表示调用点热，但目标方法没被选中，得查方法签名或大小 - 搭配
-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation可生成hotspot_pid*.xml，用 JITWatch 工具可视化分析 - 注意：
-XX:+PrintInlining仅对 C2 编译生效（Server 模式），Client 模式或未达编译阈值时不输出
哪些写法会悄悄阻止内联？
很多看似无害的写法，会让 JIT 直接放弃内联，而且不报错、不警告。
立即学习“Java免费学习笔记（深入）”；
- 方法体里有
synchronized块（哪怕锁的是局部对象）→ 触发同步膨胀检测，大概率拒内联 - 用了
java.lang.invoke.MethodHandle或反射调用 → JIT 无法静态确定目标，绕过内联流程 - 方法声明在接口中，且运行时实现类不止一个（如 Spring AOP 代理后出现多个子类）→ CHA 失败，降级为“monomorphic”甚至“megamorphic”调用
- 方法含
System.out.println或任意 I/O 调用 → 字节码膨胀 + 副作用不可控，JIT 主动规避
内联不是编译期宏替换，它是运行时基于统计和约束的保守决策。最常被忽略的一点：哪怕你把所有条件都配对了，只要方法在首次编译时尚未成为热点，它就不会进 C2 编译队列——也就没有机会被深度内联。
