当索引范围通过与运算限定时，现代HotSpot能否消除数组访问边界检查？

现代HotSpot完全可以消除示例代码中lookup[i & 0xFF]的隐式边界检查，这类优化早在JDK 8的C2编译器迭代中就已经稳定落地

核心优化原理 #

HotSpot的服务端C2 JIT编译器会在编译阶段做全量的数据流范围推导，只要能证明数组访问下标的取值完全落在0 ~ 数组长度-1的合法区间内，就会自动省略对应的空指针检查、数组越界判断逻辑，直接生成高效的内存访问指令。
针对题中的代码，编译器可以准确推导两个层面的取值范围：

• 对下标运算i & 0xFF，按位与操作的语义是将输入int值的高24位全部清零、仅保留低8位，最终取值的范围被严格限制在0 ~ 255的闭区间，不存在越界的可能
• 对lookup数组，因为是方法内直接初始化的new int[256]，数组长度是编译期可确定的常量256，对应的合法下标范围刚好也是0 ~ 255

两者的取值范围完全匹配，这种“用数组长度减1做位掩码取下标”的写法，恰好是C2编译器重点优化的场景——哈希表寻址、缓存页对齐等常见高性能代码都依赖这类模式，编译器针对这类位运算的范围推导做了专门的优化规则，会安全删除所有和边界检查相关的分支判断。

常见的优化失效场景 #

如果代码写法发生如下变化，编译器可能无法完成边界检查消除，会保留原生的检查逻辑：

• lookup数组的长度不再是固定的256，比如被初始化为长度128的数组，此时i & 0xFF的取值范围超过了数组的合法下标区间，编译器无法证明不会越界
• lookup数组不是在方法内直接初始化定长数组，而是通过方法参数传入、长度为运行时动态值，编译器无法在编译期确定数组的实际长度
• 下标计算不是单纯的i & 0xFF，引入了其他无法精确推导范围的运算，比如叠加了动态偏移值

效果验证 #

实际用JMH基准测试验证该代码的性能时，可以在生成的汇编输出中看到：数组访问逻辑没有对应的“下标和数组长度比较、不满足则跳转到异常抛出逻辑”的分支指令，和开发者手动插入边界断言的代码性能完全一致。

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