当前位置：首页 > 文章列表 > 文章 > java教程 > JavaJNI教程：本地方法调用实战详解

JavaJNI教程：本地方法调用实战详解

2025-07-05 14:36:27 0浏览收藏

本篇文章给大家分享《Java JNI开发教程：本地方法调用实战指南》，覆盖了文章的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

JNI开发的核心在于通过一套标准流程实现Java与C/C++的交互。具体步骤为：1.在Java中声明native方法并加载本地库；2.使用javac生成JNI头文件；3.根据头文件实现C/C++代码；4.编译生成动态链接库；5.运行Java程序并确保库路径正确。JNIEnv指针是JNI操作的关键，它提供与JVM交互的函数接口，且具有线程局部性。数据类型转换方面，基本类型较简单，字符串需注意GetStringUTFChars后必须调用ReleaseStringUTFChars释放内存，数组操作类似，对象访问需准确获取字段和方法ID。内存管理上，局部引用随方法返回自动释放但可能引发引用表溢出，可通过Push/PopLocalFrame或DeleteLocalRef处理；全局引用需手动创建和销毁，常用于缓存类对象；Get/Release系列函数配对使用以避免泄漏；异常处理时应确保资源释放。总之，JNI开发需细致管理所有资源，理解流程优先于记忆API。

Java如何进行JNI开发？本地方法调用实践

Java进行JNI开发，核心在于让Java代码能够调用C/C++等本地语言编写的功能。这就像是为JVM打开了一扇门，让它能触及那些Java本身不擅长或无法直接完成的任务，比如直接操作硬件、利用现有C/C++库、或者追求极致的性能优化。本质上，它是在JVM和本地代码之间搭建一座桥梁，实现双向通信。

解决方案

JNI（Java Native Interface）的开发流程，说白了，就是一套约定俗成的步骤，确保Java虚拟机能正确找到并执行你用其他语言写的代码。我个人觉得，理解这套流程比记住每个API名字更重要，因为一旦流程清晰，那些API自然就水到渠成了。

在Java中声明本地方法： 首先，你得告诉Java，某个方法不是用Java写的，而是要从外部加载。这很简单，就是在方法签名前面加上native关键字，并且不需要方法体。

// MyNativeLib.java
public class MyNativeLib {
    // 静态代码块，用于加载本地库
    static {
        System.loadLibrary("mynativelib"); // 库名称，不含前缀和后缀
    }

    // 声明一个本地方法，接收一个字符串，返回一个字符串
    public native String processString(String input);

    public static void main(String[] args) {
        MyNativeLib lib = new MyNativeLib();
        String result = lib.processString("Hello from Java!");
        System.out.println("Native method returned: " + result);
    }
}

这里System.loadLibrary("mynativelib")就是告诉JVM去哪里找那个本地库。在Windows上它会找mynativelib.dll，Linux上是libmynativelib.so，macOS上是libmynativelib.dylib。

生成C/C++头文件： Java编译器（javac）提供了一个非常方便的功能，可以根据你的Java类生成对应的JNI头文件。这个头文件定义了C/C++函数签名，JVM会通过这些签名来调用你的本地方法。在命令行中，编译Java类后：

javac MyNativeLib.java
javah MyNativeLib // 或者 javac -h . MyNativeLib.java (新版本推荐)

这会生成一个名为MyNativeLib.h的文件。打开它，你会看到类似这样的函数声明：

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class MyNativeLib */

#ifndef _Included_MyNativeLib
#define _Included_MyNativeLib
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     MyNativeLib
 * Method:    processString
 * Signature: (Ljava/lang/String;)Ljava/lang/String;
 */
JNIEXPORT jstring JNICALL Java_MyNativeLib_processString
  (JNIEnv *, jobject, jstring);

#ifdef __cplusplus
}
#endif
#endif

注意那个Java_MyNativeLib_processString，这是JNI函数命名约定，由Java_ + 包名 + 类名 + 方法名组成。

实现C/C++本地方法： 现在，根据生成的头文件，用C或C++来编写你的本地方法实现。

// MyNativeLib.cpp
#include "MyNativeLib.h" // 包含刚才生成的头文件
#include <iostream>
#include <string>

// JNIEXPORT 和 JNICALL 是JNI的宏，确保函数能够被正确导出和调用
JNIEXPORT jstring JNICALL Java_MyNativeLib_processString
  (JNIEnv *env, jobject obj, jstring javaInputString) {
    // 将Java字符串转换为C++字符串
    const char *c_str = env->GetStringUTFChars(javaInputString, NULL);
    if (c_str == NULL) {
        // 内存不足或编码问题，通常会抛出异常
        return NULL;
    }
    std::string cppInput(c_str);
    env->ReleaseStringUTFChars(javaInputString, c_str); // 释放JNI分配的内存

    std::cout << "Received from Java: " << cppInput << std::endl;

    // 在C++中处理字符串
    std::string cppOutput = "Processed: " + cppInput + " (from C++)";

    // 将C++字符串转换回Java字符串
    return env->NewStringUTF(cppOutput.c_str());
}

这里面涉及到了JNIEnv指针，jobject参数，以及Java和C/C++之间的数据类型转换。

编译本地库： 使用C/C++编译器（如GCC、Clang或Visual C++）将你的C/C++源文件编译成动态链接库（DLL、SO或DYLIB）。编译时需要包含JDK的JNI头文件路径。例如，在Linux上使用GCC：
```
g++ -I"${JAVA_HOME}/include" -I"${JAVA_HOME}/include/linux" -shared -o libmynativelib.so MyNativeLib.cpp
```
-I指定了头文件路径，-shared表示编译成共享库，-o指定输出文件名。
运行Java应用程序： 最后，运行你的Java应用程序。确保你编译好的本地库文件在Java的java.library.path中，或者直接在运行时通过-Djava.library.path指定。
```
java -Djava.library.path=. MyNativeLib
```
如果一切顺利，你会看到Java程序成功调用了C++代码并打印出结果。

JNIEnv指针在本地方法中扮演什么角色？

说实话，JNIEnv指针是JNI开发中的绝对核心，没有它，你几乎什么都做不了。你可以把它想象成JVM为当前本地线程提供的一个“服务员”或者“操作接口”。每当Java代码调用一个本地方法时，JVM都会把这个JNIEnv指针作为第一个参数传给本地方法。

这个JNIEnv指针实际上指向了一张函数指针表，这张表里包含了大量的函数，这些函数就是你用来和JVM交互的API。比如，你想从Java字符串获取C字符串，或者想在C/C++中创建一个新的Java对象，甚至是在本地代码中调用Java对象的方法或者抛出Java异常，这些操作都得通过JNIEnv提供的函数来完成。

举个例子，我在MyNativeLib.cpp里用了env->GetStringUTFChars(javaInputString, NULL)和env->NewStringUTF(cppOutput.c_str())。GetStringUTFChars就是通过JNIEnv来获取Java字符串的UTF-8表示，而NewStringUTF则是用来创建新的Java字符串。

需要特别强调的是，JNIEnv指针是线程局部（thread-local）的。这意味着每个调用JNI方法的线程都会有它自己的JNIEnv副本。你不能在一个线程中获取JNIEnv指针，然后在另一个线程中使用它。如果需要在不同线程之间传递JNIEnv，那通常说明你的设计有点问题，或者你需要更高级的JNI线程管理，比如通过JavaVM指针来AttachCurrentThread。

处理Java与C/C++数据类型转换的常见陷阱有哪些？

数据类型转换是JNI开发里一个特别容易出问题的地方，尤其是在处理非基本类型时。我记得有一次，就是因为字符串没有正确释放，导致内存泄漏，排查了很久。

基本数据类型： 这个相对简单，JNI提供了直接的映射：jint对应Java的int，jboolean对应boolean，jfloat对应float等等。它们是直接值传递，通常不会有什么陷阱。
字符串 (String)： Java的String是Unicode编码，而C/C++通常处理的是char*（C风格字符串，可能是UTF-8、ASCII等）。
- Java到C/C++： 你会用到env->GetStringUTFChars(jstring, isCopy)。这个函数会返回一个指向C风格UTF-8字符串的指针。*最大的陷阱在于：你必须在用完后调用`env->ReleaseStringUTFChars(jstring, char)来释放JVM为你分配的内存。** 如果不释放，就会造成内存泄漏。isCopy参数也很关键，如果设为NULL，JVM可能会返回原始字符串的直接指针，也可能返回一个副本，但无论如何，你都必须调用Release`。
- C/C++到Java： 使用env->NewStringUTF(const char*)。这个函数会创建一个新的Java String对象。这里相对安全，因为JVM会管理这个新创建的Java对象的内存。
数组 (Array)： Java数组在JNI中也有对应的jarray类型，比如jintArray、jobjectArray。
- 获取数组元素： 类似字符串，你需要使用env->GetArrayElements(jarray, isCopy)（例如GetIntArrayElements）。同样，用完后必须调用env->ReleaseArrayElements(jarray, pointer, mode)来释放。 mode参数决定了是写回Java数组并释放，还是只释放。不释放依然是内存泄漏的元凶。
- 对象数组： jobjectArray稍微复杂，你需要用env->GetObjectArrayElement(jobjectArray, index)获取单个元素，然后可能需要对该元素进行类型转换或进一步操作。创建对象数组则用env->NewObjectArray(length, elementClass, initialElement)。
对象 (Object)： 这是最复杂的部分。Java对象在C/C++中表现为jobject或其子类（如jclass、jthrowable）。
- 访问字段和方法： 你需要先获取字段ID (GetFieldID) 或方法ID (GetMethodID)，然后才能通过这些ID来获取或设置字段值，或者调用方法。例如：
```
jclass clazz = env->GetObjectClass(obj); // 获取对象的类
jfieldID fieldId = env->GetFieldID(clazz, "fieldName", "Ljava/lang/String;"); // 获取字段ID
jstring fieldValue = (jstring)env->GetObjectField(obj, fieldId); // 获取字段值
```
  这里的陷阱在于：字段签名和方法签名必须完全正确，包括参数类型和返回类型。一个字母不对，GetFieldID或GetMethodID就会返回NULL，并且JVM会抛出NoSuchFieldError或NoSuchMethodError。
- 局部引用与全局引用： 这是JNI内存管理的一个大坑。JNI返回给你的jobject、jstring、jarray等，默认都是“局部引用”（Local Reference）。这意味着它们只在当前本地方法调用期间有效，当本地方法返回后，JVM会自动回收它们。但是，如果你想在多次JNI调用之间保留一个Java对象（比如缓存一个jclass对象），或者在本地线程中主动创建Java对象，你就需要将其提升为“全局引用”（Global Reference），使用env->NewGlobalRef(jobject)。全局引用不会被JVM自动回收，你必须在不再需要时显式调用env->DeleteGlobalRef(jobject)来释放它，否则会导致内存泄漏。 还有一种“弱全局引用”（Weak Global Reference），用于缓存对象但允许被GC回收。

JNI开发中如何有效管理内存和避免资源泄露？

内存管理在JNI里是个永恒的话题，也是导致程序崩溃或性能下降的常见原因。我的经验是，对待JNI分配的资源，要像对待C/C++里的malloc一样小心翼翼。

理解局部引用（Local References）的生命周期： 如前所述，JNI本地方法中创建或返回的jobject、jstring、jarray等都是局部引用。它们在本地方法执行完毕返回Java代码后会自动被JVM回收。这听起来很方便，但也有陷阱：如果一个本地方法在内部创建了大量的局部引用（比如在一个循环里处理一个大数组，每次循环都创建新的Java对象），这些引用可能会在方法返回前就耗尽JVM为当前线程分配的局部引用表空间，导致OutOfMemoryError。
- 解决方案： 在处理大量局部引用时，可以使用env->PushLocalFrame(capacity)和env->PopLocalFrame(result)来创建临时的局部引用帧。在PopLocalFrame时，该帧内创建的所有局部引用都会被释放，除了你指定为返回值的那个。或者，更直接地，使用env->DeleteLocalRef(jobject)来手动释放不再需要的局部引用。
严格管理全局引用（Global References）： 全局引用是跨JNI方法调用、跨线程持久存在的。它们不会被JVM自动回收，因此必须由开发者手动管理。
- 用途： 缓存jclass对象（类查找是开销较大的操作），或者在本地代码中长期持有一个Java对象的引用。
- 管理： 使用env->NewGlobalRef(jobject)创建，使用env->DeleteGlobalRef(jobject)销毁。忘记销毁是典型的内存泄漏。
- 最佳实践： 尽量减少全局引用的使用。如果必须使用，确保它们在程序生命周期结束时或者不再需要时被正确释放。可以考虑使用智能指针（如C++11的std::unique_ptr配合自定义deleter）来管理全局引用，或者在JNI_OnUnload函数中进行统一清理。
释放通过Get...Chars/Get...Elements获取的内存： 这是最常见的资源泄漏之一。无论你从GetStringUTFChars、GetStringChars、GetArrayElements等函数中获取了什么指针，用完之后，一定要调用对应的Release...函数来释放。例如：
- env->ReleaseStringUTFChars(jstring, const char*)
- env->ReleaseIntArrayElements(jintArray, jint*, jint) 忘记释放这些资源，会导致JVM内部的内存泄漏，最终耗尽内存。mode参数在Release...ArrayElements中也很重要，JNI_COMMIT（0）表示将更改写回Java数组并释放，JNI_ABORT（2）表示不写回，只释放，0（JNI_COMMIT）通常是默认行为。
本地（Native）内存管理： 如果在C/C++代码中使用了malloc、new等分配了本地内存，那么你必须负责使用free、delete来释放它们。JNI本身不会管理你用C/C++分配的内存。这是一个纯粹的C/C++内存管理问题，但在JNI环境中，如果处理不当，同样会导致资源泄漏，影响整个应用的稳定性。
异常处理中的资源释放： 当本地方法中发生异常（比如JVM抛出异常，或者你通过env->ThrowNew主动抛出异常）时，正常的代码执行路径可能会被中断。这意味着你原本用来释放资源的Release...调用可能不会被执行。
- 解决方案： 在C++中，可以利用RAII（Resource Acquisition Is Initialization）原则，通过自定义的类或智能指针来确保资源在离开作用域时被释放。在C语言中，通常会使用goto语句来跳到统一的清理代码块。在抛出异常前，务必确保所有已分配的JNI资源和本地资源都得到了妥善处理。