JNI内存方面说明以及相关类型手动释放内存

简介: JNI内存方面说明以及相关类型手动释放内存

JNI内存方面说明以及相关类型手动释放内存

一、Java内存

二、JNI内存和引用

三、Local Reference

四、Global Reference

五、Weak Global Reference

六、注意点

6.1 Local Reference 不是 native code 的局部变量

6.2 注意释放所有对jobject的引用:

6.3 局部引用和全局引用的转换

6.4 多线程

七、手动释放内存

7.1 那些需要手动释放?

7.2 释放方法

7.2.1 jstring&char*

7.2.4 GetByteArrayElements

7.2.5 NewGlobalRef

7.3 避免内存泄露

参考文章


一、Java内存


Java程序所涉及的内存可以从逻辑上划分为两部分:Heap Memory和Native Memory。


1)Heap Memory:


供Java应用程序使用的,所有java对象的内存都是从这里分配的,它不是物理上连续的,但是逻辑上是连续的。可通过java命令行参数“-Xms, -Xmx”大设置Heap初始值和最大值。


java -Xmx1024m -Xms1024m

//-Xmx1024m:设置JVM最大可用内存为1024M。

//-Xms1024m:设置JVM初始内存为1024m。此值可与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。


在Android系统对于每个应用都有内存使用的限制,机器的内存限制,在/system/build.prop文件中配置的。可以在manifest文件application节点加入 android:largeHeap="true"来让Dalvik/ART虚拟机分配更大的堆内存空间


2)Native Memory:


也称为C-Heap,供Java Runtime进程使用的,没有相应的参数来控制其大小,其大小依赖于操作系统进程的最大值。


Java应用程序都是在Java Runtime Environment(JRE)中运行,而Runtime本身就是由Native语言(如:C/C++)编写程序。Native Memory就是操作系统分配给Runtime进程的可用内存,它与Heap Memory不同,Java Heap 是Java应用程序的内存。(JVM只是JRE的一部分,JVM的内存模型属于另一话题)


Native Memory的主要作用如下:


管理java heap的状态数据(用于GC);

JNI调用,也就是Native Stack;

JIT(即使编译器)编译时使用Native Memory,并且JIT的输入(Java字节码)和输出(可执行代码)也都是保存在Native Memory;

NIO direct buffer;

Threads;

类加载器和类信息都是保存在Native Memory中的。

 由上可以得知,JNI内存分配其实与Native Memory有很大关系。


二、JNI内存和引用


在Java代码中,Java对象被存放在JVM的Java Heap,由垃圾回收器(Garbage Collector,即GC)自动回收就可以。


在Native代码中,内存是从Native Memory中分配的,需要根据Native编程规范去操作内存。如:C/C++使用malloc()/new分配内存,需要手动使用free()/delete回收内存。


然而,JNI和上面两者又有些区别。


JNI提供了与Java相对应的引用类型(如:jobject、jstring、jclass、jarray、jintArray等),以便Native代码可以通过JNI函数访问到Java对象。引用所指向的Java对象通常就是存放在Java Heap,而Native代码持有的引用是存放在Native Memory中。


举个例子,如下代码:


jstring jstr = env->NewStringUTF("Hello World!");


 1)jstring类型是JNI提供的,对应于Java的String类型。


 2)JNI函数NewStringUTF()用于构造一个String对象,该对象存放在Java Heap中,同时返回了一个jstring类型的引用。


 3)String对象的引用保存在jstr中,jstr是Native的一个局部变量,存放在Native Memory中。


开发人员都应该遇到过OOM(Out of Memory)异常,在JNI开发中,该异常可能发生在Java Heap中,也可能发生在Native Memory中。


java.lang.OutOfMemoryError: Java heap space


java.lang.OutOfMemoryError: native memory exhausted


   Java Heap 中出现 Out of Memory异常的原因有两种:


   1)程序过于庞大,致使过多 Java 对象的同时存在;


   2)程序编写的错误导致 Java Heap 内存泄漏。


   Native Memory中出现 Out of Memory异常的原因:


   1)程序申请过多资源,系统未能满足,比如说大量线程资源;


   2)程序编写的错误导致Native Memory内存泄漏。


   为了避免出现OOM异常和内存泄露,我们在进行JNI开发的时候,需要熟悉它的内存分配和管理。


   JNI引用有三种:Local Reference、Global Reference、Weak Global Reference。下面分别来介绍一下这三种引用内存分配和管理。


三、Local Reference


只在Native Method执行时存在,只在创建它的线程有效,不能跨线程使用。它的生命期是在Native Method的执行期开始创建(从Java代码切换到Native代码环境时,或者在Native Method执行时调用JNI函数时),在Native Method执行完毕切换回Java代码时,所有Local Reference被删除(GC会回收其内存),生命期结束(调用DeleteLocalRef()可以提前回收内存,结束其生命期)。


实际上,每当线程从Java环境切换到Native代码环境时,JVM 会分配一块内存用于创建一个Local Reference Table,这个Table用来存放本次Native Method 执行中创建的所有Local Reference。每当在 Native代码中引用到一个Java对象时,JVM 就会在这个Table中创建一个Local Reference。比如,我们调用 NewStringUTF() 在 Java Heap 中创建一个 String 对象后,在 Local Reference Table 中就会相应新增一个 Local Reference。


Local Reference 表、Local Reference 和 Java 对象的关系


接下来举个简单例子说明一下:

jstring jstr = env->NewStringUTF("Hello World!");

jstr存放在Native Method Stack中,是一个局部变量

对于开发者来说,Local Reference Table是不可见的

Local Reference Table的内存不大,所能存放的Local Reference数量也是有限的(在Android中默认最大容量是512个),使用不当就会引起溢出异常

Local Reference并不是Native里面的局部变量,局部变量存放在堆栈中,其引用存放在Local Reference Table中。

在Native Method结束时,JVM会自动释放Local Reference,但Local Reference Table是有大小限制的,在开发中应该及时使用DeleteLocalRef()删除不必要的Local Reference,不然可能会出现溢出错误:


JNI ERROR (app bug): local reference table overflow (max=512)


在C/C++中实例化的JNI对象,如果不返回java,必须用release掉或delete,否则内存泄露。包括NewStringUTF,NewObject。对于一般的基本数据类型(如:jint,jdouble等),是没必要调用该函数删除掉的。如果返回java不必delete,java会自己回收。


四、Global Reference


Local Reference是在Native Method执行的时候出现的,而Global Reference是通过JNI函数NewGlobalRef()和DeleteGlobalRef()来创建和删除的。 Global Reference具有全局性,可以在多个Native Method调用过程和多线程中使用,在主动调用DeleteGlobalRef之前,它是一直有效的(GC不会回收其内存)。

/**
* 创建obj参数所引用对象的新全局引用。obj参数既可以是全局引用,也可以是局部引用。全局引用通过调用DeleteGlobalRef()来显式撤消。
* @param obj 全局或局部引用。
* @return 返回全局引用。如果系统内存不足则返回 NULL。
*/
jobject NewGlobalRef(jobject obj);
/**
* 删除globalRef所指向的全局引用
* @param globalRef 全局引用
*/
void DeleteGlobalRef(jobject globalRef);

使用 Global reference时,当 native code 不再需要访问Global reference 时,应当调用 JNI 函数 DeleteGlobalRef() 删除 Global reference和它引用的 Java 对象。否则Global Reference引用的 Java 对象将永远停留在 Java Heap 中,从而导致 Java Heap 的内存泄漏。


五、Weak Global Reference


用NewWeakGlobalRef()和DeleteWeakGlobalRef()进行创建和删除,它与Global Reference的区别在于该类型的引用随时都可能被GC回收。


对于Weak Global Reference而言,可以通过isSameObject()将其与NULL比较,看看是否已经被回收了。如果返回JNI_TRUE,则表示已经被回收了,需要重新初始化弱全局引用。Weak Global Reference的回收时机是不确定的,有可能在前一行代码判断它是可用的,后一行代码就被GC回收掉了。为了避免这事事情发生,JNI官方给出了正确的做法,通过NewLocalRef()获取Weak Global Reference,避免被GC回收。


六、注意点


6.1 Local Reference 不是 native code 的局部变量


很多人会误将 JNI 中的 Local Reference 理解为 Native Code 的局部变量。这是错误的。


Native Code 的局部变量和 Local Reference 是完全不同的,区别可以总结为:


⑴局部变量存储在线程堆栈中,而 Local Reference 存储在 Local Ref 表中。


⑵局部变量在函数退栈后被删除,而 Local Reference 在调用 DeleteLocalRef() 后才会从 Local Ref 表中删除,并且失效,或者在整个 Native Method 执行结束后被删除。


⑶可以在代码中直接访问局部变量,而 Local Reference 的内容无法在代码中直接访问,必须通过 JNI function 间接访问。JNI function 实现了对 Local Reference 的间接访问,JNI function 的内部实现依赖于具体 JVM。


6.2 注意释放所有对jobject的引用:

extern "C"
JNIEXPORT jstring JNICALL
Java_com_test_application_MainActivity_init(JNIEnv *env, jobject instance, jstring data,jbyteArray array) {
    int len = env->GetArrayLength(array);
    const char *utfChars = env->GetStringUTFChars(data, 0);
    jbyte *arrayElements = env->GetByteArrayElements(array, NULL);
    jstring pJstring = env->NewStringUTF(utfChars);
    jbyteArray jpicArray = env->NewByteArray(len);
    env->SetByteArrayRegion(jpicArray, 0, len, arrayElements);
    // TODO
    env->DeleteLocalRef(pJstring);
    env->DeleteLocalRef(jpicArray);
    env->ReleaseStringUTFChars(data, utfChars);
    env->ReleaseByteArrayElements(array, arrayElements, 0);
    std::string hello = "Hello from C++";
    jstring result = env->NewStringUTF(hello.c_str());
    return result;
}

其它的还有:

jclass ref= (env)->FindClass("java/lang/String");
env->DeleteLocalRef(ref);

因为根据jni.h里的定义:

typedef jobject jclass;

jclass也是jobject。而jmethodID/jfielID和jobject没有继承关系,它们不是object,只是个整数,不存在被释放与否的问题。


6.3 局部引用和全局引用的转换


注意Local Reference的生命周期,如果在Native中需要长时间持有一个Java对象,就不能使用将jobject存储在Native,否则在下次使用的时候,即使同一个线程调用,也将会无法使用。下面是错误的做法:

jstring global;
extern "C" JNIEXPORT jstring JNICALL
Java_org_hik_libyuv_MainActivity_stringFromJNI(JNIEnv *env,jobject /* this */) {
    std::string hello = "Hello from C++";
    jstring local = env->NewStringUTF(hello.c_str());
    global = local;
    return local;
}

正确的做法是使用Global Reference,如下:

jstring global;
extern "C" JNIEXPORT jstring JNICALL
Java_org_hik_libyuv_MainActivity_stringFromJNI(JNIEnv *env,jobject /* this */) {
    std::string hello = "Hello from C++";
    jstring local = env->NewStringUTF(hello.c_str());
    global = static_cast<jstring>(env->NewGlobalRef(global));
    return local;
}


6.4 多线程


JNIEnv和jobject对象都不能跨线程使用。 对于jobject,解决办法是:

a、m_obj = env->NewGlobalRef(obj);//创建一个全局变量
b、jobject obj = env->AllocObject(m_cls);//在每个线程中都生成一个对象

对于JNIEnv,解决办法是在每个线程中都重新生成一个env

JavaVM *gJavaVM;//声明全局变量
(*env)->GetJavaVM(env, &gJavaVM);//在JNI方法的中赋值
JNIEnv *env;//在其它线程中获取当前线程的env
m_jvm->AttachCurrentThread((void **)&env, NULL);

当在一个线程里面调用AttachCurrentThread后,如果不需要用的时候一定要DetachCurrentThread,否则线程无法正常退出,导致JNI环境一直被占用。


七、手动释放内存


7.1 那些需要手动释放?


·不需要手动释放(基本类型):jint,jlong,jchar,jdouble等


·需要手动释放(引用类型,数组家族):jstring,jobject,jobjectArray,jintArray,jclass等


7.2 释放方法


7.2.1 jstring&char*


// 创建 jstring 和 char*
jstring jstr = (*jniEnv)->CallObjectMethod(jniEnv, mPerson, getName);
char* cstr = (char*) (*jniEnv)->GetStringUTFChars(jniEnv,jstr, 0);
// 释放 
(*jniEnv)->ReleaseStringUTFChars(jniEnv, jstr, cstr);
(*jniEnv)->DeleteLocalRef(jniEnv, jstr);

7.2.2 jobject,jobjectArray,jclass 等引用类型

(*jniEnv)->DeleteLocalRef(jniEnv, XXX);

7.2.3 jbyteArray

jbyteArray audioArray = jnienv->NewByteArray(frameSize);
jnienv->DeleteLocalRef(audioArray);


7.2.4 GetByteArrayElements

jbyte* array= (*env)->GetByteArrayElements(env,jarray,&isCopy);
(*env)->ReleaseByteArrayElements(env,jarray,array,0);


7.2.5 NewGlobalRef

jobject ref= env->NewGlobalRef(customObj);
env->DeleteGlobalRef(customObj);


7.3 避免内存泄露


JNI如果创建以上引用却不手动释放的话很容易就造成内存泄露,所以JNI编程创建的引用类型一定要手动释放(切身教训),检测内存泄露可以使用Jprofiler


参考文章


C++调用JAVA方法详解

JNI内存管理

Java 虚拟机

目录
相关文章
|
2月前
|
监控 算法 Java
深入理解Java中的垃圾回收机制在Java编程中,垃圾回收(Garbage Collection, GC)是一个核心概念,它自动管理内存,帮助开发者避免内存泄漏和溢出问题。本文将探讨Java中的垃圾回收机制,包括其基本原理、不同类型的垃圾收集器以及如何调优垃圾回收性能。通过深入浅出的方式,让读者对Java的垃圾回收有一个全面的认识。
本文详细介绍了Java中的垃圾回收机制,从基本原理到不同类型垃圾收集器的工作原理,再到实际调优策略。通过通俗易懂的语言和条理清晰的解释,帮助读者更好地理解和应用Java的垃圾回收技术,从而编写出更高效、稳定的Java应用程序。
|
2月前
|
安全 Java API
【性能与安全的双重飞跃】JDK 22外部函数与内存API:JNI的继任者,引领Java新潮流!
【9月更文挑战第7天】JDK 22外部函数与内存API的发布,标志着Java在性能与安全性方面实现了双重飞跃。作为JNI的继任者,这一新特性不仅简化了Java与本地代码的交互过程,还提升了程序的性能和安全性。我们有理由相信,在外部函数与内存API的引领下,Java将开启一个全新的编程时代,为开发者们带来更加高效、更加安全的编程体验。让我们共同期待Java在未来的辉煌成就!
62 11
|
2月前
|
安全 Java API
【本地与Java无缝对接】JDK 22外部函数和内存API:JNI终结者,性能与安全双提升!
【9月更文挑战第6天】JDK 22的外部函数和内存API无疑是Java编程语言发展史上的一个重要里程碑。它不仅解决了JNI的诸多局限和挑战,还为Java与本地代码的互操作提供了更加高效、安全和简洁的解决方案。随着FFM API的逐渐成熟和完善,我们有理由相信,Java将在更多领域展现出其强大的生命力和竞争力。让我们共同期待Java编程新纪元的到来!
90 11
|
2月前
|
编译器 Linux API
基于类型化 memoryview 让 Numpy 数组和 C 数组共享内存
基于类型化 memoryview 让 Numpy 数组和 C 数组共享内存
32 0
|
3月前
|
存储 Java 程序员
Java中对象几种类型的内存分配(JVM对象储存机制)
Java中对象几种类型的内存分配(JVM对象储存机制)
77 5
Java中对象几种类型的内存分配(JVM对象储存机制)
|
3月前
|
Python
Python变量的作用域_参数类型_传递过程内存分析
理解Python中的变量作用域、参数类型和参数传递过程,对于编写高效和健壮的代码至关重要。正确的应用这些概念,有助于避免程序中的错误和内存泄漏。通过实践和经验积累,可以更好地理解Python的内存模型,并编写出更优质的代码。
28 2
|
4月前
|
Arthas 存储 Java
JVM内存问题之Linux使用ptmalloc2导致的JNI内存溢出问题如何解决
JVM内存问题之Linux使用ptmalloc2导致的JNI内存溢出问题如何解决
|
4月前
|
Arthas 监控 Java
JVM内存问题之使用gperftools分析JNI Memory泄漏的具体步骤是什么
JVM内存问题之使用gperftools分析JNI Memory泄漏的具体步骤是什么
|
4月前
|
Arthas 存储 监控
JVM内存问题之JNI内存泄漏没有关联的异常类型吗
JVM内存问题之JNI内存泄漏没有关联的异常类型吗
|
3月前
|
存储 编译器 C语言
【C语言篇】数据在内存中的存储(超详细)
浮点数就采⽤下⾯的规则表⽰,即指数E的真实值加上127(或1023),再将有效数字M去掉整数部分的1。
328 0