在 JNI 编程中避免内存泄漏
JNI 编程简介JNI，Java Native Interface，是 native code 的编程接口。JNI 使 Java 代码程序可以与 native code 交互——在 Java 程序中调用 native code；在 native code 中嵌入 Java 虚拟机调用 Java 的代码。JNI 编程在软件开发中运用广泛，其优势可以归结为以下几点：
利用 native code 的平台相关性，在平台相关的编程中彰显优势。
对 native code 的代码重用。
native code 底层操作，更加高效。然而任何事物都具有两面性，JNI 编程也同样如此。程序员在使用 JNI 时应当认识到 JNI 编程中如下的几点弊端，扬长避短，才可以写出更加完善、高性能的代码：
从 Java 环境到 native code 的上下文切换耗时、低效。
JNI 编程，如果操作不当，可能引起 Java 虚拟机的崩溃。
JNI 编程，如果操作不当，可能引起内存泄漏。JAVA 中的内存泄漏JAVA 编程中的内存泄漏，从泄漏的内存位置角度可以分为两种：JVM 中 Java Heap 的内存泄漏；JVM 内存中 native memory 的内存泄漏。Java Heap 的内存泄漏Java 对象存储在 JVM 进程空间中的 Java Heap 中，Java Heap 可以在 JVM 运行过程中动态变化。如果 Java 对象越来越多，占据 Java Heap 的空间也越来越大，JVM 会在运行时扩充 Java Heap 的容量。如果 Java Heap 容量扩充到上限，并且在 GC 后仍然没有足够空间分配新的 Java 对象，便会抛出 out of memory 异常，导致 JVM 进程崩溃。Java Heap 中 out of memory 异常的出现有两种原因——①程序过于庞大，致使过多 Java 对象的同时存在；②程序编写的错误导致 Java Heap 内存泄漏。多种原因可能导致 Java Heap 内存泄漏。JNI 编程错误也可能导致 Java Heap 的内存泄漏。JVM 中 native memory 的内存泄漏从操作系统角度看，JVM 在运行时和其它进程没有本质区别。在系统级别上，它们具有同样的调度机制，同样的内存分配方式，同样的内存格局。JVM 进程空间中，Java Heap 以外的内存空间称为 JVM 的 native memory。进程的很多资源都是存储在 JVM 的 native memory 中，例如载入的代码映像，线程的堆栈，线程的管理控制块，JVM 的静态数据、全局数据等等。也包括 JNI 程序中 native code 分配到的资源。在 JVM 运行中，多数进程资源从 native memory 中动态分配。当越来越多的资源在 native memory 中分配，占据越来越多 native memory 空间并且达到 native memory 上限时，JVM 会抛出异常，使 JVM 进程异常退出。而此时 Java Heap 往往还没有达到上限。多种原因可能导致 JVM 的 native memory 内存泄漏。例如 JVM 在运行中过多的线程被创建，并且在同时运行。JVM 为线程分配的资源就可能耗尽 native memory 的容量。JNI 编程错误也可能导致 native memory 的内存泄漏。对这个话题的讨论是本文的重点。JNI 编程中明显的内存泄漏JNI 编程实现了 native code 和 Java 程序的交互，因此 JNI 代码编程既遵循 native code 编程语言的编程规则，同时也遵守 JNI 编程的文档规范。在内存管理方面，native code 编程语言本身的内存管理机制依然要遵循，同时也要考虑 JNI 编程的内存管理。本章简单概括 JNI 编程中显而易见的内存泄漏。从 native code 编程语言自身的内存管理，和 JNI 规范附加的内存管理两方面进行阐述。Native Code 本身的内存泄漏JNI 编程首先是一门具体的编程语言，或者 C 语言，或者 C++，或者汇编，或者其它 native 的编程语言。每门编程语言环境都实现了自身的内存管理机制。因此，JNI 程序开发者要遵循 native 语言本身的内存管理机制，避免造成内存泄漏。以 C 语言为例，当用 malloc() 在进程堆中动态分配内存时，JNI 程序在使用完后，应当调用 free() 将内存释放。总之，所有在 native 语言编程中应当注意的内存泄漏规则，在 JNI 编程中依然适应。Native 语言本身引入的内存泄漏会造成 native memory 的内存，严重情况下会造成 native memory 的 out of memory。Global Reference 引入的内存泄漏JNI 编程还要同时遵循 JNI 的规范标准，JVM 附加了 JNI 编程特有的内存管理机制。JNI 中的 Local Reference 只在 native method 执行时存在，当 native method 执行完后自动失效。这种自动失效，使得对 Local Reference 的使用相对简单，native method 执行完后，它们所引用的 Java 对象的 reference count 会相应减 1。不会造成 Java Heap 中 Java 对象的内存泄漏。而 Global Reference 对 Java 对象的引用一直有效，因此它们引用的 Java 对象会一直存在 Java Heap 中。程序员在使用 Global Reference 时，需要仔细维护对 Global Reference 的使用。如果一定要使用 Global Reference，务必确保在不用的时候删除。就像在 C 语言中，调用 malloc() 动态分配一块内存之后，调用 free() 释放一样。否则，Global Reference 引用的 Java 对象将永远停留在 Java Heap 中，造成 Java Heap 的内存泄漏。JNI 编程中潜在的内存泄漏——对 LocalReference 的深入理解Local Reference 在 native method 执行完成后，会自动被释放，似乎不会造成任何的内存泄漏。但这是错误的。对 Local Reference 的理解不够，会造成潜在的内存泄漏。本章重点阐述 Local Reference 使用不当可能引发的内存泄漏。引入两个错误实例，也是 JNI 程序员容易忽视的错误；在此基础上介绍 Local Reference 表，对比 native method 中的局部变量和 JNI Local Reference 的不同，使读者深入理解 JNI Local Reference 的实质；最后为 JNI 程序员提出应该如何正确合理使用 JNI Local Reference，以避免内存泄漏。错误实例 1在某些情况下，我们可能需要在 native method 里面创建大量的 JNI Local Reference。这样可能导致 native memory 的内存泄漏，如果在 native method 返回之前 native memory 已经被用光，就会导致 native memory 的 out of memory。在代码清单 1 里，我们循环执行 count 次，JNI function NewStringUTF() 在每次循环中从 Java Heap 中创建一个 String 对象，str 是 Java Heap 传给 JNI native method 的 Local Reference，每次循环中新创建的 String 对象覆盖上次循环中 str 的内容。str 似乎一直在引用到一个 String 对象。整个运行过程中，我们看似只创建一个 Local Reference。执行代码清单 1 的程序，第一部分为 Java 代码，nativeMethod(int i) 中，输入参数设定循环的次数。第二部分为 JNI 代码，用 C 语言实现了 nativeMethod(int i)。清单 1. Local Reference 引发内存泄漏 Java 代码部分
class TestLocalReference {
private native void nativeMethod(int i);
public static void main(String args[]) {
TestLocalReference c = new TestLocalReference();
//call the jni native method
c.nativeMethod(1000000);
//load the jni library
System.loadLibrary("StaticMethodCall");
JNI 代码，nativeMethod(int i) 的 C 语言实现
#include&stdio.h&
#include&jni.h&
#include"TestLocalReference.h"
JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod
(JNIEnv * env, jobject obj, jint count)
jint i = 0;
for(; i& i++)
str = (*env)-&NewStringUTF(env, "0");
JVMCI161: FATAL ERROR in native method: Out of memory when expanding
local ref table beyond capacity
at TestLocalReference.nativeMethod(Native Method)
at TestLocalReference.main(TestLocalReference.java:9)运行结果证明，JVM 运行异常终止，原因是创建了过多的 Local Reference，从而导致 out of memory。实际上，nativeMethod 在运行中创建了越来越多的 JNI Local Reference，而不是看似的始终只有一个。过多的 Local Reference，导致了 JNI 内部的 JNI Local Reference 表内存溢出。错误实例 2实例 2 是实例 1 的变种，Java 代码未作修改，但是 nativeMethod(int i) 的 C 语言实现稍作修改。在 JNI 的 native method 中实现的 utility 函数中创建 Java 的 String 对象。utility 函数只建立一个 String 对象，返回给调用函数，但是 utility 函数对调用者的使用情况是未知的，每个函数都可能调用它，并且同一函数可能调用它多次。在实例 2 中，nativeMethod 在循环中调用 count 次，utility 函数在创建一个 String 对象后即返回，并且会有一个退栈过程，似乎所创建的 Local Reference 会在退栈时被删除掉，所以应该不会有很多 Local Reference 被创建。实际运行结果并非如此。清单 2. Local Reference 引发内存泄漏 Java 代码部分参考实例 1，未做任何修改。
JNI 代码，nativeMethod(int i) 的 C 语言实现
#include&stdio.h&
#include&jni.h&
#include"TestLocalReference.h"
jstring CreateStringUTF(JNIEnv * env)
return (*env)-&NewStringUTF(env, "0");
JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod
(JNIEnv * env, jobject obj, jint count)
jint i = 0;
for(; i& i++)
str = CreateStringUTF(env);
JVMCI161: FATAL ERROR in native method: Out of memory when expanding local ref
table beyond
at TestLocalReference.nativeMethod(Native Method)
at TestLocalReference.main(TestLocalReference.java:9)运行结果证明，实例 2 的结果与实例 1 的完全相同。过多的 Local Reference 被创建，仍然导致了 JNI 内部的 JNI Local Reference 表内存溢出。实际上，在 utility 函数 CreateStringUTF(JNIEnv * env)执行完成后的退栈过程中，创建的 Local Reference 并没有像 native code 中的局部变量那样被删除，而是继续在 Local Reference 表中存在，并且有效。Local Reference 和局部变量有着本质的区别。Local Reference 深层解析Java JNI 的文档规范只描述了 JNI Local Reference 是什么（存在的目的），以及应该怎么使用 Local Reference（开放的接口规范）。但是对 Java 虚拟机中 JNI Local Reference 的实现并没有约束，不同的 Java 虚拟机有不同的实现机制。这样的好处是，不依赖于具体的 JVM 实现，有好的可移植性；并且开发简单，规定了“应该怎么做、怎么用”。但是弊端是初级开发者往往看不到本质，“不知道为什么这样做”。对 Local Reference 没有深层的理解，就会在编程过程中无意识的犯错。Local Reference 和 Local Reference 表理解 Local Reference 表的存在是理解 JNI Local Reference 的关键。JNI Local Reference 的生命期是在 native method 的执行期（从 Java 程序切换到 native code 环境时开始创建，或者在 native method 执行时调用 JNI function 创建），在 native method 执行完毕切换回 Java 程序时，所有 JNI Local Reference 被删除，生命期结束（调用 JNI function 可以提前结束其生命期）。实际上，每当线程从 Java 环境切换到 native code 上下文时（J2N），JVM 会分配一块内存，创建一个 Local Reference 表，这个表用来存放本次 native method 执行中创建的所有的 Local Reference。每当在 native code 中引用到一个 Java 对象时，JVM 就会在这个表中创建一个 Local Reference。比如，实例 1 中我们调用 NewStringUTF() 在 Java Heap 中创建一个 String 对象后，在 Local Reference 表中就会相应新增一个 Local Reference。图 1. Local Reference 表、Local Reference 和 Java 对象的关系图 1 中：⑴运行 native method 的线程的堆栈记录着 Local Reference 表的内存位置（指针 p）。⑵ Local Reference 表中存放 JNI Local Reference，实现 Local Reference 到 Java 对象的映射。⑶ native method 代码间接访问 Java 对象（java obj1，java obj2）。通过指针 p 定位相应的 Local Reference 的位置，然后通过相应的 Local Reference 映射到 Java 对象。⑷当 native method 引用一个 Java 对象时，会在 Local Reference 表中创建一个新 Local Reference。在 Local Reference 结构中写入内容，实现 Local Reference 到 Java 对象的映射。⑸ native method 调用 DeleteLocalRef() 释放某个 JNI Local Reference 时，首先通过指针 p 定位相应的 Local Reference 在 Local Ref 表中的位置，然后从 Local Ref 表中删除该 Local Reference，也就取消了对相应 Java 对象的引用（Ref count 减 1）。⑹当越来越多的 Local Reference 被创建，这些 Local Reference 会在 Local Ref 表中占据越来越多内存。当 Local Reference 太多以至于 Local Ref 表的空间被用光，JVM 会抛出异常，从而导致 JVM 的崩溃。Local Ref 不是 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。代码清单 1 中 str = (*env)-&NewStringUTF(env, "0");str 是 jstring 类型的局部变量。Local Ref 表中会新创建一个 Local Reference，引用到 NewStringUTF(env, "0") 在 Java Heap 中新建的 String 对象。如图 2 所示：图 2. str 间接引用 string 对象图 2 中，str 是局部变量，在 native method 堆栈中。Local Ref3 是新创建的 Local Reference，在 Local Ref 表中，引用新创建的 String 对象。JNI 通过 str 和指针 p 间接定位 Local Ref3，但 p 和 Local Ref3 对 JNI 程序员不可见。Local Reference 导致内存泄漏在以上论述基础上，我们通过分析错误实例 1 和实例 2，来分析 Local Reference 可能导致的内存泄漏，加深对 Local Reference 的深层理解。分析错误实例 1：局部变量 str 在每次循环中都被重新赋值，间接指向最新创建的 Local Reference，前面创建的 Local Reference 一直保留在 Local Ref 表中。在实例 1 执行完第 i 次循环后，内存布局如图 3：图 3. 执行 i 次循环后的内存布局继续执行完第 i+1 次循环后，内存布局发生变化，如图 4：图 4. 执行 i+1 次循环后的内存布局图 4 中，局部变量 str 被赋新值，间接指向了 Local Ref i+1。在 native method 运行过程中，我们已经无法释放 Local Ref i 占用的内存，以及 Local Ref i 所引用的第 i 个 string 对象所占据的 Java Heap 内存。所以，native memory 中 Local Ref i 被泄漏，Java Heap 中创建的第 i 个 string 对象被泄漏了。也就是说在循环中，前面创建的所有 i 个 Local Reference 都泄漏了 native memory 的内存，创建的所有 i 个 string 对象都泄漏了 Java Heap 的内存。直到 native memory 执行完毕，返回到 Java 程序时（N2J），这些泄漏的内存才会被释放，但是 Local Reference 表所分配到的内存往往很小，在很多情况下 N2J 之前可能已经引发严重内存泄漏，导致 Local Reference 表的内存耗尽，使 JVM 崩溃，例如错误实例 1。分析错误实例 2：实例 2 与实例 1 相似，虽然每次循环中调用工具函数 CreateStringUTF(env) 来创建对象，但是在 CreateStringUTF(env) 返回退栈过程中，只是局部变量被删除，而每次调用创建的 Local Reference 仍然存在 Local Ref 表中，并且有效引用到每个新创建的 string 对象。str 局部变量在每次循环中被赋新值。这样的内存泄漏是潜在的，但是这样的错误在 JNI 程序员编程过程中却经常出现。通常情况，在触发 out of memory 之前，native method 已经执行完毕，切换回 Java 环境，所有 Local Reference 被删除，问题也就没有显露出来。但是某些情况下就会引发 out of memory，导致实例 1 和实例 2 中的 JVM 崩溃。控制 Local Reference 生命期因此，在 JNI 编程时，正确控制 JNI Local Reference 的生命期。如果需要创建过多的 Local Reference，那么在对被引用的 Java 对象操作结束后，需要调用 JNI function（如 DeleteLocalRef()），及时将 JNI Local Reference 从 Local Ref 表中删除，以避免潜在的内存泄漏。总结本文阐述了 JNI 编程可能引发的内存泄漏，JNI 编程既可能引发 Java Heap 的内存泄漏，也可能引发 native memory 的内存泄漏，严重的情况可能使 JVM 运行异常终止。JNI 软件开发人员在编程中，应当考虑以下几点，避免内存泄漏：
native code 本身的内存管理机制依然要遵循。
使用 Global reference 时，当 native code 不再需要访问 Global reference 时，应当调用 JNI 函数 DeleteGlobalRef() 删除 Global reference 和它引用的 Java 对象。Global reference 管理不当会导致 Java Heap 的内存泄漏。
透彻理解 Local reference，区分 Local reference 和 native code 的局部变量，避免混淆两者所引起的 native memory 的内存泄漏。
使用 Local reference 时，如果 Local reference 引用了大的 Java 对象，当不再需要访问 Local reference 时，应当调用 JNI 函数 DeleteLocalRef() 删除 Local reference，从而也断开对 Java 对象的引用。这样可以避免 Java Heap 的 out of memory。
使用 Local reference 时，如果在 native method 执行期间会创建大量的 Local reference，当不再需要访问 Local reference 时，应当调用 JNI 函数 DeleteLocalRef() 删除 Local reference。Local reference 表空间有限，这样可以避免 Local reference 表的内存溢出，避免 native memory 的 out of memory。
严格遵循 Java JNI 规范书中的使用规则。
查看 developerWorks 文章“”，了解 JNI 开发教程。
查看文章“”，详细了解 JNI 编程向导和规范。
查看文章“”，了解 JVM 进程的内存空间布局。
：数百篇关于 Java 编程各个方面的文章。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=Java technologyArticleID=650448ArticleTitle=在 JNI 编程中避免内存泄漏publish-date=============================================================博文原创，转载请声明出处(原id蓝岩)============================================================JNI jstring 和char* 的相互转换/+++++++++++++++++++++++++
//jstring to char*
//NOTICE: you need free return value,like free(ch)
char* jstringToChar(JNIEnv* env, jstring jstr)
char* rtn = NULL;
jclass clsstring = env-&FindClass("java/lang/String");
jstring strencode = env-&NewStringUTF("utf-8");
jmethodID mid = env-&GetMethodID(clsstring, "getBytes", "(Ljava/lang/S)[B");
jbyteArray barr= (jbyteArray)env-&CallObjectMethod(jstr, mid, strencode);
env-&DeleteLocalRef( strencode);
jsize alen = env-&GetArrayLength(barr);
jbyte* ba = env-&GetByteArrayElements(barr, JNI_FALSE);
if (alen & 0)
rtn = (char*)malloc(alen + 1);
memcpy(rtn, ba, alen);
rtn[alen] = 0;
env-&ReleaseByteArrayElements(barr, ba, 0);
//char* to jstring
//NOTICE: you need free return value,like
(*env)-&DeleteLocalRef( env, myObj );
jstring charToJstring(JNIEnv* env, const char* pat)
jclass strClass = env-&FindClass("Ljava/lang/S");
jmethodID ctorID = env-&GetMethodID(strClass, "&init&", "([BLjava/lang/S)V");
jbyteArray bytes = env-&NewByteArray(strlen(pat));
env-&SetByteArrayRegion(bytes, 0, strlen(pat), (jbyte*)pat);
jstring encoding = env-&NewStringUTF("utf-8");
jstring result= (jstring) env-&NewObject(strClass, ctorID, bytes, encoding);
(env)-&DeleteLocalRef(bytes);
env-&DeleteLocalRef( encoding);
//+++++++++++++++++++++++++2007年6月 总版技术专家分月排行榜第三
2007年6月 VC/MFC大版内专家分月排行榜第一
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
2013年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第七
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。android libpomelo2 接收emoji表情时，总是报错:input is not valid Modified UTF-8:illegal start byte 0xf0 - Pomelo Club
android libpomelo2 接收emoji表情时，总是报错:input is not valid Modified UTF-8:illegal start byte 0xf0
除了emoji以外，其它功能都是好的.请问有碰到过类似问题，并解决的吗？谢谢
@,请问有解决方案吗？
@ android 具体怎么处理不清楚，我们只保证libpomelo2能正常处理json，满足json规范
@ 已经解决了，把.c文件里加上一个函数jstring chartoJstring(JNIEnv* env, const char* pat){
jclass strClass = (env)-&FindClass(env, &java/lang/String&);
jmethodID ctorID = (env)-&GetMethodID(env, strClass, &&init&&, &([BLjava/lang/S)V&);
jbyteArray bytes = (env)-&NewByteArray(env, strlen(pat));
(env)-&SetByteArrayRegion(env,bytes, 0, strlen(pat), (jbyte)pat);
jstring encoding = (env)-&NewStringUTF(env, &utf-8&);
return (jstring)(*env)-&NewObject(env, strClass, ctorID, bytes, encoding);}
并把NewStringUTF方法调用的地方改成 chartoJstring,当然如果消息中不存在emoji表情则不需要替换。
将NewStringUTF改成NewString可否？还没有试验
如果没有副作用的话，而且还是增强功能的话，可以考虑提一个PR，方便后来者，谢谢！
@ hi,我想请问下，如何编译64位的libjpomelo.so,我在64位机器下，使用64位的NDK，编译出来的始终是32位的，请问下怎么修改编译参数？谢谢
哥们，能否分享一下你的libpomelo2在Android平台的so文件，我编译后使用的时候报received null array，一直没有解决，小弟跪谢！解析Java的JNI编程中的对象引用与内存泄漏问题
作者：pony
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了Java的JNI编程中的对象引用与内存泄漏问题,重点讲述了局部和全局引用时一些值得注意的地方,需要的朋友可以参考下
JNI，Java Native Interface，是 native code 的编程接口。JNI 使 Java 代码程序可以与 native code 交互——在 Java 程序中调用 native code；在 native code 中嵌入 Java 虚拟机调用 Java 的代码。
JNI 编程在软件开发中运用广泛，其优势可以归结为以下几点：
利用 native code 的平台相关性，在平台相关的编程中彰显优势。
对 native code 的代码重用。
native code 底层操作，更加高效。
然而任何事物都具有两面性，JNI 编程也同样如此。程序员在使用 JNI 时应当认识到 JNI 编程中如下的几点弊端，扬长避短，才可以写出更加完善、高性能的代码：
从 Java 环境到 native code 的上下文切换耗时、低效。
JNI 编程，如果操作不当，可能引起 Java 虚拟机的崩溃。
JNI 编程，如果操作不当，可能引起内存泄漏。
JAVA 中的内存泄漏
JAVA 编程中的内存泄漏，从泄漏的内存位置角度可以分为两种：JVM 中 Java Heap 的内存泄漏；JVM 内存中 native memory 的内存泄漏。
局部和全局引用
JNI将实例、数组类型暴露为不透明的引用。native代码从不会直接检查一个不透明的引用指针的上下文，而是通过使用JNI函数来访问由不透明的引用所指向的数据结构。因为只处理不透明的引用，这样就不需要担心不同的java VM实现而导致的不同的内部对象的布局。然而，还是有必要了解一下JNI中不同种类的引用：
1）JNI 支持3中不透明的引用：局部引用、全局引用和弱全局引用。
2）局部和全局引用，有着各自不同的生命周期。局部引用能够被自动释放，而全局引用和若全局引用在被程序员释放之前，是一直有效的。
3）一个局部或者全局引用，使所提及的对象不能被垃圾回收。而弱全局引用，则允许提及的对象进行垃圾回收。
4）不是所有的引用都可以在所有上下文中使用的。例如：在一个创建返回引用native方法之后，使用一个局部引用，这是非法的。
那么到底什么是局部引用，什么事全局引用，它们有什么不同？
多数JNI函数都创建局部引用。例如JNI函数NewObject创建一个实例，并且返回一个指向该实例的局部引用。
局部引用只在创建它的native方法的动态上下文中有效，并且只在native方法的一次调用中有效。所有局部引用只在一个native方法的执行期间有效，在该方法返回时，它就被回收。
在native方法中使用一个静态变量来保存一个局部引用，以便在随后的调用中使用该局部引用，这种方式是行不通的。例如以下例子，误用了局部引用：
/* This code is illegal */&
MyNewString(JNIEnv *env, jchar *chars, jint len)
static jclass stringClass = NULL;
jcharArray elemA
if (stringClass == NULL) {
stringClass = (*env)-&FindClass(env, "java/lang/String");
if (stringClass == NULL) {
return NULL; /* exception thrown */
/* It is wrong to use the cached stringClass here,
because it may be invalid. */
cid = (*env)-&GetMethodID(env, stringClass, "&init&", "([C)V");
elemArr = (*env)-&NewCharArray(env, len);
result = (*env)-&NewObject(env, stringClass, cid, elemArr);
(*env)-&DeleteLocalRef(env, elemArr);
这种保存局部引用的方式是不正确的，因为FindClass()返回的是对java.lang.String的局部引用。这是因为，在native代码从MyNewString返回退出时，VM 会释放所有局部引用，包括存储在stringClass变量中的指向类对象的引用。这样当再次后继调用MyNewString时，可能会访问非法地址，导致内存被破坏，或者系统崩溃。
局部引用失效，有两种方式：‘
1）系统会自动释放局部变量。
2）程序员可以显示地管理局部引用的生命周期，例如调用DeleteLocalRef。
一个局部引用可能在被摧毁之前，被传给多个native方法。例如，MyNewString中，返回一个由NewObject创建的字符串引用，它将由NewObject的调用者来决定是否释放该引用。而在以下代码中：
JNIEXPORT jstring JNICALL Java_C_f(JNIEnv *env, jobject this) {
char *c_str = ...&pre name="code" class="cpp"&
... &pre name="code" class="cpp"&return MyNewString(c_str);&pre name="code" class="cpp"&}
在VM接收到来自Java_C_f的局部引用以后，将基础字符串对象传递给ava_C_f的调用者，然后摧毁原本由MyNewString中调用的JNI函数NewObject所创建的局部引用。
局部对象只属于创建它们的线程，只在该线程中有效。一个线程想要调用另一个线程创建的局部引用是不被允许的。将一个局部引用保存到全局变量中，然后在其它线程中使用它，这是一种错误的编程。
在一个native方法被多次调用之间，可以使用一个全局引用跨越它们。一个全局引用可以跨越多个线程，并且在被程序员释放之前，一致有效。和局部引用一样，全局引用保证了所引用的对象不会被垃圾回收。
和局部引用不一样（局部变量可以由多数JNI函数创建），全局引用只能由一个JNI函数创建（NewGlobalRef）。下面是一个使用全局引用版本的MyNewString：
/* This code is OK */&
MyNewString(JNIEnv *env, jchar *chars, jint len)
static jclass stringClass = NULL;
if (stringClass == NULL) {
jclass localRefCls =
(*env)-&FindClass(env, "java/lang/String");
if (localRefCls == NULL) {
return NULL; /* exception thrown */
/* Create a global reference */
stringClass = (*env)-&NewGlobalRef(env, localRefCls);
/* The local reference is no longer useful */
(*env)-&DeleteLocalRef(env, localRefCls);
/* Is the global reference created successfully? */
if (stringClass == NULL) {
return NULL; /* out of memory exception thrown */
弱全局引用
弱全局引用是在java 2 SDK1.2才出现的。它由NewGolableWeakRef函数创建，并且被DeleteGloablWeakRef函数摧毁。和全局引用一样，它可以跨native方法调用，也可以跨越不同线程。但是和全局引用不同的是，它不阻止对基础对象的垃圾回收。下面是弱全局引用版的MyNewString：
JNIEXPORT void JNICALL&
Java_mypkg_MyCls_f(JNIEnv *env, jobject self)
static jclass myCls2 = NULL;
if (myCls2 == NULL) {
jclass myCls2Local =
(*env)-&FindClass(env, "mypkg/MyCls2");
if (myCls2Local == NULL) {
/* can't find class */
myCls2 = NewWeakGlobalRef(env, myCls2Local);
if (myCls2 == NULL) {
/* out of memory */
... /* use myCls2 */
弱全局引用在一个被native代码缓存着的引用不想阻止基础对象被垃圾回收时，非常有用。如以上例子，mypkg.MyCls.f需要缓存mypkg.MyCls2的引用。而通过将mypkg.MyCls2缓存到弱引用中，能够实现MyCls2类依旧可以被卸载。
上面代码中，我们假设了MyCls类和MyCls2类的生命周期是相同的（例如，在同一个类中被加载、卸载）。所以没有考虑MyCls2被卸载了，然后在类MyCls和native方法的实现Java_mypkg_MyCls_f还要被继续使用时，再被重新加载起来的情况。针对于这个MyCls2类可能被卸载再加载的情况，在使用时，需要检查该弱全局引用是否还有效。如何检查，这将在下面提到。
可以用JNI函数IsSameObject来检查给定的两个局部引用、全局引用或者弱全局引用，是否指向同一个对象。
(*env)-&IsSameObject(env, obj1, obj2)&
返回值为：
JNI_TRUE，表示两个对象一致，是同一个对象。
JNI_FALSE，表示两个对象不一致，不是同一个对象。
在java VM中NULL是null的引用。
如果一个对象obj是局部引用或者全局引用，则可以这样来检查它是否指向null对象：
(*env)-&IsSameObject(env, obj, NULL)
NULL == obj
而对于弱全局引用，以上规则需要改变一下：
我们可以用这个函数来判断一个非0弱全局引用wobj所指向的对象是否仍旧存活着（依旧有效）。
(*env)-&IsSameObject(env, wobj, NULL)
JNI_TRUE，表示对象已经被回收了。
JNI_FALSE，表示wobj指向的对象，依旧有效。
除了引用的对象要占用内存，每个JNI引用本身也会消耗一定内存。作为一个JNI程序员，应该对在一段给定的时间里，程序会用到的引用的个数，做到心中有数。特别是，尽管程序所创建的局部引用最终会被VM会被自动地释放，仍旧需要知道在程序在执行期间的任何时刻，创建的局部引用的上限个数。创建过多的引用，即便他们是瞬间、短暂的，也会导致内存耗尽。
释放局部引用
多数情况下，在执行一个native方法时，你不需要担心局部引用的释放，java VM会在native方法返回调用者的时候释放。然而有时候需要JNI程序员显示的释放局部引用，来避免过高的内存使用。那么什么时候需要显示的释放呢，且看一下情景：
1）在单个native方法调用中，创建了大量的局部引用。这可能会导致JNI局部引用表溢出。此时有必要及时地删除那些不再被使用的局部引用。例如以下代码，在该循环中，每次都有可能创建一个巨大的字符串数组。在每个迭代之后，native代码需要显示地释放指向字符串元素的局部引用：
for (i = 0; i & i++) {
jstring jstr = (*env)-&GetObjectArrayElement(env, arr, i);
... /* process jstr */
(*env)-&DeleteLocalRef(env, jstr);
2）你可能要创建一个工具函数，它会被未知的上下文调用。例如之前提到到MyNewString这个例子，它在每次返回调用者欠，都及时地将局部引用释放。
3）native方法，可能不会返回（例如，一个可能进入无限事件分发的循环中的方法）。此时在循环中释放局部引用，是至关重要的，这样才能不会无限期地累积，进而导致内存泄露。
4）native方法可能访问一个巨大的对象，因此，创建了一个指向该对象的局部引用。native方法在返回调用者之前，除访问对象之外，还执行了额外的计算。指向这个大对象的局部引用，将会包含该对象，以防被垃圾回收。这个现象会持续到native方法返回到调用者时，即便这个对象不会再被使用，也依旧会受保护。在以下例子中，由于在lengthyComputation()前，显示地调用了DeleteLocalRef，所以垃圾回收器有机会可以释放lref所指向的对象。
/* A native method implementation */
JNIEXPORT void JNICALL
Java_pkg_Cls_func(JNIEnv *env, jobject this)
lref = ...
/* a large Java object */
/* last use of lref */
(*env)-&DeleteLocalRef(env, lref);
lengthyComputation();
/* may take some time */
/* all local refs are freed */
这个情形的实质，就是允许程序在native方法执行期间，java的垃圾回收机制有机会回收native代码不在访问的对象。
管理局部引用
不知道java 7怎么样了，应该更强大吧，有时间，去看看，这里且按照java2的特性来吧。
SDK1.2中提供了一组额外的函数来管理局部引用的生命周期。他们是EnsureLocalCapacity、NewLocalRef、PushLocalFram以及PopLocalFram。
JNI的规范要求VM可以自动确保每个native方法可以创建至少16个局部引用。经验显示，如果native方法中未包含和java VM的对象进行复杂的互相操作，这个容量对大多数native方法而言，已经足够了。如果，出现这还不够的情况，需要创建更多的局部引用，那么native方法可以调用EnsureLocalCapacity来保证这些局部引用有足够的空间。
/* The number of local references to be created is equal to
the length of the array. */
if ((*env)-&EnsureLocalCapacity(env, len)) & 0) {
... /* out of memory */
} for (i = 0; i & i++) {
jstring jstr = (*env)-&GetObjectArrayElement(env, arr, i);
... /* process jstr */
/* DeleteLocalRef is no longer necessary */ }
这样做，所消耗的内存，自然就有可能比之前的版本来的多。
另外，PushLocalFram\PopLocalFram函数允许程序员创建嵌套作用域的局部引用。如下代码：
#define N_REFS ... /* the maximum number of local references
used in each iteration */
for (i = 0; i & i++) {
if ((*env)-&PushLocalFrame(env, N_REFS) & 0) {
... /* out of memory */
jstr = (*env)-&GetObjectArrayElement(env, arr, i);
... /* process jstr */
(*env)-&PopLocalFrame(env, NULL);
PushLocalFram为指定数目的局部引用，创建一个新的作用域，PopLocalFram摧毁最上层的作用域，并且释放该域中的所有局部引用。
使用这两个函数的好处是它们可以管理局部引用的生命周期，而不需关系在执行过程中可能被创建的每个单独局部引用。例子中，如果处理jstr的过程，创建了额外的局部引用，它们也会在PopLocalFram之后被立即释放。
NewLocalRef函数，在你写一个工具函数时，非常有用。这个会在下面章节——管理引用的规则，具体分析。
native代码可能会创建超出16个局部引用的范围，也可能将他们保存在PushLocalFram或者EnsureLocalCapacity调用，VM会为局部引用分配所需要的内存。然而，这些内存是否足够，是没有保证的。如果内存分配失败，虚拟机将会退出。
&释放全局引用
在native代码不再需要访问一个全局引用的时候，应该调用DeleteGlobalRef来释放它。如果调用这个函数失败，Java VM将不会回收对应的对象。
在native代码不在需要访问一个弱全局引用的时候，应该调用DeleteWeakGlobalRef来释放它。如果调用这个函数失败了，java VM 仍旧将会回收对应的底层对象，但是，不会回收这个弱引用本身所消耗掉的内存。
&管理引用的规则
管理引用的目的是为了清除不需要的内存占用和对象保留。
总体来说，只有两种类型的native代码：直接实现native方法的函数，在二进制上下文中被使用的工具函数。
在写native方法的实现的时候，需要当心在循环中过度创建局部引用，以及在native方法中被创建的，却不返回给调用者的局部引用。在native方法方法返回后还留有16个局部引用在使用中，将它们交给java VM来释放，这是可以接受的。但是native方法的调用，不应该引起全局引用和弱全局引用的累积。应为这些引用不会在native方法返后被自动地释放。
在写工具函数的时候，必须要注意不能泄露任何局部引用或者超出该函数之外的执行。因为一个工具函数，可能在意料之外的上下文中，被不停的重复调用。任何不需要的引用创建都有可能导致内存泄露。
1）当一个返回一个基础类型的工具函数被调用，它必须应该没有局部引用、若全局引用的累积。
2）当一个返回一个引用类型的工具函数被调用，它必须应该没有局部、全局或若全局引用的累积，除了要被作为返回值的引用。
一个工具函数以捕获为目的创建一些全局或者弱全局引用，这是可接受的，因为只有在最开始的时候，才会创建这些引用。
如果一个工具函数返回一个引用，你应该使返回的引用的类型(例如局部引用、全局引用）作为函数规范的一部分。它应该始终如一，而不是有时候返回一个局部引用，有时候却返回一个全局引用。调用者需要知道工具函数返回的引用的类型，以便正确地管理自己的JNI引用。以下代码重复地调用一个工具工具函数（GetInfoString）。我们需要知道GetInfoString返回的引用的类型，以便释放该引用：
while (JNI_TRUE) {
jstring infoString = GetInfoString(info);
... /* process infoString */
??? /* we need to call DeleteLocalRef, DeleteGlobalRef,
or DeleteWeakGlobalRef depending on the type of
reference returned by GetInfoString. */
在java2 SDK1.2中，NewLocalRef函数可以用来保证一个工具函数一直返回一个局部引用。为了说明这个问题，我们对MyNewString做一些改动,它缓存了一个被频繁请求的字符串（“CommonString”）到全局引用：
MyNewString(JNIEnv *env, jchar *chars, jint len)
/* wstrncmp compares two Unicode strings */
if (wstrncmp("CommonString", chars, len) == 0) {
/* refers to the global ref caching "CommonString" */
static jstring cachedString = NULL;
if (cachedString == NULL) {
/* create cachedString for the first time */
jstring cachedStringLocal = ... ;
/* cache the result in a global reference */
cachedString =
(*env)-&NewGlobalRef(env, cachedStringLocal);
return (*env)-&NewLocalRef(env, cachedString);
... /* create the string as a local reference and store in
result as a local reference */
正常的流程返回的时候局部引用。就像之前解释的那样，我们必须将缓存字符保存到一个全局引用中，这样就可以在多个线程中调用native方法时，都能访问它。
return (*env)-&NewLocalRef(env, cachedString);
这条语句，创建了一个局部引用，它指向了缓存在全局引用的指向的统一对象。作为和调用者的约定的一部分，MyNewString总是返回一个局部引用。
PushLocalFram、PopLocalFram函数用来管理局部引用的生命周期特别得方便。只需要在native函数的入口调用PushLocalFram，在函数退出时调用PopLocalFram，局部变量就会被释放。
jobject f(JNIEnv *env, ...)
if ((*env)-&PushLocalFrame(env, 10) & 0) {
/* frame not pushed, no PopLocalFrame needed */
return NULL;
result = ...;
if (...) {
/* remember to pop local frame before return */
result = (*env)-&PopLocalFrame(env, result);
result = (*env)-&PopLocalFrame(env, result);
/* normal return */
PopLocalFram函数调用失败时，可能会导致未定义的行为，例如VM崩溃。
内存泄漏问题
Java Heap 的内存泄漏
Java 对象存储在 JVM 进程空间中的 Java Heap 中，Java Heap 可以在 JVM 运行过程中动态变化。如果 Java 对象越来越多，占据 Java Heap 的空间也越来越大，JVM 会在运行时扩充 Java Heap 的容量。如果 Java Heap 容量扩充到上限，并且在 GC 后仍然没有足够空间分配新的 Java 对象，便会抛出 out of memory 异常，导致 JVM 进程崩溃。
Java Heap 中 out of memory 异常的出现有两种原因——①程序过于庞大，致使过多 Java 对象的同时存在；②程序编写的错误导致 Java Heap 内存泄漏。
多种原因可能导致 Java Heap 内存泄漏。JNI 编程错误也可能导致 Java Heap 的内存泄漏。
JVM 中 native memory 的内存泄漏
从操作系统角度看，JVM 在运行时和其它进程没有本质区别。在系统级别上，它们具有同样的调度机制，同样的内存分配方式，同样的内存格局。
JVM 进程空间中，Java Heap 以外的内存空间称为 JVM 的 native memory。进程的很多资源都是存储在 JVM 的 native memory 中，例如载入的代码映像，线程的堆栈，线程的管理控制块，JVM 的静态数据、全局数据等等。也包括 JNI 程序中 native code 分配到的资源。
在 JVM 运行中，多数进程资源从 native memory 中动态分配。当越来越多的资源在 native memory 中分配，占据越来越多 native memory 空间并且达到 native memory 上限时，JVM 会抛出异常，使 JVM 进程异常退出。而此时 Java Heap 往往还没有达到上限。
多种原因可能导致 JVM 的 native memory 内存泄漏。例如 JVM 在运行中过多的线程被创建，并且在同时运行。JVM 为线程分配的资源就可能耗尽 native memory 的容量。
JNI 编程错误也可能导致 native memory 的内存泄漏。对这个话题的讨论是本文的重点。
JNI 编程实现了 native code 和 Java 程序的交互，因此 JNI 代码编程既遵循 native code 编程语言的编程规则，同时也遵守 JNI 编程的文档规范。在内存管理方面，native code 编程语言本身的内存管理机制依然要遵循，同时也要考虑 JNI 编程的内存管理。
本章简单概括 JNI 编程中显而易见的内存泄漏。从 native code 编程语言自身的内存管理，和 JNI 规范附加的内存管理两方面进行阐述。
Native Code 本身的内存泄漏
JNI 编程首先是一门具体的编程语言，或者 C 语言，或者 C++，或者汇编，或者其它 native 的编程语言。每门编程语言环境都实现了自身的内存管理机制。因此，JNI 程序开发者要遵循 native 语言本身的内存管理机制，避免造成内存泄漏。以 C 语言为例，当用 malloc() 在进程堆中动态分配内存时，JNI 程序在使用完后，应当调用 free() 将内存释放。总之，所有在 native 语言编程中应当注意的内存泄漏规则，在 JNI 编程中依然适应。
Native 语言本身引入的内存泄漏会造成 native memory 的内存，严重情况下会造成 native memory 的 out of memory。
Global Reference 引入的内存泄漏
JNI 编程还要同时遵循 JNI 的规范标准，JVM 附加了 JNI 编程特有的内存管理机制。
JNI 中的 Local Reference 只在 native method 执行时存在，当 native method 执行完后自动失效。这种自动失效，使得对 Local Reference 的使用相对简单，native method 执行完后，它们所引用的 Java 对象的 reference count 会相应减 1。不会造成 Java Heap 中 Java 对象的内存泄漏。
而 Global Reference 对 Java 对象的引用一直有效，因此它们引用的 Java 对象会一直存在 Java Heap 中。程序员在使用 Global Reference 时，需要仔细维护对 Global Reference 的使用。如果一定要使用 Global Reference，务必确保在不用的时候删除。就像在 C 语言中，调用 malloc() 动态分配一块内存之后，调用 free() 释放一样。否则，Global Reference 引用的 Java 对象将永远停留在 Java Heap 中，造成 Java Heap 的内存泄漏。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具