varhandle 对数组原子操作不自动检查索引越界，异常仍由 jvm 抛出；因其设计追求极致性能，省去边界校验以减少开销，故需开发者在调用前手动预校验索引合法性。
VarHandle 对数组做原子操作时，不自动检查索引是否越界——越界行为和普通数组访问一致，仍由 JVM 在运行时抛出 ArrayIndexOutOfBoundsException。这意味着：高并发场景下，如果多个线程同时用非法索引调用 VarHandle 的 get、set 或 compareAndSet，异常仍会照常抛出，且无法靠 VarHandle 本身规避。
为什么 VarHandle 不做范围检查
VarHandle 的设计目标是极致性能与底层控制权下放。它绕过了 AtomicIntegerArray 等封装类中内置的边界校验、null 数组判断和统一 volatile 语义包装。JDK 9+ 中 AtomicIntegerArray 实际就是基于 VarHandle 实现的，但它额外加了安全层；而直接使用 VarHandle，等于手动“摘掉”这层防护。
- 省去边界检查 → 减少分支预测失败和指令开销 → 更适合高频、确定性索引的场景
- 但代价是：你必须确保索引合法，否则异常在运行时爆发，且无提前预警
- 尤其在并发循环、分段处理或动态计算索引（如 hash 映射、轮询偏移）时，逻辑稍有偏差就容易漏判
高并发下推荐的越界防护策略
不能依赖 VarHandle 自检，就得把检查前置、轻量、线程安全地嵌入业务逻辑中。
-
索引预校验 + 快速失败：在调用 VarHandle 方法前，用
index >= 0 && index 判断。这个判断开销极小，且可内联优化；比捕获异常成本低两个数量级 -
避免在循环条件里隐式越界：例如
for (int i = start; i 容易多走一轮；应统一用 <code>i 或严格按预计算的合法区间执行 -
对动态索引做归一化：比如用模运算取余得到有效下标（
int safeIdx = Math.floorMod(hash, array.length)），比事后检查更高效稳定 - 结合 ThreadLocal 或分段锁缩小校验粒度：若某段索引只被固定线程访问，可在初始化阶段一次性校验并缓存合法范围，避免每次重复判断
和 AtomicIntegerArray 的开销对比要点
直接手写 VarHandle 能省掉的，正是 AtomicIntegerArray 封装带来的“安全税”：
-
AtomicIntegerArray每次操作都强制检查array != null和index边界 —— 即使你 100% 确保不会越界 - 它的
get/set是 public final 方法，无法被 JIT 内联为单条 CPU 指令；而静态获取的 VarHandle 可以内联成近乎原生的内存访问 - 如果你的索引来源可信（如预分配固定任务槽、RingBuffer 固定大小），VarHandle 的零开销边界跳过就是合理选择
实际编码建议
不要为了“看起来更底层”而裸用 VarHandle。先问自己三个问题：
- 索引是否全部来自可控输入（如配置、预计算结果），还是可能含用户/网络/文件等外部数据？
- 是否已有其他机制（如限流、预校验层、断言）兜底？
- 压测中，VarHandle 带来的微秒级收益，是否真比一次未捕获的越界异常导致的线程中断更值得？
多数业务系统，用 AtomicIntegerArray 更稳妥；只有高性能中间件、底层框架或已充分验证的热路径，才建议切换到 VarHandle 并自行担起索引守门责任。
