虚拟机native方法本质上就是一段用非Java语言（通常是C/C++）编写的、由JVM通过JNI规范调用和执行的外部函数，底层原理围绕JNI（Java Native Interface）展开，调用机制则涉及方法注册、参数转换、栈帧切换和本地代码回调等完整链路。很多开发者第一次接触它，往往是因为项目里出现了类似public native void hello();的声明，却不知道这个没有方法体的Java方法究竟是如何被“变”出实现的，这篇文章直接拆解，从声明到执行,把native方法的底裤翻出来看。
虚拟机native方法是什么？先看一个最简单的例子
在Java类里写native关键字，等于告诉JVM：“这个方法的外壳用Java声明，但内脏在别处。”
public class NativeDemo {
static { System.loadLibrary("demo"); }
public native String getMessage();
}
getMessage()没有方法体，但程序跑起来不会报错，因为JVM会去加载名为libdemo.so（Linux）或demo.dll（Windows）的动态库，从里面找对应的C语言函数，这个函数负责真正返回一个字符串给Java层。一句话概括：native方法就是把“体力活”外包给了C/C++，JNI是外包合同，动态库是外包团队。
为什么需要把活外包？三个典型场景
- 性能敏感区域：图像处理、加密算法、数学计算这类高频调用，C/C++直接操作内存和寄存器，比Java字节码少一层解释执行,多数情况下能快不少。
- 操作系统能力：Java标准库管不到的系统API，比如Windows注册表、Linux的
epoll、硬件的直接驱动访问,只能用native方法穿透。 - 复用存量代码：公司早就用C++写好了一套算法库，与其用Java重写一遍,不如用JNI包一层薄壳直接调用。
业内专家指出，Java生态里相当一部分底层基础设施，比如java.lang.Object的hashCode()（部分实现）、System.currentTimeMillis()、NIO中的epoll机制,背后都有native方法的影子。
虚拟机native方法底层原理：JNI规范与数据类型映射
JNI不是某个JVM的私货，而是一套由Java标准定义的接口规范，它规定了Java方法怎么映射到C函数，两边怎么交换数据，核心有三个环节：数据类型映射、方法注册、调用执行。
数据类型映射：Java和C怎么互相理解
Java的int不是随便给C用就行,JNI定义了专门的类型：
| Java类型 | JNI类型 | C/C++类型 | 备注 |
|---|---|---|---|
| boolean | jboolean | unsigned char | 0为false，非0为true |
| byte | jbyte | signed char | |
| int | jint | long（32位系统是int） | 注意C的int长度不固定，JNI直接用jint |
| long | jlong | long long | 64位 |
| float | jfloat | float | |
| double | jdouble | double | |
| String | jstring | 特殊引用类型 | 不能直接当char，要用GetStringUTFChars |
| 数组 | jintArray等 | 特殊引用类型 | 用GetIntArrayElements等函数访问 |
最容易踩坑的是jstring，C程序员习惯把字符串当char，但在JNI里，jstring是一个JVM内部的引用对象，直接用指针操作会崩，必须调用GetStringUTFChars把Java字符串转成C字符串，用完还得调用ReleaseStringUTFChars释放，不释放会导致内存泄漏,这是native方法最常见的隐患之一。
方法注册的两种方式
JVM不认识Java方法名，得靠一种规则把Java的native声明和C函数“对上号”。
- 静态注册：按照JNI规范约定的命名规则。
Java_com_example_NativeDemo_getMessage这种格式，包名里的换成_，然后拼接类名和方法名，JVM加载动态库时，按这个符号名去找函数地址，好处是简单，坏处是方法多了以后非常冗长，而且每次调用都要做符号查找,性能略差。 - 动态注册：在C代码里用
JNI_OnLoad函数，主动调用RegisterNatives，把Java方法名、签名和C函数指针一股脑告诉JVM，这种方式性能更好，因为JVM提前缓存了映射关系；还能随意命名C函数，不用遵守那套冗长的命名规则，Android NDK开发绝大多数场景用的是动态注册，因为有JNI_OnLoad的入口,方便初始化。
执行时JVM做了什么：栈帧与本地方法
当线程执行到invokevirtual或invokestatic指令，发现指向的方法有native标志,JVM会走一条特殊路径：
- 切换栈帧：Java调用栈每个元素是Java帧，调用native方法时，JVM会创建一条
native method frame，它不像Java帧那样存储局部变量表,而是预留了足够空间存放C函数的参数和返回值。 - 进入本地世界：线程从JVM的托管状态切换到原生状态，此时JVM无法再精确控制线程行为，比如垃圾回收时，GC线程需要知道线程当前在不在安全点，如果线程正在执行C代码，JVM不知道它内部的状态,必须等它回到JVM托管状态才能进行GC。
-
处理返回值
：C函数返回后，JNI层会把jxxx类型的返回值转换成Java类型，压入Java操作数栈,然后恢复Java执行流。
特别注意：在C代码内部，允许反向调用Java对象的方法，这叫“回调”，比如C函数里拿到一个jobject，调用CallVoidMethod触发Java层的回调方法，这时候线程又回到了JVM托管状态，GC可以正常工作,这个双向切换是JNI底层原理里最精巧也最危险的部分。
虚拟机native方法调用机制：从字节码到本地函数的完整链路
Java字节码里并不存在什么invokenative指令。native标志只是方法描述符的一个属性，真正触发调用的是普通的invokestatic或invokevirtual指令，JVM在解释执行时检查方法标志，发现是native就走NativeMethodAccessorImpl的逻辑。
动态代理如何提升调用效率
JVM对native方法调用做了两层优化，首次调用时，会生成一个NativeMethodAccessorImpl对象，它内部用直接指针指向动态库里的函数地址，随着调用次数增加，JVM可能会用GeneratedMethodAccessor生成一段机器码来替代解释路径，减少每次调用的流程判断，这和Java普通方法的内联优化类似，但native方法的优化空间有限，因为函数体在JVM之外,无法参与跨语言内联。
排查调用失败：UnsatisfiedLinkError的常见原因
这是学习native方法时遇到最频繁的错误，行业共识认为，绝大多数情况不是代码逻辑错了，而是“找不到符号”：
- 动态库没加载：
System.loadLibrary()抛UnsatisfiedLinkError，检查java.library.path是否包含.so或.dll所在目录。 - 方法名不匹配：静态注册时，C函数名少写了一个下划线,或者包名大小写不对。
- 签名不一致：动态注册时，用
(Ljava/lang/String;)V传错了签名,JVM校验时匹配失败。 - 平台不匹配：64位JVM必须加载64位编译的动态库，32位同理,混用会直接崩溃或加载失败。
- 依赖库缺失：C/C++动态库本身依赖其他
.so，系统找不到，加载时会报libxxx.so: cannot open shared object file。
实际操作中，可以打开JVM的-Xlog:jni+resolve=debug参数（JDK 9+）来输出JNI解析日志，能直接看到JVM在找哪个符号、找没找到。
虚拟机native方法底层原理深入：线程与内存管理
native方法不是百无禁忌的，C代码里可以随意分配内存，但这些内存如果忘了释放，JVM的GC管不到，就会慢慢吃光系统内存，JNI提供了一组GetPrimitiveArrayCritical和ReleasePrimitiveArrayCritical接口，用来获得数组的直接指针，但要求在这之间不能执行JNI函数，否则死锁，这就是所谓的“critical section”,执行期间必须快速完成操作。
线程挂载问题：从Java线程进入C线程
当某个C线程需要调用Java方法，它不能直接利用Java线程的JNIEnv指针，每个线程都有自己的JNIEnv，C线程必须先调用JavaVM的AttachCurrentThread把自己挂载到JVM上，然后才有资格拿到JNIEnv，用完后要调用DetachCurrentThread，否则线程退出时JVM会报错，这在Android的pthread场景里尤其常见。
虚拟机native方法常见疑问解答
Q：native方法是直接调用系统内核吗？
A：不一定，native方法只是让你能从Java层跳到C/C++层，至于C代码是调用系统API、还是自己写死运算逻辑、又或者和另一个进程通信，完全由你控制，JNI本身不提供任何“特权”，只是给了一个穿透Java沙箱的通道，在标准Java SE里，某些native方法能访问操作系统资源,但JDK对JNI调用没有像Java代码那样严格的安全限制。
Q：native方法和JNI是什么关系？是不是同一个东西？
A：不是同一个概念，JNI是Java Native Interface的缩写，是一套标准的接口定义，包含头文件jni.h、一系列函数表和数据结构的规范，native方法是Java语言里用native关键字修饰的方法声明，可以说，JNI是实现native方法的方式，而native方法是JNI在Java语法层的表现形式，没有JNI,native方法就只是个空壳。
Q：Java调用native方法的性能损失有多大？
A：一次标准的native调用，损耗主要来自JNI边界的数据转换、安全点检查和可能的动态注册查找，在多数JVM实现上，一次空native方法调用的开销大约是普通空Java方法调用的数倍以上，但绝对值非常小（相对纳秒级），如果方法体本身做了大量计算，这部分开销几乎可以忽略，真正要注意的不是单次调用，而是频繁地在Java和C之间传来传去，比如在循环里反复调用native方法，每次都要做类型转换和临界区切换，积累起来相当可观，更合理的做法是一次native调用做大批量工作,而不是拆成几千次小调用。
虚拟机native方法不是神秘的魔法，它就是JVM对外开放的一扇后门。底层原理的关键在于JNI规范管理了跨语言调用的每个细节方法注册、参数搬运、栈帧切换、线程挂载；调用机制则是一个清晰的分工体系：Java负责声明和控制线程状态，C负责执行实际逻辑，JVM负责兜底和整合资源。 搞懂这条链路，你在排查UnsatisfiedLinkError、做性能优化、或者阅读JVM源码时,就有了完整的地图导航。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/741295.html
