虚拟机中的native方法之所以能跨平台调用底层系统资源，是因为JVM通过JNI（Java Native Interface）在运行时将Java声明映射到当前操作系统的动态库，再经由该动态库直接发起系统调用。
虚拟机中native方法为什么能跨平台调用系统资源？
native方法在Java源码里只写了一个方法签名,比如public native int read()，真正执行动作的，是JVM根据所在平台加载的本地动态库，JVM本身是分平台的，Windows有Windows版JVM，Linux有Linux版JVM，每个JVM都按照JNI规范提供同一套接口，当Java代码调用native方法时，JVM会查找当前平台的动态库文件：Windows上是.dll，Linux和macOS上是.so或.dylib，找到后，从库中导出对应的C/C++函数并执行。
![[DevLog] 这能算绕过Native吗？](https://i1.hdslb.com/bfs/archive/91c710a7db36cdd0d0f9577aff60caf829b12eed.jpg)
这个机制的关键在于：JNI规范定义了一套稳定的二进制接口，Java层和本地层都遵循这套接口，Java代码不关心操作系统是谁，只关心JVM是否实现了接口；JVM则负责根据底层API去适配，同一个Java文件可以在Windows调用CreateFile，在Linux调用open，而Java源码不需要改动一行。
Java标准库本身就这么干的
java.io.FileInputStream里有一个readBytes()方法，被声明为native。- JVM加载
libjava.so后，找到名称为Java_java_io_FileInputStream_readBytes的函数。 - 该函数在Unix平台上调用
read()系统调用，在Windows上调用ReadFile()。 - 所以你在Windows和Linux运行同一个Java程序,文件读取的底层路径完全不同，但结果一致。
native方法本身并不“跨平台”
这一点容易误会,Java代码跨平台，native动态库并不跨平台，一个.so文件不能直接在Windows上运行，所谓“跨平台”，指的是Java调用入口和调用方式不变，而动态库针对每个平台单独编译，开发者通常需要为不同CPU架构和操作系统构建多个版本的动态库。
jni跨平台原理：Java与C/C++的握手协议
JNI是一份协议,规定了Java虚拟机如何找到本地函数、如何传递参数、如何返回结果，没有这个协议，Java和C/C++就像两个说不同语言的人，没法握手。
JNI规范的几个核心约定
- 函数命名规则：
Java_包名_类名_方法名，包名中的点改为下划线。 - 数据类型映射：
jstring对应Java的String，jint对应Java的int，jobject对应任意Java对象。 - 方法查表机制：JVM在动态库中按名字查找符号，找到后直接建立调用关系。
- 返回值约定：本地函数返回
jobject或基本类型，JVM负责转换为Java可用的对象。
native方法如何与虚拟机中的对象交互
native函数会收到一个JNIEnv指针，这个指针指向一组函数表，通过这组函数，本地代码可以操作Java字段、调用Java方法、创建Java对象，比如GetObjectClass拿到对象类型，CallVoidMethod调用方法，这些操作仍然由JVM执行，本地代码不会直接访问Java堆内存，从而保证内存安全。
为什么说JNI是“跨平台”的桥梁？
- Java层只依赖
System.loadLibrary加载库名，不关心库路径细节。 - JVM根据平台自动拼接动态库前缀和后缀,比如
System.loadLibrary("my")在Linux上加载libmy.so，在Windows上加载my.dll。 - JNI函数签名与硬件架构无关,只要动态库导出符号正确，JVM就能调用。
哪些场景必须请native方法“出山”？从性能到硬件操作
不是所有Java代码都需要碰native方法,大多数Web业务、数据库访问、消息队列操作，纯Java已经足够，但有些场景，native方法几乎是唯一选择。
Java native方法性能对比：什么时候纯Java扛不住？
- 图形渲染和图像处理：OpenGL、OpenCV这类C/C++库已经封装好底层算法，直接用JNI调用比重新用Java写一遍快得多。
- 音视频编解码：FFmpeg、libvpx等库用汇编和SIMD指令优化过，Java调用native性能损失很小。
- 加密解密运算：底层crypto库往往利用硬件加速，Java包装层只做数据传递。
- 串口通信、USB设备控制：Java标准库不支持直接操作硬件，必须通过native方法访问驱动API。
行业共识认为,JNI更适合“复用成熟本地库”和“访问平台特有能力”，而不是单纯为了追求性能去写C代码，因为每次native调用都有跨边界开销，参数要转换、引用要管理，如果调用过于频繁，性能反而可能不如纯Java。
下表对比纯Java实现和native方法在不同维度的差异：
| 对比维度 | 纯Java实现 | native方法调用 |
|---|---|---|
| 跨平台能力 | 直接支持，一次编译处处运行 | 需要为每个平台编译动态库 |
| 执行性能 | 适合业务逻辑，JIT优化后够用 | 适合底层计算，但调用有边界开销 |
| 开发成本 | 低，语言自带回收机制 | 高，需要处理内存和异常 |
| 系统资源访问 | 受限，只能通过标准库 | 可直接调用操作系统API |
| 安全性 | 高，受JVM内存管理约束 | 低，本地代码崩溃会拖垮整个JVM |
本地代码的内存管理
native方法分配的内存不受Java堆管理,也不受垃圾回收控制，如果C代码里用了malloc，必须手动free，否则会内存泄漏，native方法可能通过NewGlobalRef创建全局引用，必须调用DeleteGlobalRef释放，否则Java对象永远无法被回收。
跨平台调用底层资源的常见坑：动态库加载与排查
实际项目里,不少开发者第一次遇到native方法时，会碰到UnsatisfiedLinkError，原因往往不复杂，但排查起来需要看几层。
System.loadLibrary加载失败的典型原因
- 库路径不对：动态库不在
java.library.path指定的目录里。 - 库名不匹配：JVM预期的是
libxxx.so或xxx.dll，实际文件名差一点都会失败。 - 依赖库缺失：本地库调用了其他第三方库，那些库没被打包。
- 架构不匹配：64位JVM加载了32位的动态库，会直接报错。
实操排查步骤
- 在Java代码里使用
System.out.println(System.getProperty("java.library.path"));
查看当前库路径。
- 把编译好的动态库放到该路径下,或者用
java -Djava.library.path=/your/dir指定路径。 - 通过
javap -s -p 类名查看native方法的完整签名，确认与C代码中的函数名一致。 - 通过
nm -D libxxx.so（Linux）或dumpbin /exports xxx.dll（Windows）查看动态库导出符号，看是否包含Java_开头的函数。 - 在C/C++代码中添加日志输出，确认函数是否被JVM找到并调用。
跨平台编译时要做什么
- 在Windows上使用MSVC或MinGW编译生成
.dll。 - 在Linux上使用GCC或Clang编译生成
.so。 - 在macOS上使用Clang编译生成
.dylib。 - Android需要借助NDK编译,且要为不同ABI（如
armeabi-v7a、arm64-v8a）分别生成.so。
Q&A：虚拟机中native方法跨平台调用底层资源的常见问题
Q1：native方法会被Java垃圾回收器清理吗？
不会,native方法本身是JVM中的方法定义，但其背后的本地资源由本地代码分配，例如C语言的malloc分配的内存、文件描述符等，垃圾回收器只管理Java堆中的对象，无法感知这些资源，程序员需要在native方法中主动调用释放函数，才能避免内存泄漏。
Q2：为什么不同平台必须编译不同的动态库？
因为底层系统API和二进制格式不一样,Windows使用PE格式，调用约定是__stdcall或__fastcall；Linux和macOS使用ELF格式，调用约定是SysV，这些差异无法用Java代码屏蔽，JNI规范解决了接口统一，却没有统一二进制格式，所以需要单独编译。
Q3：在Android中调用native方法有什么特别之处？
Android使用ART虚拟机,也兼容JNI规范，开发者通过NDK编写C/C++代码，使用Android.mk或CMake构建.so文件，然后放在app/src/main/jniLibs目录下，ART运行时同样按JNI规范查找函数，但内存管理和引用规则与标准JVM略有差异，例如需要避开Java EE中不存在于Android的API，事实是，JNI作为接口标准在Android和标准JVM中保持高度一致。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/729676.html
