C1与C2模式的核心差异在于热点代码识别策略、优化深度、触发阈值及编译时机；Java无独立“热点变量”，其优化依赖所在方法或循环是否被JIT选中及编译器能力。
Client（C1）和Server（C2）模式在JIT编译热点代码时，核心差异不在“变量”本身，而在于对方法或循环体这类热点单元的识别策略、优化深度、触发阈值及编译时机。Java中没有“热点变量”这一独立概念，所谓“热点变量”实际是嵌套在热点方法或热点循环中的局部变量，其优化效果由所在代码块是否被JIT选中、以及所用编译器的能力决定。
触发条件不同：计数器阈值与判定逻辑
C1和C2均采用基于计数器的热点探测，但默认阈值差异显著：
- Client模式下，方法调用计数器阈值为1500次，回边计数器（针对循环）也较低；适合快速响应短生命周期应用
- Server模式下，方法调用计数器阈值为10000次，回边计数器更高；需更长时间积累运行数据，避免过早编译不稳定代码
- 两者都只对整个方法或循环体做编译，不单独编译某个变量——变量的栈分配、标量替换、寄存器分配等优化，是编译器在方法级编译过程中自动推导并实施的
优化能力不同：C1重速度，C2重深度
一旦某段含变量操作的代码被识别为热点并进入编译流程，C1与C2的处理方式明显分化：
- C1编译器执行轻量级优化：如方法内联（小方法）、公共子表达式消除、简单逃逸分析（可能触发标量替换），但不支持跨虚方法调用的激进内联
- C2编译器启用高级优化：包括全路径的逃逸分析（可将对象拆解为独立变量存入寄存器）、循环展开、冗余检查消除、以及基于类型推断的虚拟调用内联——这意味着原本动态绑定的变量访问，可能被静态化为直接字段读写
- 例如一个频繁访问
obj.field的循环，在C2下可能完全消除对象引用，把field值提升为循环内的局部寄存器变量；C1通常保留原始对象访问模式
代码缓存与运行阶段行为差异
编译产物的存储与使用方式也影响变量相关性能表现：
- Client模式默认codeCache起始大小仅160KB，适合GUI类程序，频繁编译小方法，但缓存易满导致编译停顿；变量优化受限于缓存容量和编译粒度
- Server模式codeCache起始为2496KB，支持更大方法、更多内联层级和更持久的优化代码驻留；变量的生命周期管理（如栈上替换OSR中循环变量的快照）更稳定可靠
- Server模式还会进行分层编译：先用C1快速生成带监控的版本，再用C2替换为高度优化版本；变量在不同层级间可能经历从堆分配→栈分配→寄存器暂存的演进
实际影响：启动快慢与长期吞吐的权衡
对含密集变量计算的业务逻辑（如数值聚合、状态机更新），两种模式的表现差异直观可见：
- 桌面工具类应用（如IDE插件、小型配置器）用Client模式：几秒内就看到变量运算变快，但高峰负载下可能因优化不足出现抖动
- 后端服务（如订单计算、实时风控）必须用Server模式：前几十秒稍慢，但1–2分钟后变量访问延迟下降30%–60%，GC压力明显降低
- 现代HotSpot（JDK 8u+）已默认取消-client/-server显式开关，改为根据CPU核数（≥2）和内存（≥2GB）自动选择Server模式；手动指定仅在特殊嵌入场景仍有意义
