为什么64位HotSpot JIT不对long计数器循环展开、还会引入Safepoint？

你观察到的性能差异完全是HotSpot C2 JIT的常规优化决策导致的，和“long类型在64位CPU上更慢”这类玄学猜测没有任何关系，两个核心现象的逻辑链非常直接：

为什么long计数器的循环不会被执行循环展开 #

循环展开是C2针对计数循环做的经典吞吐优化，它的决策完全基于「优化带来的收益能不能覆盖膨胀的代码成本」计算，从来不会根据计数器类型一刀切：

• 对int计数器的循环场景：JIT可以通过静态分析确认，int i < MAX（MAX为编译期常量）的访问模式下，所有数组索引都是合法的int值，和Java数组的最大长度约束完全匹配。此时JIT可以安全消除所有循环内的数组边界检查，直接把循环拆成单次迭代处理4~8个元素的流水线代码，展开后没有额外指令开销，收益远大于代码体积膨胀的成本，自然会触发优化。
• 对long计数器的循环场景：Java语言规范明确要求数组索引必须是int类型，所以代码里的data[(int) l]本质是一个无精度保留的long到int强制截断操作。C2的静态分析没法100%证明这个截断过程永远不会溢出——毕竟long的取值范围是int的40亿倍，哪怕循环写的是从0开始自增，JIT也没法确定整个循环过程中l不会突破int的上限。
  这种情况下，JIT不仅不能消除截断操作本身，还必须为截断后的索引保留完整的数组边界检查。如果此时强行做循环展开，每多展开一次迭代，就要多复制一份截断检查、边界检查的指令，膨胀的代码带来的指令缓存开销，会直接抵消流水线并行的收益，因此C2的代价模型会直接放弃对这类循环的展开优化。

这里有个非常实用的避坑点：不是所有long计数器的循环都不能展开。只要你给C2提供足够的静态证据证明l的取值永远不会溢出int范围（比如把终止条件补充为l < MAX && l < Integer.MAX_VALUE），C2是可以把long归纳变量窄化为int类型，拿到和int计数器完全一致的优化效果的。

为什么long计数器的循环需要插入额外的Safepoint检查 #

Safepoint是HotSpot实现全局操作（GC、线程栈扫描、偏向锁撤销等）的核心机制，插入规则的核心判断逻辑非常朴素：如果线程在一段连续代码里运行的时间长到会阻塞全局操作的触发，就必须在代码流中插入轮询指令。

• 对int计数器的循环场景：因为循环被完整展开，JIT可以精准计算出整个循环的最大执行时长——int计数器的最大迭代次数是2^31次，展开后单次循环的总执行时间通常在几十毫秒级别，完全达不到需要中断做全局操作的时长阈值。因此JIT只会把Safepoint轮询放在整个循环的出口位置，不需要在循环体内部插入任何检查。
• 对long计数器的循环场景：long类型的理论最大迭代次数是2^63次，这个量级的循环如果不插入内部Safepoint，线程可能连续运行几个小时都不退出，完全阻塞全局操作的触发。再加上这类循环没有被展开，JIT没法准确估算循环的实际运行时长，因此会默认把循环判定为“可能超长运行的循环”，直接在每次循环的回边位置插入Safepoint轮询指令，也就是每跑一次迭代就要做一次安全点检查，凭空增加了不少指令开销。

两个因素叠加——既没有循环展开的流水线并行收益，又有每次迭代的Safepoint轮询开销，最终就会体现为long计数器的循环吞吐比int计数器的版本低非常多。

内容的提问来源于stack exchange，提问作者Leprechaun