调高-xx:maxinlinesize对高频轻量方法（如getter/setter）可减少调用开销，但需确认内联被拒是瓶颈；应结合-xx:+printinlining等参数诊断，优先优化方法结构而非盲目调参。
直接调高 -XX:MaxInlineSize 并不能“一键加速”变量调用，但它对高频、轻量、非热点的核心访问方法（如 getter/setter、状态检查）确实能立竿见影地减少调用开销——前提是方法字节码略超默认阈值，且你已确认内联被拒是性能瓶颈。
先看日志，别猜内联是否发生
启用诊断参数，让JIT告诉你真实决策：
-
-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions：输出每处调用的内联结果 -
-XX:+PrintCompilation：配合观察哪些方法进入了C2编译（含C2标识） - 重点关注含 not inline (hot) because: too big 的行——这说明方法体超了
MaxInlineSize，但已被识别为热点，值得调优 - 若看到 virtual call 或 unstable if，问题不在大小，而在多态或分支，此时调参无效
只动关键方法，小步试探
-XX:MaxInlineSize 默认为 35（字节码指令数，不是源码行数），适用于启动期或中频调用的关键访问方法。调整时需聚焦场景：
- 典型目标：如
isLocked()、getVersion()、nextId()等无分支、无异常、无同步的纯访问方法 - 实测常见情况：一个带 final 字段读取的 getter 编译后约 4–6 条字节码；若含空校验或简单逻辑，可能达 38–42，刚好卡在默认阈值外
- 建议从
-XX:MaxInlineSize=40开始，每次 +5 测试；超过 60 需谨慎——代码缓存压力上升，反而可能拖慢 L1 指令缓存命中
搭配使用，避免副作用
单改一个参数容易顾此失彼。应与以下参数协同控制内联质量：
-
-XX:InlineSmallCode=1000：限制内联后生成的机器码体积上限（单位字节），防止因过度内联导致函数体膨胀 -
-XX:MaxTrivialSize=6：对极简方法（如单 return、单字段读）启用无条件内联，无需计数，适合最核心的变量访问 -
-XX:+UseInlineCaches（默认开启）：提升虚方法内联判断效率，尤其在有少量子类覆盖时更稳定 - 不推荐盲目提高
-XX:MaxInlineLevel：它管的是调用链深度（默认9），对单个 getter/setter 无实质帮助
比调参更有效的前置动作
很多“调不快”的问题，根源不在阈值，而在方法本身是否利于内联：
- 把
public int getValue()改成private final int getValue()或直接private static工具方法——消除虚调用不确定性，JIT 可直接内联 - 移出 getter 内的
Objects.requireNonNull()、日志开关判断等非核心逻辑，它们会增加字节码并引入分支 - 避免在变量访问路径中混入
synchronized、try-catch或 Lambda 表达式——这些结构天然抑制内联 - 用
javap -c查看目标方法的字节码长度，确认是否真超限（例如aload_0; getfield; ireturn共 3 条，远小于 35）
