选c1还是c2取决于程序生命周期：c1适合短时交互型应用，c2适合长期运行服务；jdk 8起默认分层编译，c1先处理冷启动，约1万次调用后c2接手深度优化。
C1和C2编译器的适用场景差异
选C1还是C2，本质是权衡「启动快」和「跑得久」：C1适合短生命周期、交互敏感的程序（比如命令行工具、GUI小应用），C2适合长期运行的服务端进程（如Spring Boot Web服务、批处理任务）。JDK 8起默认启用分层编译（-XX:+TieredCompilation），实际是让C1先扛住冷启动，等方法被调用约1万次后，再由C2接手深度优化——你不用手动切，但得知道它在后台怎么流转。
C1和C2的优化能力与开销对比
C1做的是“够用就好”的优化：
-
方法内联只对极短方法（如getName()）生效，不分析调用链深度 - 不做
逃逸分析、循环展开或分支预测 - 寄存器分配用
线性扫描算法，生成代码体积小、编译快（毫秒级）
C2则是“榨干性能”的路线：
- 收集运行时
Profiling数据（如分支跳转频率、对象存活时间） - 支持
去虚拟化（把接口调用转为具体实现）、DeadCode Elimination、全局标量替换 - 寄存器分配用
图着色算法，更耗内存和CPU，但生成代码执行效率高
如何验证当前用的是C1还是C2
别猜，直接看JIT日志。加JVM参数：-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，然后运行程序。观察输出中的关键字段：
- 每行开头的
123（数字）表示编译层级：1是C1编译，4是C2编译（分层编译下还可能有0解释执行、3C1+profiling等） - 含
made not entrant或made zombie说明该方法被C2替换了C1版本 -
@ 123后面跟inline (hot)表示C2已对该方法做了内联，而C1通常只标inline (cold)
注意：-client和-server参数在JDK 8+已失效，强行使用会被忽略——这是最容易踩的坑。
C1/C2的安全点插入机制不同
GC和线程挂起依赖安全点（Safepoint），但C1和C2插入位置策略不一致：
- C1在
方法返回前固定插桩，调用SharedRuntime::polling_page_return_handler_blob()，逻辑简单直接 - C2通过
C2SafepointPollStubTable统一管理多个桩，且会结合Profiling数据，在循环体头部、方法入口等更激进的位置插入 - 这意味着：C2编译后的代码，安全点密度更高，GC停顿（Stop-The-World）等待时间理论上更短，但也带来稍多一点的运行时开销
如果你在压测中观察到safepoint sync time异常高，别只盯着GC，先确认是不是C2把安全点塞得太密，或者某些热点方法没被C2及时接管（比如被CompileCommand=exclude误排除了）。
