String.indexOf更快是因为HotSpot JVM在JIT编译时将其内联为CPU原生向量化指令（如SSE的PCMPEQB+PMOVMSKB），绕过Java栈帧与边界检查；前提是运行于HotSpot、完成JIT预热、且字符串均为Latin-1编码。
String.indexOf 为什么快得不像 Java 代码
因为 HotSpot JVM 在 JIT 编译阶段，把 StringLatin1.indexOf 这类带 @HotSpotIntrinsicCandidate 注解的方法，直接替换成 CPU 原生指令（比如 SSE 的 PCMPEQB + PMOVMSKB 组合），跳过了字节码解释和常规方法调用开销。这不是“优化循环”，而是彻底绕过 Java 栈帧、内存访问和边界检查——只要满足触发条件，它就变成一条或多条向量化机器指令。
必须满足的三个硬件/运行时前提
即便方法打了 @HotSpotIntrinsicCandidate，JVM 也不会无条件启用 intrinsic。实际生效依赖以下硬性条件：
- 运行在 HotSpot VM（OpenJDK / Oracle JDK），GraalVM 或其他 JVM 实现基本不支持该注解
- JIT 已完成预热：同一段
String.indexOf调用需被高频执行（默认阈值 10000 次），触发 C2 编译器介入 - 字符串编码匹配：调用者与参数都为 Latin-1 编码（
coder == 0），此时底层走byte[]路径，才能命中StringLatin1.indexOf的 intrinsic 版本；若含中文或 emoji，自动降级为 UTF-16 路径，intrinsic 失效
如何验证 intrinsic 是否真正启用
不能只看性能数字，得确认 JIT 真的插了指令。推荐组合使用两个标志：
- 启动参数加
-XX:+PrintIntrinsics：JVM 启动后会打印类似java.lang.StringLatin1::indexOf (115 bytes) @ 0x00007f... [intrinsic]的日志，说明已识别并准备替换 - 配合
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需安装 hsdis），查看生成的汇编里是否出现pcmpeqb、pmovmskb、testl等向量化指令序列，而非传统cmpb+je循环 - 注意：JDK 17+ 默认禁用
PrintAssembly，需额外配置-XX:CompileCommand=print,*StringLatin1.indexOf精准定位
别指望手动触发或“强制开启”
@HotSpotIntrinsicCandidate 是纯提示性注解，不是开关。你无法通过反射、系统属性或 JVM 参数“打开”某个 intrinsic。它的启用完全由 HotSpot 内部规则控制，包括：
- 当前 CPU 是否支持对应指令集（如 SSE4.2 或 AVX2）——老至 Core2 只支持 SSE3，
indexOfintrinsic 就不会启用 - 方法是否被内联：若调用链过深或存在虚方法分派，JIT 可能放弃内联，导致 intrinsic 失效
- 数组长度是否达到向量化门槛：短于 8 字节的 pattern 通常走标量路径，长 pattern 才触发 SIMD 批处理
真正可控的只有输入数据形态：确保字符串不含非 Latin-1 字符、避免频繁创建新 String 实例（破坏 coder 推断）、让热点逻辑稳定复现——剩下的交给 JIT。
