（转）JNI内存管理及优化

最近接触JNI相关的项目遇到一些与内存相关到问题，JNI或者说是C/C++开发与平时的Java开发相比，总会给人更多的“惊喜”，因为不熟悉native开发，所以有很多知识都不太清楚，一点一点地记录。
在掘金相关搜索到下面这篇，个人感觉还不错。
以下内容转载自：

https://juejin.cn/post/6844903743352209422

上面这张图大家都应该很熟了，下面只讲下和JNI有关的部分

程序计数器

记录正在执行的虚拟机字节码指令的地址（如果正在执行的是本地方法则为空）。

本地方法栈

本地方法栈与 Java 虚拟机栈类似，它们之间的区别只不过是本地方法栈为本地方法服务。本地方法一般是用其它语言（C、C++ 或汇编语言等）编写的，并且被编译为基于本机硬件和操作系统的程序，对待这些方法需要特别处理。

堆(Java-Heap)

所有对象都在这里分配内存，是垃圾收集的主要区域（”GC 堆”）。堆不需要连续内存，并且可以动态增加其内存，增加失败会抛出 OutOfMemoryError 异常。

可以通过 -Xms 和 -Xmx 两个虚拟机参数来指定一个程序的堆内存大小，第一个参数设置初始值，第二个参数设置最大值。

1
2
3

java -Xmx1024m -Xms1024m
//-Xmx1024m：设置JVM最大可用内存为1024M。
//-Xms1024m：设置JVM初始内存为1024m。此值可与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。

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

直接内存（native堆）

也称为C-Heap，供Java Runtime进程使用的，没有相应的参数来控制其大小，其大小依赖于操作系统进程的最大值。 Java应用程序都是在Java Runtime Environment（JRE）中运行，而Runtime本身就是由Native语言（如：C/C++）编写程序。Native Memory就是操作系统分配给Runtime进程的可用内存，它与Heap Memory不同，Java Heap 是Java应用程序的内存。。Native Memory的主要作用如下：

管理java heap的状态数据（用于GC）;
JNI调用，也就是Native Stack；
JIT（即使编译器）编译时使用Native Memory，并且JIT的输入（Java字节码）和输出（可执行代码）也都是保存在Native Memory；
NIO direct buffer；
Threads；
类加载器和类信息都是保存在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中。

举个例子，如下代码：

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

jstring类型是JNI提供的，对应于Java的String类型
JNI函数NewStringUTF()用于构造一个String对象，该对象存放在Java Heap中，同时返回了一个jstring类型的引用。
String对象的引用保存在jstr中，jstr是Native的一个局部变量，存放在Native Memory中。

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

string类型是JNI提供的，对应于Java的String类型
JNI函数NewStringUTF()用于构造一个String对象，该对象存放在Java Heap中，同时返回了一个jstring类型的引用。
String对象的引用保存在jstr中，jstr是Native的一个局部变量，存放在Native Memory中。

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

1 2	java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: native memory exhausted

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

1 2	1）程序过于庞大，致使过多 Java 对象的同时存在； 2）程序编写的错误导致 Java Heap 内存泄漏。

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

1 2	1）程序申请过多资源，系统未能满足，比如说大量线程资源； 2）程序编写的错误导致Native Memory内存泄漏。

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 对象的关系

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

1	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，不然可能会出现溢出错误：

1	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回收。

注意点

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。

注意释放所有对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里的定义：

1	typedef jobject jclass;

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

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

注意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;
}

多线程

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

1
2
3

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);

当在一个线程里面调用AttachCurrentThr