JIT 编译与性能优化

• PrintCompilation 的输出格式
• 编译级别与状态
• 解读 JIT 编译行为

-XX:+PrintCompilation 会输出 JIT 编译事件日志，每行形如：timestamp compilation_id attributes flags owner compiled_method，其中 timestamp 是编译开始时间，compilation_id 是编译编号，attributes 表示编译状态（如 % 表示 OSR 栈上替换、s 表示 synchronized 方法、! 表示异常处理、n 表示 native 等），flags 表示编译级别（C1/C2，如 1/2/3/4），owner 是编译线程，compiled_method 是方法签名。通过解读日志可了解：哪些方法被编译、编译级别（C1 快速编译还是 C2 深度优化）、是否发生 OSR、是否多次重新编译（去优化）。这在定位"方法未按预期编译"或"编译开销过大"时很有用。

PrintCompilation 是 JIT 编译行为的"账本"，记录编译时机、级别与状态。结合编译级别（1-4）与 OSR/去优化标记，可判断 JIT 是否按预期工作。

• CompressedOops 的作用
• 内联缓存（Inline Cache）机制
• 指针压缩与缓存的影响

-XX:+UseCompressedOops 启用压缩对象指针，把 64 位对象引用压缩为 32 位，从而减少对象头与引用占用、提升缓存命中与内存利用。内联缓存（Inline Cache）是 JIT 为多态/虚方法调用做的优化：缓存调用点的目标方法，避免每次查虚方法表。CompressedOops 对内联缓存的影响在于：压缩指针改变了对象引用的表示与地址计算（需经过解压/偏移），使 JIT 生成的访问代码更紧凑，减少引用占用的内存和带宽，从而提升缓存利用率；但压缩指针的解压指令等操作也可能增加少许代码开销。总体而言，CompressedOops 通过缩小对象与引用、改善局部性，对依赖内联缓存与方法调用的热点代码通常有正面影响，但需在具体场景下评估。

CompressedOops 的价值在"内存局部性"，它让更多对象/引用驻留缓存，间接提升内联缓存与整体访问效率。代价是地址计算多一步解压，需权衡堆大小与受益。

• CodeCache 耗尽的现象
• 征兆与日志
• 先排查的根因

CodeCache 存放 JIT 编译的机器码，耗尽时会出现：日志中出现 "CodeCache is full" 或 "Compiler thread can't allocate" 警告，JIT 编译被暂停（编译线程停止），方法退化为解释执行，导致性能骤降（热点方法不再被编译）。性能征兆是 CPU 升高、吞吐下降、方法调用变慢。扩容前应先排查根因：是否因代码量过大（方法过多/过大）导致编译过多、是否因去优化/重新编译频繁、是否因方法内联层次过深、是否因 JIT 编译策略（如分层编译全量编译）导致匹配不足。排除了异常后再考虑 -XX:ReservedCodeCacheSize 扩容，避免掩盖问题。

CodeCache 耗尽的首要应对是"找出为何编译量过大"，而非盲目扩容。根因常是代码量、编译策略或去优化问题，扩容只是手段。

• CompileCommand 的用法
• 编译指令类型
• 编译指令文件

CompileCommand 是 JVM 提供的编译控制命令，用于对指定方法施加编译策略，如 -XX:CompileCommand=inline,com.example.Foo::bar（强制内联）、exclude（禁止编译）、dontinline（禁止内联）、compileonly（只编译指定方法）、print（打印编译信息）等。多个 CompileCommand 可写入编译指令文件（-XX:CompileCommandFile=file），便于批量管理。这些指令用于调试、调优或规避 JIT 的异常行为（如强制/禁止某方法内联、排除有问题的编译）。它们是 JIT 的"手动干预"手段，需谨慎使用。

CompileCommand 提供对 JIT 的细粒度控制（内联、排除、编译范围），配合编译指令文件可批量应用。它适合定位编译器问题或做针对性优化，但生产环境应谨慎。

• 分层编译的级别
• C1 与 C2 的分工
• 热点计数器与编译阈值

HotSpot 分层编译（Tiered Compilation）把编译分为多个级别：解释执行（0）、C1 简单编译（1）、C1 带性能分析（2/3）、C2 深度优化（4）。其思想是：先用 C1 快速编译让方法尽快获得编译性能（避免长时间解释执行），同时用 C1（带分析）收集运行时画像（如接收者类型、分支情况），当方法真正成为热点后，再用 C2 基于画像做深度优化（内联、逃逸分析、向量化等）。热点计数器（Invocation Counter + Backedge Counter）统计方法调用次数与循环回边次数，编译阈值（-XX:CompileThreshold 等，分层下为各层阈值）决定何时触发编译/升级。解释器与 C1 维护计数器，达到阈值后触发 C1→C2 的升级编译，从而"快速获得收益 + 深度优化峰值"。

分层编译的核心是"先用 C1 快速上车，再用 C2 深度优化"：C1 提供即时编译性能，C2 提供峰值性能，热点计数器与阈值决定升级时机。这样兼顾启动速度与峰值吞吐。

• JEP 483 AOT 类加载缓存
• 与运行期 JIT 的分工
• 改善启动 vs 提升了吞吐

JEP 483（AOT Class Loading Cache，JDK 24）把类加载过程（验证、解析、常量池、类元数据）的结果缓存到 AOT 缓存（磁盘），后续启动时直接加载，跳过重复的类加载工作，从而缩短启动时间。它与运行期 JIT 的分工是：JEP 483 优化的是"类加载/启动阶段"，而 JIT 优化的是"运行期编译与执行"。JEP 483 主要改善启动时间（冷启动更快），而非稳定运行吞吐——因为稳定运行期吞吐由 JIT 编译与热点优化、GC 等决定，类加载缓存只影响启动开销。这也解释了为何它适合缩短启动、减少启动期 CPU 峰值，但对长期稳定吞吐贡献有限。

关键区分"启动阶段"与"运行阶段"：JEP 483 属于启动优化（类加载缓存），JIT 属于运行期优化。因此它改善的是启动时间，而非稳定吞吐。

• JEP 484 的能力
• 字节码分析/转换
• 与 JIT 编译管线的边界

JEP 484（Class-File API）提供解析、生成和转换 Class 文件的 API，支持读取类文件结构（常量池、字段、方法、属性）、构建新类文件、以及遍历/修改字节码。它面向的是"类文件层面的分析和转换"，如热更新、字节码增强、框架二次开发、静态分析工具。与 JIT 编译管线的边界：Class-File API 操作的是"类文件（字节码）"这一层的静态结构，属于编译前/加载期的工具；而 JIT 编译管线运行在 JVM 运行时，把字节码编译为机器码并做热点优化。两者是"类文件处理"与"运行期编译"两个不同阶段，边界清晰：Class-File API 不参与 JIT 的机器码生成，JIT 也不直接使用 Class-File API 做类文件级操作。

边界在于"静态类文件 vs 运行期编译"：JEP 484 处理类文件结构（字节码层面），JIT 处理机器码（运行期）。理解边界可避免混淆"字节码增强"与"JIT 优化"。

• LambdaMetafactory 的作用
• invokedynamic 与 Lambda
• JIT 对 Lambda 的优化

Lambda 表达式在字节码层面通过 invokedynamic 指令和 LambdaMetafactory 引导方法实现：javac 不直接生成匿名内部类，而是生成立即求值的 bootstrap 方法，运行时由 LambdaMetafactory 根据函数式接口动态生成 Lambda 实现类/方法。JIT 与 LambdaMetafactory 的协作体现在：JIT 能对 invokedynamic 调用点做内联优化，对 LambdaMetafactory 生成的适配器方法做内联/去优化，并利用类型画像优化调用；同时，LambdaMetafactory 生成的类通常很小、生命周期短，JIT 与 GC 都能高效处理。相比每次创建匿名内部类，LambdaMetafactory 避免了每次抛出新的类/开销，配合 JIT 的内联能让 Lambda 调用接近直接方法调用。

Lambda 由 invokedynamic + LambdaMetafactory 动态生成，JIT 对其调用点做内联与优化，从而让 Lambda 开销接近直接调用。这是"语言特性 + 字节码 + JIT"协同的典型。

• Jaotc 的 AOT 机制
• GraalVM 的 Native Image
• 两者的差异

Jaotc 是 JDK 自带的 AOT 编译器，把 Java 类编译为原生机器码（库文件），供 JVM 启动时加载，仍基于 HotSpot 运行时不依赖反射的部分做了预编译，但运行时仍需 JVM、且动态特性受限。GraalVM 的 Native Image 是更彻底的 AOT：基于"封闭世界假设"（closed world），在构建期静态分析可达性，把整个应用（含静态初始化结果）编译为独立可执行文件，无需 JVM 运行，启动快、内存占用低，但通过反射/动态代理/字节码生成等动态特性时需额外配置（-H:ReflectionConfigurationFiles 等）。差异：Jaotc 是"HotSpot 内预编译部分方法"，运行时仍需 JVM、保留动态能力；Native Image 是"整应用静态编译为可执行文件"，极端 AOT、牺牲动态能力。选型看是否接受动态能力限制。

Jaotc 是"部分 AOT + 保留 JVM"，Native Image 是"全量 AOT + 封闭世界"。差异核心是"动态能力保留程度"与"启动/内存收益"的权衡。

• GraalVM JIT vs C2 的差异
• 编译速度、峰值性能、内联、诊断
• 基准对比方法

GraalVM JIT（Java 编写的编译器，也作为 JIT 使用）与 HotSpot C2 的差异：编译速度上，GraalVM JIT 通常编译更快、实现更可维护；峰值性能上，两者接近，但 C2 在部分场景（成熟优化）更优，GraalVM JIT 在部分新特性（如向量化、Lambda 优化）有优势；内联策略上，GraalVM JIT 的内联更激进、更依赖分析，C2 更保守；诊断工具上，C2 有 PrintCompilation、JFR 等成熟工具，GraalVM JIT 有 GraalVM 专属的编译图形（Ideal Graph）可视化与诊断。基准对比方法：用 JMH 做严谨的微基准（预热、Fork、Blackhole），分别用 -XX:+UseJVMCICompiler（GraalVM JIT）与默认 C2 运行，对比吞吐、P99、启动时间与编译时间，并监控 GC 与 C2 编译日志，在真实业务压测下验证。

差异在"编译器实现与新特性支持"：GraalVM JIT 更现代、编译快，C2 更成熟、峰值稳定。基准对比要用 JMH + 真实压测，分别跑两种编译器并对比多维度指标。

• 类型预测与激进优化
• 去优化的触发条件
• 去优化的正确性保证

JIT（C2）基于运行期收集的类型画像（Profile）做激进优化，如根据"调用点绝大多数是类 A"做推测内联、推测类型断言、优化分支。当运行时情况与画像不符（如出现了新的接收者类型、类层次被修改、断言失败）时，JIT 会触发去优化（deoptimization / uncommon trap）：把当前执行从编译代码回退到解释器（或转用正确的编译版本），并重新收集画像。去优化保证语义正确的关键在于"编译代码与解释器以同一语义执行"：编译代码插入了守护检查（guard），一旦发现假设被破坏，就通过栈帧的"可恢复信息"安全回退到解释器栈，从正确位置继续执行，从而保证即使切片假设失效，程序行为仍与规范一致。去优化带来的是性能回退（重新解释/再编译），但不影响正确性。

去优化是"激进优化 + 安全回退"的保险机制：编译代码带守护，假设失效时回退解释器，保证语义正确。代价是性能抖动，但正确性永远有保障。

• 内联的大小条件
• 调用类型与类型谱条件
• 内联失败日志确认

JIT 方法内联需要满足：大小条件（方法字节码大小在 -XX:MaxInlineSize 内，热点方法在 -XX:FreqInlineSize 内）、调用类型条件（静态/私有/构造器可直接内联，虚方法需接收者类型单一或通过类型画像确认）、类型谱条件（调用点接收者类型集中，若过于多态则无法安全内联）。内联失败时，可通过 -XX:+PrintInlining 日志确认原因，日志会标注 "too big"、"virtual call"、"polymorphic"、"receiver type" 等，明确指出为什么没内联。根据日志可调整参数（如 FreqInlineSize）或优化代码（减少多态）来促进内联。

内联是"大小 + 调用类型 + 类型谱"三重条件。PrintInlining 提供失败原因，是定位内联问题的关键工具。

• Code Cache 耗尽现象
• 定位参数与日志
• 治理措施

Code Cache 耗尽时，JIT 编译器停止编译新方法，方法退化为解释执行，出现性能下降、CPU 升高、吞吐降低；日志会出现 "CodeCache is full" 或相关工作线程警告。定位参数与日志：-XX:+PrintCodeCache 输出 CodeCache 使用统计（各段 reserved/committed/used），-XX:+PrintCompilation 观察编译是否停止，-XX:+PrintCodeCacheOnCompilation 在每次编译时输出 CodeCache 状态，配合 -XX:ReservedCodeCacheSize 查看是否超限。治理：排查是否编译量异常（方法过多、去优化频繁），必要时扩容 ReservedCodeCacheSize，或调整编译策略（如减少分层编译的惰性编译）。

CodeCache 耗尽的关键证据是"编译停止 + 解释退化"。通过 PrintCodeCache 看使用、PrintCompilation 看编译状态，结合扩容与策略调整治理。

• 逃逸分析机制
• 标量替换与栈上分配
• 受益对象类型

逃逸分析（Escape Analysis）分析对象的作用域，判断对象是否逃逸出方法。若对象不逃逸（只在方法内使用，未返回、未存入外部引用），JIT 可把对象拆分为其字段（标量替换，Scalar Replacement），直接在栈上（或寄存器）用局部变量代替，避免真正的堆分配；甚至无需分配对象，直接访问字段。受益对象是"局部创建的、不逃逸的、字段简单的小对象"（如临时封装、迭代器、局部 DTO、锁对象等），通过标量替换消除堆分配与 GC 压力。代价是分析成本与对象字段过多时收益有限。现代 JVM（C2/GraalVM）默认开启逃逸分析。

逃逸分析通过"对象不逃逸→标量替换/栈上分配"消除堆分配，是 JIT 的关键优化。受益对象是"方法内局部、不逃逸、字段简单"的临时对象。

• 分层级别的计数与画像
• 解释器/C1/C2 的协作
• 关闭分层编译的代价

分层编译中，解释器维护计数（调用次数、回边次数）判断热点，达到阈值后触发 C1 编译；C1（带分析级别 2/3）在编译时收集画像（接收者类型、分支频率、虚方法分布），并把这些画像"传递"给 C2；C2 基于画像做深度优化（推测内联、逃逸分析等）。这种"解释器计数 → C1 编译并画像 → C2 深度优化"的接力是分层编译的核心。关闭分层编译（-XX:-TieredCompilation）会失去：C1 的快速编译与画像收集，导致方法直接由 C2 编译（或由解释器直接跳到 C2），编译等待时间更长、启动变慢，且缺少画像使 C2 无法做推测优化，峰值性能可能下降。因此关闭分层通常得不偿失。

分层编译的价值是"快速编译 + 画像驱动深度优化"。关闭分层会失去 C1 的快速响应与画像，使 C2 无画像可选、启动变慢、峰值优化受限。

• 压缩指针的影响
• 对象布局与缓存
• 地址计算与关闭评估

压缩对象指针（CompressedOops）把 64 位引用压为 32 位，影响：对象布局上，引用字段占 4 字节而非 8，对象更小，对象头中的 Klass 指针也可压缩；缓存占用上，同样大小的堆能容纳更多对象/引用，改善缓存局部性与内存带宽；JIT 地址计算上，访问引用字段时需解压（乘 8/加基址），生成代码多一步位移/加运算。何时应评估关闭：当堆非常大（超过 32GB，压缩指针失效而自动关闭）或地址计算开销显著、或需要超大堆时，可评估关闭 -XX:+UseCompressedOops 的收益（虽堆占用增加，但可能减少解压指令）。但默认小/中堆下开启压缩通常更优。

压缩指针是"以地址计算换取内存"的权衡：减少内存与改善局部性，但访问需解压。堆越大越接近其限制，超过 32GB 自动关闭；特定场景可评估关闭收益。

• OSR 的机制
• 长循环的 OSR 编译
• 与入口编译的区别

栈上替换（On-Stack Replacement，OSR）允许 JVM 在方法仍在执行（尚未返回）时，把正在解释执行的热点循环切换为编译代码，从而让长循环也能获得编译优化，而不必等循环结束再编译。触发机制：解释器在循环回边处计数，当回边计数超过阈值（Backedge Counter）时，为循环体做 OSR 编译（编译时锁定循环入口），并在下一次回边时把解释器栈帧切换到编译栈帧。与普通方法入口编译的区别：普通编译在方法入口处，把整个方法编译为从入口执行的机器码；OSR 编译是针对"循环入口"的编译，从循环体开始执行，把解释器栈帧就地转换为编译栈帧，因此能优化正在运行的长循环。OSR 的编译代码在方法退出后也可复用。

OSR 是"针对运行中热点循环的入口编译"，区别于"方法入口的普通编译"。它让长循环不因"方法未返回"而失去编译优化，是 JIT 对循环热点的关键支持。

• CompileThreshold 的语义
• 分层编译下的阈值
• 热点检测机制

-XX:CompileThreshold 是触发 JIT 编译的方法调用次数阈值，当方法调用次数（或回边次数）超过该值成为热点时，触发编译。在分层编译下，阈值的语义被细分：不同编译级别（C1、C2）有各自的阈值配置（如 -XX:TieredStopAtLevel、-XX:Tier*CompileThreshold 等），解释器先按阈值触发 C1 编译（快速），C1 按其阈值升级到 C2。因此 CompileThreshold 是"单层"的旧概念，分层编译用更细的层级阈值控制编译升级。热点检测通过方法调用计数器与回边计数器，达到阈值即触发对应层级的编译。

CompileThreshold 是"触发编译的调用次数"，分层编译把它细分到各层级的阈值。理解后明白"热点"如何在不同编译层级间升级。

• 解释器与编译器的分工
• 分层编译的协作
• 计数与画像的传递

解释器与 JIT 编译器协作构成分层编译：解释器负责快速启动执行与维护热点计数（方法调用、回边），当计数超阈值时触发 C1（客户端编译器）快速编译，让方法尽快获得编译性能；C1 在带分析级别编译时收集运行画像（接收者类型、分支等），这些画像传递给 C2（服务端编译器，深度优化）——C2 基于画像做推测内联、逃逸分析、循环优化等激进优化。解释器、C1、C2 通过"计数 + 画像 + 编译"的接力协作，兼顾启动速度与峰值性能。去优化时，从编译代码回退到解释器继续执行。

协作链是"解释器计数 → C1 快速编译 + 画像 → C2 深度优化"，去优化回退解释器。这套机制让 JVM 兼顾快速启动与峰值吞吐。

• OSR 的栈帧切换
• OSR 编译过程
• JFR/编译日志验证

长循环运行期间，解释器在循环回边计数超阈值后触发 OSR 编译。OSR 编译会产生一个从"循环入口"开始的编译方法，并生成对应的 OSR 栈帧模板。切换时，JVM 在回边处把解释器栈帧"就地"转换为编译栈帧（OSR 栈帧），把局部变量、操作数栈的内容迁移到编译栈帧，然后从编译后的循环入口继续执行。这与方法入口编译不同（后者从方法开始）。验证收益：可用 -XX:+PrintCompilation 观察 OSR 编译（标记 % 表示 OSR），用 JFR 的 jdk.Compilation 事件或编译日志查看编译发生；用 JFR 的 CPU 采样或执行时间对比"OSR 前后"的循环吞吐，确认优化生效。

OSR 栈帧切换是"解释器帧→编译帧"的就地迁移，从循环入口续跑。用 PrintCompilation（% 标记）与 JFR 编译事件可确认 OSR 发生并验证循环性能提升。

• MaxInlineLevel 的语义
• 内联深度控制
• 调整影响

-XX:MaxInlineLevel 控制 JIT 内联的最大嵌套深度（默认 9），即内联链最多嵌套多少层方法。它作为内联预算（Inline Budget）的一部分，限制递归内联/深层调用链的内联深度，防止过度内联导致代码膨胀或编译时间过长。除了 MaxInlineLevel，内联预算还包括 MaxInlineSize（方法大小）、FreqInlineSize（热点方法大小）、MaxInlineNumberOfClasses 等。当调用链很深时，超过 MaxInlineLevel 的方法不会内联，改为普通调用。调整 MaxInlineLevel 需权衡：增大可内联更多层（减少调用开销），但可能增大代码膨胀与编译成本；减小则内联更保守。

MaxInlineLevel 是内联预算的"深度维度"，与大小/数量一起限制内联规模。控制深度防止代码膨胀，是内联策略的平衡阀。

• 接收者类型画像
• 推测内联
• 类层次变化与去优化

HotSpot 在运行期收集调用点的接收者类型画像（Receiver Type Profile），记录调用点接收者主要是哪些类。C2 据此做推测内联（Speculative Inlining）：若调用点绝大多数接收者是类 A，C2 就假设 A 为接收者并内联 A 的方法，同时插入类型的守护检查（guard），验证运行时接收者仍是 A。若类层次变化（如加载了新的子类、新增实现、或运行时出现不同于 A 的接收者），守护检查失败，JIT 触发去优化（uncommon trap）：回退到解释器（或重新编译成不含该假设的版本），重新收集画像。这样既享受了推测内联的优化，又保证了类层次动态变化时语义正确。

推测内联 = 类型画像 + 守护检查 + 内联假设；类层次变化破坏假设 → 去优化回退。这是"用画像做激进优化 + 用守护保证正确"的典型。

• 类型画像污染
• 对内联与分支预测的影响
• 恢复稳定画像的方法

多态调用点的类型画像被污染，指调用点接收者类型分布变得杂乱（如出现大量不同类），导致 C2 无法推测单一接收者做内联，内联失效；同时分支预测也因类型不确定而命中率下降。影响：方法调用开销增加、内联带来的优化（逃逸分析、常量传播）丢失，峰值性能下降。恢复稳定画像的方法：在调用点设计上让接收者类型集中——如把多态逻辑拆分为多个单态调用点（按类型分流）、使用接口默认方法/重载规避多态、避免在热点路径混入多种实现、用 instanceof 分支预先分流再调用、或把类型相关逻辑下推至每个实现类。这样恢复单一/少数接收者画像，让 C2 重新内联。

画像污染的本质是"调用点类型不集中"。通过拆分多态调用点、分流类型，让接收者类型收敛，从而恢复内联与分支预测。这是"代码组织影响 JIT 优化"的体现。

• 循环展开
• 循环不变量外提
• 其他循环优化与观察

C2 对热点循环做多种优化：循环展开（Loop Unrolling）把循环体复制多次以减少循环控制开销与分支；循环不变量外提（Loop Invariant Code Motion）把循环体内不随迭代变化的计算移到循环外执行；此外还有循环合并、循环拆分、循环谓词（guard）、向量化（自动 SIMD）等。观察手段：-XX:+PrintOptoAssembly 或 -XX:+PrintIdeal 查看编译后的理想图/汇编确认优化；用 -XX:+PrintCompilation 观察循环方法是否被 C2 编译；用 JFR 的编译事件与 CPU 采样对比优化前后性能；用 JMH 微基准验证循环吞吐提升。

循环优化是 C2 的核心优化，展开与不变量外提降低循环开销。观察通过 PrintOptoAssembly/PrintIdeal 看优化后的代码形态，用 JMH 验证收益。

• Vector API 的机制
• JIT 的向量化支持
• 显式向量与自动向量化

Vector API（JEP 489/508/529，JDK 16 孵化、后续转正）提供显式的向量编程 API，让开发者用 Java 代码表达 SIMD 向量运算，JIT（C2）在编译期把 Vector API 操作翻译为对应的 SIMD 指令（如 AVX、NEON），从而获得硬件向量化性能。JIT 与 Vector API 的协作：C2 识别 Vector API 调用并生成向量指令，自动适应硬件 SIMD 能力；当目标架构不支持某向量宽度时，JIT 会退化到标量执行（仍正确）。相比 C2 的自动向量化（对循环的隐式 SIMD），Vector API 让开发者显式控制向量形状与运算，更可控、可预测。JIT 还会对 Vector API 做内联、常量折叠等优化。

Vector API 是"开发者显式向量化 + JIT 生成 SIMD 指令"的协作，让 Java 获得接近硬件极限的向量性能，且当硬件不支持时安全退化为标量。

• 内联失败的原因
• 方法过大
• 虚方法/多态

方法内联失败的常见原因：其一，方法过大——方法字节码超过 -XX:MaxInlineSize（非热点）或 -XX:FreqInlineSize（热点）阈值，内联预算不足；其二，虚方法/多态——调用点为多态（接收者类型不单一），无法确定目标方法，须通过类型画像推测，若过于多态则判定 "polymorphic" 不内联；其三，其他——方法过大、递归、编译时间限制、异常处理复杂、被 dontinline 指令禁止等。内联失败会使方法保持调用开销，可通过 PrintInlining 查看具体原因（too big / virtual call / polymorphic）。

内联失败主因是"大小超限"与"虚方法多态"。PrintInlining 会明确标注原因，据此调整参数或优化代码。

• 内联的条件
• 内联的收益
• 内联的风险

方法内联（Method Inlining）是 JIT 把被调方法体复制到调用处，消除方法调用开销。条件：方法大小在预算内（MaxInlineSize/FreqInlineSize）、调用类型可确定（静态/私有/构造器，或单态/可用画像预测的虚方法）、内联深度未超过 MaxInlineLevel 等。收益：消除调用指令、栈帧分配与参数传递开销；内联后可为更大代码块做常量传播、逃逸分析、死代码消除等二次优化，显著提升热点性能。风险：内联过大/过深会膨胀代码、增加缓存压力与编译时间，故有内联预算控制。合理内联是 JIT 性能的基石。

内联收益是"消除调用开销 + 为后续优化提供更大代码块"，风险是代码膨胀。条件（大小/类型/深度）与预算约束保证收益大于成本。

• 内联预算的三维
• 大小/深度/多态的权衡
• 强制内联的风险

内联预算由三个维度共同决定：方法字节码大小（越大消耗预算越多）、调用深度（越深越接近 MaxInlineLevel 上限）、多态程度（越偏离单态越难内联，需更多画像守护）。JIT 在预算内综合权衡这三个维度决定是否内联。强制内联（如 -XX:CompileCommand=inline 强制指定方法）的风险：若方法过大，强制内联会显著膨胀代码，导致编译时间变长、CodeCache 占用增加、指令缓存（I-Cache）命中率下降，甚至吞吐反而下降；若方法有副作用或异常复杂，强制内联可能引入 deopt 风险。因此强制内联应谨慎，仅在确认收益时使用。

内联预算是在"大小、深度、多态"三维间权衡。强制内联打破预算约束，可能带来代码膨胀与性能回退，是"人工干预需谨慎"的体现。

• 预热的作用
• Fork 的作用
• Blackhole 与参数化

JMH 测量 JIT 优化必须设置预热（Warmup）、Fork、Blackhole 和参数化场景，原因：预热让 JIT 完成编译与优化、消除解释/编译期噪声，否则测得的是"解释执行"而非"优化后"性能；Fork 让每个基准在独立 JVM 进程运行，隔离不同基准间 JIT/GC 状态干扰，保证结果可复现；Blackhole 防止 JIT 因"结果未被使用"而做死代码消除（dead code elimination），让测量反映真实计算；参数化场景（@Param）覆盖不同输入规模，避免单一输入下 JIT 的特殊优化（如极值分支）造成误导。缺少这些设置，结论可能被 JIT 优化、进程污染或死代码消除歪曲。

JMH 的严谨性来自"预热灭 JIT 噪声、Fork 隔离进程、Blackhole 防消除、参数化覆盖输入"。这些设置共同保证测量的是"真实、可复现、无偏"的 JIT 优化效果。

• 封闭世界 AOT
• 启动与峰值吞吐
• 动态能力权衡

GraalVM Native Image 采用封闭世界 AOT（Closed-World AOT）：构建期静态分析应用可达性，把整个应用（含部分静态初始化）编译为独立可执行文件，无需 JVM。权衡：启动上，Native Image 启动极快（毫秒级）、内存占用低，适合冷启动敏感场景（Serverless、CLI）；峰值吞吐上，Native Image 因无 JIT 运行期优化，峰值吞吐通常低于 HotSpot JIT（JIT 能针对运行画像做深度优化）；动态能力上，Native Image 牺牲反射、动态代理、字节码生成等动态特性（需额外配置或受限），而 HotSpot JIT 保留全部动态能力。因此权衡是"启动/内存 vs 峰值吞吐/动态能力"：追求快速启动与低内存选 Native Image，追求峰值性能与动态性选 HotSpot JIT。

权衡落在"启动/内存"与"峰值吞吐/动态能力"两端。Native Image 适合启动敏感、动态性低的场景，HotSpot JIT 适合长期运行、依赖动态特性的场景。

• 显式向量 vs 自动向量化
• 尾部元素处理
• 硬件差异

Vector API 提供显式向量操作，让开发者明确指定向量类型与运算，控制力强、可预测；C2 自动向量化对循环做隐式 SIMD，省心但依赖编译器识别模式，且只在特定条件下生效。取舍：追求确定性、复杂运算或需要跨架构性能时用 Vector API；简单连续循环、希望省心时依赖自动向量化。尾部元素：当数据长度不是向量宽度的整数倍时，Vector API 可通过 mask 操作（等宽向量部分加载）或标量循环处理剩余元素，C2 自动向量化也会用标量/半宽向量处理尾部。硬件差异：Vector API 通过 IntVector/preferredSpecies 选择架构最优向量宽度，JIT 在目标硬件不支持时退化为标量，保证在不同 CPU（AVX2/AVX-512/NEON）上正确运行。

取舍是"显式可控 vs 自动省心"；尾部元素用 mask 或标量处理；硬件差异由 JIT 自适应向量宽度与安全退化。这使 Vector API 既高性能又跨平台正确。

• 连续数据访问识别
• 向量化条件
• 验证 SIMD 生成

向量化优化识别循环中的连续数据访问，通常要求：循环可证明迭代次数固定/可分析、数组访问步长为一个元素（连续）、无数据依赖（读写不冲突）、无别名歧义、无函数调用逃逸等。满足这些条件，JIT 才能把循环标量运算合并为 SIMD 向量运算。使用 Vector API 时，确认生成了 SIMD 指令而非退化标量代码的方法：用 -XX:+PrintAssembly 或 hsdis 查看生成的汇编是否出现向量指令（如 vaddps、vpmulld、pxor 等 AVX/SSE 指令）；用 -XX:+PrintOptoAssembly 查看 IR 阶段是否出现 VectorNode；或用 JFR 的编译事件结合汇编确认。若出现标量指令（如 addl、mull）则说明退化为标量，需检查向量宽度、循环形状或添加对齐/掩码。

向量化依赖"连续访问 + 可分析循环 + 无依赖"。确认 SIMD 的核心手段是看汇编中的向量指令，若无则退化为标量，需排查原因。

• 破坏逃逸分析的操作
• 反射与身份相关操作
• 逃逸分析的保守性

若干操作会破坏逃逸分析，使对象无法被标量替换/栈上分配：反射——对象被反射访问（getField/setField）时，逃逸分析无法跟踪反射路径，对象视为逃逸；identityHashCode——对对象调用 System.identityHashCode 或基于身份的操作，需要对象有真实身份/地址，无法标量替换；同步——对象被用作锁（monitor 进入），锁需要对象身份，逃逸分析失效；序列化——对象被序列化/反序列化时，通过反射/外部框架访问，破坏逃逸。此外，对象被存储到外部引用、返回给调用方、通过方法边界传递等也会视为逃逸。逃逸分析对这些"无法安全跟踪"的操作持保守态度，视为对象逃逸，放弃标量替换。

逃逸分析是"保守的"，凡对象身份被外部依赖（反射、锁、identityHashCode、序列化）或引用逃逸出方法，就放弃优化。识别这些破坏操作可推测代码是否受益于逃逸分析。