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.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。
立即学习“Java免费学习笔记(深入)”;
生成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指针是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。
数据类型转换是JNI开发里一个特别容易出问题的地方,尤其是在处理非基本类型时。我记得有一次,就是因为字符串没有正确释放,导致内存泄漏,排查了很久。
基本数据类型:
这个相对简单,JNI提供了直接的映射:jint对应Java的int,jboolean对应boolean,jfloat对应float等等。它们是直接值传递,通常不会有什么陷阱。
字符串 (String):
Java的String是Unicode编码,而C/C++通常处理的是char*(C风格字符串,可能是UTF-8、ASCII等)。
env->GetStringUTFChars(jstring, isCopy)。这个函数会返回一个指向C风格UTF-8字符串的指针。*最大的陷阱在于:你必须在用完后调用`env->ReleaseStringUTFChars(jstring, char)来释放JVM为你分配的内存。** 如果不释放,就会造成内存泄漏。isCopy参数也很关键,如果设为NULL,JVM可能会返回原始字符串的直接指针,也可能返回一个副本,但无论如何,你都必须调用Release`。env->NewStringUTF(const char*)。这个函数会创建一个新的Java String对象。这里相对安全,因为JVM会管理这个新创建的Java对象的内存。数组 (Array):
Java数组在JNI中也有对应的jarray类型,比如jintArray、jobjectArray。
env->Get<Primitive>ArrayElements(jarray, isCopy)(例如GetIntArrayElements)。同样,用完后必须调用env->Release<Primitive>ArrayElements(jarray, pointer, mode)来释放。 mode参数决定了是写回Java数组并释放,还是只释放。不释放依然是内存泄漏的元凶。jobjectArray稍微复杂,你需要用env->GetObjectArrayElement(jobjectArray, index)获取单个元素,然后可能需要对该元素进行类型转换或进一步操作。创建对象数组则用env->NewObjectArray(length, elementClass, initialElement)。对象 (Object):
这是最复杂的部分。Java对象在C/C++中表现为jobject或其子类(如jclass、jthrowable)。
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。
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分配的资源,要像对待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)销毁。忘记销毁是典型的内存泄漏。std::unique_ptr配合自定义deleter)来管理全局引用,或者在JNI_OnUnload函数中进行统一清理。释放通过Get...Chars/Get...Elements获取的内存:
这是最常见的资源泄漏之一。无论你从GetStringUTFChars、GetStringChars、Get<Primitive>ArrayElements等函数中获取了什么指针,用完之后,一定要调用对应的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...调用可能不会被执行。
goto语句来跳到统一的清理代码块。在抛出异常前,务必确保所有已分配的JNI资源和本地资源都得到了妥善处理。总之,JNI的内存管理需要一种近乎偏执的细致。每当你从JNI函数得到一个指针或引用时,脑子里就应该立刻响起警报:我该如何以及何时释放它?这种思维模式能帮你避开大部分的内存陷阱。
以上就是Java如何进行JNI开发?本地方法调用实践的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号