"native"关键字与@HotSpotIntrinsicCandidate注解的区别、选型及性能对比

两者从设计目标、实现路径到语义归属完全不同，核心区别可以拆成几个维度：

• 规范属性不同
  native是Java语言规范定义的跨语言调用契约，所有兼容JVM规范的实现（包括OpenJ9、GraalVM、Zing等）都必须支持该关键字的语义。
  @HotSpotIntrinsicCandidate是HotSpot JVM私有的编译标记，没有任何跨JVM的强制语义，其他JVM解析到该注解时会直接忽略，不产生任何编译或运行时行为变更。
• 实现依赖不同
  被native修饰的方法没有可执行的Java逻辑体，必须依赖外部编译的本地动态库（.so/.dll/.dylib）提供符号实现，通过JNI桥接完成调用绑定。
  被@HotSpotIntrinsicCandidate修饰的方法自带完整的Java可执行实现，不存在外部库依赖，标记的作用是告诉HotSpot的C1/C2 JIT编译器：在编译该方法时，可以直接用内置的、针对CPU架构手写优化的汇编/IR逻辑替换原有的Java字节码执行逻辑。
• 调用路径不同
  native方法调用需要在Java栈和本地方法栈之间做切换，同步完成Java类型到本地类型的参数、返回值转换，还要处理JNI边界的引用有效性检查、异常栈回溯等固定流程。
  intrinsic替换的代码是直接嵌入到JIT编译的Java代码流中的，和调用方共享同一个栈空间，不存在跨栈切换、跨语言类型转换的固定开销。

优先选择native机制的场景 #

• 需要对接操作系统内核接口、硬件能力的逻辑：比如线程底层调度、内存直接映射、特殊指令集的裸调用等，这类场景不属于JDK核心类库的固定逻辑范围，HotSpot不可能内置对应的intrinsic实现，必须通过native方法对接本地系统能力。
• 需要跨非HotSpot JVM运行的逻辑：如果代码的运行环境包含OpenJ9、GraalVM Native Image等不支持HotSpot私有注解的JVM，@HotSpotIntrinsicCandidate的优化完全失效，此时要提供本地能力就只能依赖native关键字的标准化语义。
• 需要对接外部第三方本地库的逻辑：比如团队需要对接已经存在的C/C++科学计算库、多媒体处理库，这类外部依赖的逻辑不可能被HotSpot识别为可优化的intrinsic目标，必须通过native方法完成桥接。

优先选择@HotSpotIntrinsicCandidate机制的场景 #

• JDK核心类库中逻辑固定、可枚举的热点方法：比如字符串操作、数学函数计算、集合类核心操作等，这类逻辑不需要对接外部依赖，通过intrinsic替换既可以保留Java层的可调试、可扩展的默认实现，又能拿到接近手写汇编的执行效率，完全省去了维护JNI胶水代码、多平台编译本地库的成本。
• 高频触发的轻量方法调用：对于每秒调用数百万次的热点方法，JNI的跨栈切换、类型转换开销会累积成显著的性能损耗，此时用intrinsic替换可以把固定调用开销降到和普通Java方法调用一致的水平。
• 需要动态适配不同CPU指令集的逻辑：intrinsic实现支持HotSpot在运行时根据当前机器的CPU能力（比如是否支持AVX2、BMI2等指令集）选择最优的汇编版本，相比提前编译的通用本地库实现，不需要为不同硬件架构单独打包、分发动态库。

反向选型的适用逻辑 #

选型的核心判断标准是逻辑边界是否属于HotSpot的内置优化范围：如果逻辑需要对接外部依赖、运行在非HotSpot环境，强行依赖intrinsic机制会导致优化完全失效，功能无法正常工作；如果逻辑属于HotSpot可以覆盖的固定优化范围，强行用native实现则会平白增加跨语言调用的固定开销，还要承担多平台编译、维护JNI桥接代码的额外成本，完全没有收益。

在实现逻辑完全等价的前提下，经过intrinsic替换的方法性能显著优于常规native方法，差距来源非常直接：

• intrinsic代码不存在跨栈切换、JNI引用有效性检查、跨语言类型转换的固定开销，执行路径和普通JIT编译的Java方法没有区别；
• intrinsic实现可以和JIT编译流程深度联动，参与内联、常量折叠、逃逸分析等跨方法优化；而普通native方法对JIT来说是完全不透明的黑盒，编译阶段根本不知道方法内部做了什么，没办法做任何深度优化；
• intrinsic实现抛出异常时完全走Java栈的标准异常处理路径，不需要从本地栈回溯定位对应的Java栈帧，异常高频触发的场景下，性能差距会被进一步放大。

如果native实现是针对特定场景做了极致裁剪、没有冗余的C/汇编代码，它的纯计算效率和intrinsic实现的差距会缩小到可感知的范围，但还是没法抵消跨语言调用边界带来的固定成本。

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