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代码能够调用C/C++等本地语言编写的功能。这就像是为JVM打开了一扇门，让它能触及那些Java本身不擅长或无法直接完成的任务，比如直接操作硬件、利用现有C/C++库、或者追求极致的性能优化。本质上，它是在JVM和本地代码之间搭建一座桥梁，实现双向通信。
解决方案
JNI（Java Native Interface）的开发流程，说白了，就是一套约定俗成的步骤，确保Java虚拟机能正确找到并执行你用其他语言写的代码。我个人觉得，理解这套流程比记住每个API名字更重要，因为一旦流程清晰，那些API自然就水到渠成了。
在Java中声明本地方法：首先，你得告诉Java，某个方法不是用Java写的，而是要从外部加载。这很简单，就是在方法签名前面加上native关键字，并且不需要方法体。
// MyNativeLib.javapublic 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。
立即学习“Java免费学习笔记（深入）”；
生成C/C++头文件：Java编译器（javac）提供了一个非常方便的功能，可以根据你的Java类生成对应的JNI头文件。这个头文件定义了C/C++函数签名，JVM会通过这些签名来调用你的本地方法。在命令行中，编译Java类后：
javac MyNativeLib.javajavah MyNativeLib // 或者 javac -h . MyNativeLib.java (新版本推荐)
这会生成一个名为MyNativeLib.h的文件。打开它，你会看到类似这样的函数声明：
/* DO NOT EDIT THIS FILE - it is machine generated */#include /* Header for class MyNativeLib */#ifndef _Included_MyNativeLib#define _Included_MyNativeLib#ifdef __cplusplusextern "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 #include // 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 <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;"); // 获取字段IDjstring 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资源和本地资源都得到了妥善处理。
总之，JNI的内存管理需要一种近乎偏执的细致。每当你从JNI函数得到一个指针或引用时，脑子里就应该立刻响起警报：我该如何以及何时释放它？这种思维模式能帮你避开大部分的内存陷阱。
以上就是Java如何进行JNI开发？本地方法调用实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/146091.html
微信扫一扫 
支付宝扫一扫 
