Android修行手册 - 万字梳理JNI开发正确技巧和错误缺陷

JNI 简介 

JNI，Java Native Interface，是 native code 的编程接口。JNI 使 Java 代码程序可以与 native code 交互——在 Java 程序中调用 native code；在 native code 中嵌入 Java 虚拟机调用 Java 的代码。

它支持将 Java 代码与使用其他编程语言编写的代码相集成。如果您希望利用已有的代码资源，那么可以使用 JNI 作为您工具包中的关键组件 —— 比如在面向服务架构（SOA）和基于云的系统中。但是，如果在使用时未注意某些事项，则 JNI 会迅速导致应用程序性能低下且不稳定。本文将确定 10 大 JNI 编程缺陷，提供避免这些缺陷的最佳实践，并介绍可用于实现这些实践的工具。

JNI 编程在软件开发中运用广泛，其优势可以归结为以下几点：

1. 利用 native code 的平台相关性，在平台相关的编程中彰显优势。
2. 对 native code 的代码重用。
3. native code 底层操作，更加高效。

然而任何事物都具有两面性，JNI 编程也同样如此。程序员在使用 JNI 时应当认识到 JNI 编程中如下的几点弊端，扬长避短，才可以写出更加完善、高性能的代码：

1. 从 Java 环境到 native code 的上下文切换耗时、低效。
2. JNI 编程，如果操作不当，可能引起 Java 虚拟机的崩溃。
3. JNI 编程，如果操作不当，可能引起内存泄漏。

有一个有趣的地方值得注意，一些较年轻的语言（如 PHP）在它们的本机代码支持方面仍然在努力克服这些问题。

• 与旧有代码集成，避免重新编写。
• 实现可用类库中所缺少的功能。举例来说，在 Java 语言中实现 ping 时，您可能需要 Internet Control Message Protocol (ICMP) 功能，但基本类库并未提供它。
• 最好与使用 C/C++ 编写的代码集成，以充分发掘性能或其他与环境相关的系统特性。
• 解决需要非 Java 代码的特殊情况。举例来说，核心类库的实现可能需要跨包调用或者需要绕过其他 Java 安全性检查。

本文介绍 JNI 用户最常遇到的编码和设计错误。其目标是帮助您认识到并避免它们，以便您可以编写安全、高效、性能出众的 JNI 代码。本文还将介绍一些用于在新代码或已有代码中查找这些问题的工具和技巧，并展示如何有效地应用它们。

性能缺陷

不缓存方法 ID、字段 ID 和类

要访问 Java 对象的字段并调用它们的方法，本机代码必须调用 FindClass()、GetFieldID()、GetMethodId() 和GetStaticMethodID()。对于 GetFieldID()、GetMethodID() 和GetStaticMethodID()，为特定类返回的 ID 不会在 JVM 进程的生存期内发生变化。但是，获取字段或方法的调用有时会需要在 JVM 中完成大量工作，因为字段和方法可能是从超类中继承而来的，这会让 JVM 向上遍历类层次结构来找到它们。由于 ID 对于特定类是相同的，因此您只需要查找一次，然后便可重复使用。同样，查找类对象的开销也很大，因此也应该缓存它们。

举例来说，代码 1 展示了调用静态方法所需的 JNI 代码：

代码 1. 使用 JNI 调用静态方法

int val=1;
jmethodID method;
jclass cls;

cls = (*env)->FindClass(env, "com/ibm/example/TestClass");
if ((*env)->ExceptionCheck(env)) {
   return ERR_FIND_CLASS_FAILED;
}
method = (*env)->GetStaticMethodID(env, cls, "setInfo", "(I)V");
if ((*env)->ExceptionCheck(env)) {
   return ERR_GET_STATIC_METHOD_FAILED;
}
(*env)->CallStaticVoidMethod(env, cls, method,val);
if ((*env)->ExceptionCheck(env)) {
   return ERR_CALL_STATIC_METHOD_FAILED;
}

当我们每次希望调用方法时查找类和方法 ID 都会产生六个本机调用，而不是第一次缓存类和方法 ID 时需要的两个调用。

缓存会对您应用程序的运行时造成显著的影响。考虑下面两个版本的方法，它们的作用是相同的。代码 2 使用了缓存的字段 ID：代码 2. 使用缓存的字段 ID

int sumValues2(JNIEnv* env, jobject obj, jobject allValues){

   jint avalue = (*env)->GetIntField(env, allValues, a);
   jint bvalue = (*env)->GetIntField(env, allValues, b);
   jint cvalue = (*env)->GetIntField(env, allValues, c);
   jint dvalue = (*env)->GetIntField(env, allValues, d);
   jint evalue = (*env)->GetIntField(env, allValues, e);
   jint fvalue = (*env)->GetIntField(env, allValues, f);

   return avalue + bvalue + cvalue + dvalue + evalue + fvalue;
}

性能技巧一

获取和更新仅本机代码需要的数组部分。在只要数组的一部分时通过适当的 API 调用来避免复制整个数组。

GetTypeArrayRegion() 和 SetTypeArrayRegion() 方法允许您获取和更新数组的一部分，而不是整个数组。通过使用这些方法访问较大的数组，您可以确保只复制本机代码将要实际使用的数组部分。

举例来说，考虑相同方法的两个版本，如代码 4 所示：

代码 4. 相同方法的两个版本

jlong getElement(JNIEnv* env, jobject obj, jlongArray arr_j, 
                 int element){
   jboolean isCopy;
   jlong result;
   jlong* buffer_j = (*env)->GetLongArrayElements(env, arr_j, &isCopy);
   result = buffer_j[element];
   (*env)->ReleaseLongArrayElements(env, arr_j, buffer_j, 0);
   return result;
}

jlong getElement2(JNIEnv* env, jobject obj, jlongArray arr_j, 
                  int element){
     jlong result;
     (*env)->GetLongArrayRegion(env, arr_j, element,1, &result);
     return result;
}

第一个版本可以生成两个完整的数组副本，而第二个版本则完全没有复制数组。当数组大小为 1,000 字节时，运行第一个方法 10,000,000 次用了 12,055 ms；而第二个版本仅用了 1,421 ms。第一个版本多花了 8.5 倍的时间！

性能技巧二 触发数组副本

查找并全局缓存常用的类、字段 ID 和方法 ID。

代码 3 没有使用缓存的字段 ID：代码 3. 未缓存字段 ID

int sumValues2(JNIEnv* env, jobject obj, jobject allValues){
   jclass cls = (*env)->GetObjectClass(env,allValues);
   jfieldID a = (*env)->GetFieldID(env, cls, "a", "I");
   jfieldID b = (*env)->GetFieldID(env, cls, "b", "I");
   jfieldID c = (*env)->GetFieldID(env, cls, "c", "I");
   jfieldID d = (*env)->GetFieldID(env, cls, "d", "I");
   jfieldID e = (*env)->GetFieldID(env, cls, "e", "I");
   jfieldID f = (*env)->GetFieldID(env, cls, "f", "I");
   jint avalue = (*env)->GetIntField(env, allValues, a);
   jint bvalue = (*env)->GetIntField(env, allValues, b);
   jint cvalue = (*env)->GetIntField(env, allValues, c);
   jint dvalue = (*env)->GetIntField(env, allValues, d);
   jint evalue = (*env)->GetIntField(env, allValues, e);
   jint fvalue = (*env)->GetIntField(env, allValues, f);
   return avalue + bvalue + cvalue + dvalue + evalue + fvalue
}

代码2 3,572 ms 运行了 10,000,000 次。代码 3 用了 86,217 ms — 多花了 24 倍的时间。

JNI 在 Java 代码和本机代码之间提供了一个干净的接口。为了维持这种分离，数组将作为不透明的句柄传递，并且本机代码必须回调 JVM 以便使用 set 和 get 调用操作数组元素。Java 规范让 JVM 实现决定让这些调用提供对数组的直接访问，还是返回一个数组副本。举例来说，当数组经过优化而不需要连续存储时，JVM 可以返回一个副本。（参见参考资料 获取关于 JVM 的信息）。

随后，这些调用可以复制被操作的元素。举例来说，如果您对含有 1,000 个元素的数组调用 GetLongArrayElements()，则会造成至少分配或复制 8,000 字节的数据（每个long 1,000 元素 * 8 字节）。当您随后使用 ReleaseLongArrayElements() 更新数组的内容时，需要另外复制 8,000 字节的数据来更新数组。即使您使用较新的GetPrimitiveArrayCritical()，规范仍然准许 JVM 创建完整数组的副本。

性能技巧三 回访而不是传递参数

在单个 API 调用中尽可能多地获取或更新数组内容。如果可以一次较多地获取和更新数组内容，则不要逐个迭代数组中的元素。

另一方面，如果您最终要获取数组中的所有元素，则使用 GetTypeArrayRegion() 逐个获取数组中的元素是得不偿失的。要获取最佳的性能，应该确保以尽可能大的块的来获取和更新数组元素。如果您要迭代一个数组中的所有元素，则清单 4代码4中这两个 getElement() 方法都不适用。比较好的方法是在一个调用中获取大小合理的数组部分，然后再迭代所有这些元素，重复操作直到覆盖整个数组。

在调用某个方法时，您经常会在传递一个有多个字段的对象以及单独传递字段之间做出选择。在面向对象设计中，传递对象通常能提供较好的封装，因为对象字段的变化不需要改变方法签名。但是，对于 JNI 来说，本机代码必须通过一个或多个 JNI 调用返回到 JVM 以获取需要的各个字段的值。这些额外的调用会带来额外的开销，因为从本机代码过渡到 Java 代码要比普通方法调用开销更大。因此，对于 JNI 来说，本机代码从传递进来的对象中访问大量单独字段时会导致性能降低。

考虑代码 5 中的两个方法，第二个方法假定我们缓存了字段 ID：代码 5. 两个方法版本

int sumValues(JNIEnv* env, jobject obj, jint a, jint b,jint c, jint d, jint e, jint f){
   return a + b + c + d + e + f;
}

int sumValues2(JNIEnv* env, jobject obj, jobject allValues){

   jint avalue = (*env)->GetIntField(env, allValues, a);
   jint bvalue = (*env)->GetIntField(env, allValues, b);
   jint cvalue = (*env)->GetIntField(env, allValues, c);
   jint dvalue = (*env)->GetIntField(env, allValues, d);
   jint evalue = (*env)->GetIntField(env, allValues, e);
   jint fvalue = (*env)->GetIntField(env, allValues, f);
   
   return avalue + bvalue + cvalue + dvalue + evalue + fvalue;
}

性能技巧四 使用大量本地引用而未通知 JVM

构造应用程序的数据，使它位于界限的正确的侧，并且可以由使用它的代码访问，而不需要大量跨界调用。

最显著的一个问题就是，清单 6代码6清单 6 中的接口在设置或检索每个位，以及从串行端口读取字节或者向串行端口写入字节都需要一个 JNI 调用。这会导致读取或写入的每个字节的 JNI 调用变成原来的 9 倍。第二个问题是，清单 6代码6清单 6 将串行端口的配置信息存储在 Java/本机界限的错误一侧的某个 Java 对象上。我们仅在本机侧需要此配置数据；将它存储在 Java 侧会导致本机代码向 Java 代码发起大量回调以获取/设置此配置信息。清单 7代码7清单 7 将配置信息存储在一个本机结构中（比如，一个struct），并向 Java 代码返回了一个不透明的句柄，该句柄可以在后续调用中返回。这意味着，当本机代码正在运行时，它可以直接访问该结构，而不需要回调 Java 代码获取串行端口硬件地址或下一个可用的缓冲区等信息。因此，使用清单 7代码7清单 7 的实现的性能将大大改善。JNI 函数返回的任何对象都会创建本地引用。举例来说，当您调用 GetObjectArrayElement() 时，将返回对数组中对象的本地引用。考虑代码 8 中的代码在运行一个很大的数组时会使用多少本地引用：

代码 8. 创建本地引用

void workOnArray(JNIEnv* env, jobject obj, jarray array){
   jint i;
   jint count = (*env)->GetArrayLength(env, array);
   for (i=0; i < count; i++) {
      jobject element = (*env)->GetObjectArrayElement(env, array, i);
      if((*env)->ExceptionOccurred(env)) {
         break;
      }
      
      /* do something with array element */
   }
}

每次调用 GetObjectArrayElement() 时都会为元素创建一个本地引用，并且直到本机代码运行完成时才会释放。数组越大，所创建的本地引用就越多。

性能技巧五 错误认定本机代码与 Java 代码之间的界限

如果可能，将各参数传递给 JNI 本机代码，以便本机代码回调 JVM 获取所需的数据。

sumValues2() 方法需要 6 个 JNI 回调，并且运行 10,000,000 次需要 3,572 ms。其速度比 sumValues() 慢 6 倍，后者只需要 596 ms。通过传递 JNI 方法所需的数据，sumValues() 避免了大量的 JNI 开销。

本机代码和 Java 代码之间的界限是由开发人员定义的。界限的选定会对应用程序的总体性能造成显著的影响。从 Java 代码中调用本机代码以及从本机代码调用 Java 代码的开销比普通的 Java 方法调用高很多。此外，这种越界操作会干扰 JVM 优化代码执行的能力。举例来说，随着 Java 代码与本机代码之间互操作的增加，实时编译器的效率会随之降低。经过测量，我们发现从 Java 代码调用本机代码要比普通调用多花 5 倍的时间。同样，从本机代码中调用 Java 代码也需要耗费大量的时间。

性能技巧六

定义 Java 代码与本机代码之间的界限，最大限度地减少两者之间的互相调用。

因此，在设计 Java 代码与本机代码之间的界限时应该最大限度地减少两者之间的相互调用。消除不必要的越界调用，并且应该竭力在本机代码中弥补越界调用造成的成本损失。最大限度地减少越界调用的一个关键因素是确保数据处于 Java/本机界限的正确一侧。如果数据未在正确的一侧，则另一侧访问数据的需求则会持续发起越界调用。

举例来说，如果我们希望使用 JNI 为某个串行端口提供接口，则可以构造两种不同的接口。第一个版本如代码 6 所示：

代码 6. 到串行端口的接口：版本 1

/**
 * Initializes the serial port and returns a java SerialPortConfig objects
 * that contains the hardware address for the serial port, and holds
 * information needed by the serial port such as the next buffer 
 * to write data into
 * 
 * @param env JNI env that can be used by the method
 * @param comPortName the name of the serial port
 * @returns SerialPortConfig object to be passed ot setSerialPortBit 
 *          and getSerialPortBit calls
 */
jobject initializeSerialPort(JNIEnv* env, jobject obj,  jstring comPortName);

/**
 * Sets a single bit in an 8 bit byte to be sent by the serial port
 *
 * @param env JNI env that can be used by the method
 * @param serialPortConfig object returned by initializeSerialPort
 * @param whichBit value from 1-8 indicating which bit to set
 * @param bitValue 0th bit contains bit value to be set 
 */
void setSerialPortBit(JNIEnv* env, jobject obj, jobject serialPortConfig, 
  jint whichBit,  jint bitValue);

/**
 * Gets a single bit in an 8 bit byte read from the serial port
 *
 * @param env JNI env that can be used by the method
 * @param serialPortConfig object returned by initializeSerialPort
 * @param whichBit value from 1-8 indicating which bit to read
 * @returns the bit read in the 0th bit of the jint 
 */
jint getSerialPortBit(JNIEnv* env, jobject obj, jobject serialPortConfig, 
  jint whichBit);

/**
 * Read the next byte from the serial port
 * 
 * @param env JNI env that can be used by the method
 */
void readNextByte(JNIEnv* env, jobject obj);

/**
 * Send the next byte
 *
 * @param env JNI env that can be used by the method
 */
void sendNextByte(JNIEnv* env, jobject obj);

在代码6中，串行端口的所有配置数据都存储在由 initializeSerialPort() 方法返回的 Java 对象中，并且将 Java 代码完全控制对硬件中各数据位的设置。清单 6代码6清单 6 所示版本的一些问题会造成其性能差于代码 7 中的版本：

代码 7. 到串行端口的接口：版本 2

/**
 * Initializes the serial port and returns an opaque handle to a native
 * structure that contains the hardware address for the serial port 
 * and holds information needed by the serial port such as 
 * the next buffer to write data into
 *
 * @param env JNI env that can be used by the method
 * @param comPortName the name of the serial port
 * @returns opaque handle to be passed to setSerialPortByte and 
 *          getSerialPortByte calls 
 */
jlong initializeSerialPort2(JNIEnv* env, jobject obj, jstring comPortName);

/**
 * sends a byte on the serial port
 * 
 * @param env JNI env that can be used by the method
 * @param serialPortConfig opaque handle for the serial port
 * @param byte the byte to be sent
 */
void sendSerialPortByte(JNIEnv* env, jobject obj, jlong serialPortConfig, 
    jbyte byte);

/**
 * Reads the next byte from the serial port
 * 
 * @param env JNI env that can be used by the method
 * @param serialPortConfig opaque handle for the serial port
 * @returns the byte read from the serial port
 */
jbyte readSerialPortByte(JNIEnv* env, jobject obj,  jlong serialPortConfig);

性能技巧七

如果某本机代码将同时存在大量本地引用，则调用 JNI EnsureLocalCapacity() 方法通知 JVM 并允许它优化对本地引用的处理。

您可以调用 JNI EnsureLocalCapacity() 方法来通知 JVM 您将使用超过 16 个本地引用。这将允许 JVM 优化对该本机代码的本地引用的处理。如果无法创建所需的本地引用，或者 JVM 采用的本地引用管理方法与所使用的本地引用数量之间不匹配造成了性能低下，则未成功通知 JVM 会导致FatalError。

性能技巧八

当本机代码造成创建大量本地引用时，在各引用不再需要时删除它们。

这些本地引用会在本机方法终止时自动释放。JNI 规范要求各本机代码至少能创建 16 个本地引用。虽然这对许多方法来说都已经足够了，但一些方法在其生存期中却需要更多的本地引用。对于这种情况，您应该删除不再需要的引用，方法是使用 JNIDeleteLocalRef() 调用，或者通知 JVM 您将使用更多的本地引用。

代码 9 向 代码8 中的示例添加了一个 DeleteLocalRef() 调用，用于通知 JVM 本地引用已不再需要，以及将可同时存在的本地引用的数量限制为一个合理的数值，而与数组的大小无关：

代码 9. 添加 DeleteLocalRef()

void workOnArray(JNIEnv* env, jobject obj, jarray array){
   jint i;
   jint count = (*env)->GetArrayLength(env, array);
   for (i=0; i < count; i++) {
      jobject element = (*env)->GetObjectArrayElement(env, array, i);
      if((*env)->ExceptionOccurred(env)) {
         break;
      }
      
      /* do something with array element */

      (*env)->DeleteLocalRef(env, element);
   }
}

正确性缺陷

5 大 JNI 正确性缺陷包括：

使用错误的 JNIEnv

执行本机代码的线程使用 JNIEnv 发起 JNI 方法调用。但是，JNIEnv 并不是仅仅用于分派所请求的方法。JNI 规范规定每个JNIEnv 对于线程来说都是本地的。JVM 可以依赖于这一假设，将额外的线程本地信息存储在 JNIEnv 中。一个线程使用另一个线程中的JNIEnv 会导致一些小 bug 和难以调试的崩溃问题。

仅在相关的单一线程中使用 JNIEnv。

线程可以调用通过 JavaVM 对象使用 JNI 调用接口的 GetEnv() 来获取 JNIEnv。JavaVM 对象本身可以通过使用JNIEnv 方法调用 JNI GetJavaVM() 来获取，并且可以被缓存以及跨线程共享。缓存 JavaVM 对象的副本将允许任何能访问缓存对象的线程在必要时获取对它自己的 JNIEnv 访问。要实现最优性能，线程应该绕过JNIEnv，因为查找它有时会需要大量的工作。

未检测异常

本机能调用的许多 JNI 方法都会引起与执行线程相关的异常。当 Java 代码执行时，这些异常会造成执行流程发生变化，这样便会自动调用异常处理代码。当某个本机方法调用某个 JNI 方法时会出现异常，但检测异常并采用适当措施的工作将由本机来完成。一个常见的 JNI 缺陷是调用 JNI 方法而未在调用完成后测试异常。这会造成代码有大量漏洞以及程序崩溃。

举例来说，考虑调用 GetFieldID() 的代码，如果无法找到所请求的字段，则会出现 NoSuchFieldError。如果本机代码继续运行而未检测异常，并使用它认为应该返回的字段 ID，则会造成程序崩溃。举例来说，如果 Java 类经过修改，导致charField 字段不再存在，则代码 10 中的代码可能会造成程序崩溃 — 而不是抛出一个 NoSuchFieldError：

代码 10. 未能检测异常在发起可能会导致异常的 JNI 调用后始终检测异常。

添加异常检测代码要比在事后尝试调试崩溃简单很多。经常，您只需要检测是否出现了某个异常，如果是则立即返回 Java 代码以便抛出异常。然后，使用常规的 Java 异常处理流程处理它或者显示它。举例来说，代码 11 将检测异常：

代码 11. 检测异常

jclass objectClass;
jfieldID fieldID;
jchar result = 0;

objectClass = (*env)->GetObjectClass(env, obj);
fieldID = (*env)->GetFieldID(env, objectClass, "charField", "C");
if((*env)->ExceptionOccurred(env)) {
   return;
}
result = (*env)->GetCharField(env, obj, fieldID);

不检测和清除异常会导致出现意外行为。您可以确定以下代码的问题吗？

fieldID = (*env)->GetFieldID(env, objectClass, "charField", "C");
if (fieldID == NULL){
   fieldID = (*env)->GetFieldID(env, objectClass,"charField", "D");
}
return (*env)->GetIntField(env, obj, fieldID);

问题在于，尽管代码处理了初始 GetFieldID() 未返回字段 ID 的情况，但它并未清除 此调用将设置的异常。因此，本机返回的结果会造成立即抛出一个异常。

未检测返回值

许多 JNI 方法都通过返回值来指示调用成功与否。与未检测异常相似，这也存在一个缺陷，即代码未检测返回值却假定调用成功而继续运行。对于大多数 JNI 方法来说，它们都设置了返回值和异常状态，这样应用程序更可以通过检测异常状态或返回值来判断方法运行正常与否。

始终检测 JNI 方法的返回值，并包括用于处理错误的代码路径。

您可以确定以下代码的问题吗？

clazz = (*env)->FindClass(env, "com/ibm/j9//HelloWorld");
method = (*env)->GetStaticMethodID(env, clazz, "main",
                   "([Ljava/lang/String;)V");
(*env)->CallStaticVoidMethod(env, clazz, method, NULL);

问题在于，如果未发现 HelloWorld 类，或者如果 main() 不存在，则本机将造成程序崩溃。

未正确使用数组方法

GetXXXArrayElements() 和 ReleaseXXXArrayElements() 方法允许您请求任何元素。同样，GetPrimitiveArrayCritical()、ReleasePrimitiveArrayCritical()、GetStringCritical() 和ReleaseStringCritical() 允许您请求数组元素或字符串字节，以最大限度降低直接指向数组或字符串的可能性。这些方法的使用存在两个常见的缺陷。其一，忘记在ReleaseXXX() 方法调用中提供更改。即便使用 Critical 版本，也无法保证您能获得对数组或字符串的直接引用。一些 JVM 始终返回一个副本，并且在这些 JVM 中，如果您在ReleaseXXX() 调用中指定了 JNI_ABORT，或者忘记调用了 ReleaseXXX()，则对数组的更改不会被复制回去。

举例来说，考虑以下代码：

void modifyArrayWithoutRelease(JNIEnv* env, jobject obj, jarray arr1) {
   jboolean isCopy;
   jbyte* buffer = (*env)-> (*env)->GetByteArrayElements(env,arr1,&isCopy);
   if ((*env)->ExceptionCheck(env)) return; 
   
   buffer[0] = 1;
}

其他正确性技巧一

不要忘记为每个 GetXXX() 使用模式 0（复制回去并释放内存）调用 ReleaseXXX()。

在提供直接指向数组的指针的 JVM 上，该数组将被更新；但是，在返回副本的 JVM 上则不是如此。这会造成您的代码在一些 JVM 上能够正常运行，而在其他 JVM 上却会出错。您应该始终始终包括一个释放（release）调用，如代码 12 所示：

代码 12. 包括一个释放调用

void modifyArrayWithRelease(JNIEnv* env, jobject obj, jarray arr1) {
   jboolean isCopy;
   jbyte* buffer = (*env)-> (*env)->GetByteArrayElements(env,arr1,&isCopy);
   if ((*env)->ExceptionCheck(env)) return; 
   
   buffer[0] = 1;

   (*env)->ReleaseByteArrayElements(env, arr1, buffer, JNI_COMMIT);
   if ((*env)->ExceptionCheck(env)) return;
}

第二个缺陷是不注重规范对在 GetXXXCritical() 和 ReleaseXXXCritical() 之间执行的代码施加的限制。本机可能不会在这些方法之间发起任何调用，并且可能不会由于任何原因而阻塞。未重视这些限制会造成应用程序或 JVM 中出现间断性死锁。

举例来说，以下代码看上去可能没有问题：

void workOnPrimitiveArray(JNIEnv* env, jobject obj, jarray arr1) {
   jboolean isCopy;
   jbyte* buffer = (*env)->GetPrimitiveArrayCritical(env, arr1, &isCopy); 
   if ((*env)->ExceptionCheck(env)) return; 
   
   processBufferHelper(buffer);
   
   (*env)->ReleasePrimitiveArrayCritical(env, arr1, buffer, 0); 
   if ((*env)->ExceptionCheck(env)) return;
}

其他正确性技巧二 未正确使用全局引用

确保代码不会在 GetXXXCritical() 和 ReleaseXXXCritical() 调用之间发起任何 JNI 调用或由于任何原因出现阻塞。

但是，我们需要验证在调用 processBufferHelper() 时可以运行的所有代码都没有违反任何限制。这些限制适用于在 Get 和 Release 调用之间执行的所有代码，无论它是不是本机的一部分。

本机可以创建一些全局引用，以保证对象在不再需要时才会被垃圾收集器回收。常见的缺陷包括忘记删除已创建的全局引用，或者完全失去对它们的跟踪。考虑一个本机创建了全局引用，但是未删除它或将它存储在某处：

lostGlobalRef(JNIEnv* env, jobject obj, jobject keepObj) {
   jobject gref = (*env)->NewGlobalRef(env, keepObj);
}

其他正确性技巧三

始终跟踪全局引用，并确保不再需要对象时删除它们。

创建全局引用时，JVM 会将它添加到一个禁止垃圾收集的对象列表中。当本机返回时，它不仅会释放全局引用，应用程序还无法获取引用以便稍后释放它 — 因此，对象将会始终存在。不释放全局引用会造成各种问题，不仅因为它们会保持对象本身为活动状态，还因为它们会将通过该对象能接触到的所有对象都保持为活动状态。在某些情况下，这会显著加剧内存泄漏。

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);
 } 
 static {
 //load the jni library
 System.loadLibrary("StaticMethodCall");
 }
 }

 JNI 代码，nativeMethod(int i) 的 C 语言实现
 #include
 #include
 #include"TestLocalReference.h"
 JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod
 (JNIEnv * env, jobject obj, jint count)
 {
 jint i = 0;
 jstring str;

 for(; iNewStringUTF(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
 #include
 #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

运行结果证明，实例 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。

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 对象。

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 表中。

分析错误实例 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 代码，或者继承了别处的某些 JVI 代码，如何才能确保避免了常见缺陷，或者在继承代码中发现它们？表 1 提供了一些确定这些常见缺陷的技巧：

表 1. 确定 JNI 编程缺陷的清单

	未缓存	触发数组副本	错误界限	过多回访	使用大量本地引用	使用错误的 JNIEnv	未检测异常	未检测返回值	未正确使用数组	未正确使用全局引用
规范验证						X	X		X
方法跟踪	X	X	X	X			X		X	X
转储										X
-verbose:jni					X
代码审查	X	X	X	X	X	X	X	X	X	X

您可以在开发周期的早期确定许多常见缺陷，方法如下：

• 根据规范验证新代码
• 分析方法跟踪
• 使用-verbose:jni 选项
• 生成转储
• 执行代码审查

根据 JNI 规范验证新代码

维持规范的限制列表并审查本机与列表的遵从性是一个很好的实践，这可以通过手动或自动代码分析来完成。确保遵从性的工作可能会比调试由于违背限制而出现的细小和间断性故障轻松很多。下面提供了一个专门针对新开发代码（或对您来说是新的）的规范顺从性检查列表：

• 验证 JNIEnv 仅与与之相关的线程使用。
• 确认未在 GetXXXCritical() 的 ReleaseXXXCritical() 部分调用 JNI 方法。
• 对于进入关键部分的方法，验证该方法未在释放前返回。
• 验证在所有可能引起异常的 JNI 调用之前都检测了异常。
• 确保所有 Get/Release 调用在各 JNI 方法中都是相匹配的。

IBM 的 JVM 实现包括开启自动 JNI 检测的选项，其代价是较慢的执行速度。与出色的代码单元测试相结合，这是一种极为强大的工具。您可以运行应用程序或单元测试来执行遵从性检查，或者确定所遇到的 bug 是否是由本机引起的。除了执行上述规范遵从性检查之外，它还能确保：

• 传递给 JNI 方法的参数属于正确的类型。
• JNI 代码未读取超过数组结束部分之外的内容。
• 传递给 JNI 方法的指针都是有效的。

JNI 检测报告的所有结论并不一定都是代码中的错误。它们还包括一些针对代码的建议，您应该仔细阅读它们以确保代码功能正常。

您可以通过以下命令行启用 JNI 检测选项：

Usage: -Xcheck:jni:[option[,option[,...]]]

        all            check application and system classes
        verbose        trace certain JNI functions and activities
        trace          trace all JNI functions
        nobounds       do not perform bounds checking on strings and arrays
        nonfatal       do not exit when errors are detected
        nowarn         do not display warnings
        noadvice       do not display advice
        novalist       do not check for va_list reuse
        valist         check for va_list reuse
        pedantic       perform more thorough, but slower checks
        help           print this screen

使用 IBM JVM 的 -Xcheck:jni 选项作为标准开发流程的一部分可以帮助您更加轻松地找出代码错误。特别是，它可以帮助您确定在错误线程中使用JNIEnv 以及未正确使用关键区域的缺陷的根源。

最新的 Sun JVM 提供了一个类似的 -Xcheck:jni 选项。它的工作原理不同于 IBM 版本，并且提供了不同的信息，但是它们的作用是相同的。它会在发现未符合规范的代码时发出警告，并且可以帮助您确定常见的 JNI 缺陷。

分析方法跟踪

生成对已调用本机方法以及这些本机方法发起的 JNI 回调的跟踪，这对确定大量常见缺陷的根源是非常有用的。可确定的问题包括：

• 大量 GetFieldID() 和 GetMethodID() 调用 — 特别是，如果这些调用针对相同的字段和方法 — 表示字段和方法未被缓存。
• GetTypeArrayElements() 调用实例（而非 GetTypeArrayRegion()）有时表示存在不必要的复制。
• 在 Java 代码与本机代码之前来回快速切换（由时间戳指示）有时表示 Java 代码与本机代码之间的界限有误，从而造成性能较差。
• 每个本机函数调用后面都紧接着大量 GetFieldID() 调用，这种模式表示并未传递所需的参数，而是强制本机回访完成工作所需的数据。
• 调用可能抛出异常的 JNI 方法之后缺少对 ExceptionOccurred() 或 ExceptionCheck() 的调用表示本机未正确检测异常。
• GetXXX() 和 ReleaseXXX() 方法调用的数量不匹配表示缺少释放操作。
• 在 GetXXXCritical() 和 ReleaseXXXCritical() 调用之间调用 JNI 方法表示未遵循规范施加的限制。
• 如果调用 GetXXXCritical() 和 ReleaseXXXCritical() 之间相隔的时间较长，则表示未遵循 “不要阻塞调用” 规范所施加的限制。
• NewGlobalRef() 和 DeleteGlobalRef() 调用之间出现严重失衡表示释放不再需要的引用时出现故障。

一些 JVM 实现提供了一种可用于生存方法跟踪的机制。您还可以通过各种外部工具来生成跟踪，比如探查器和代码覆盖工具。

IBM JVM 实现提供了许多用于生成跟踪信息的方法。第一种方法是使用 -Xcheck:jni:trace 选项。这将生成对已调用的本机方法以及它们发起的 JNI 回调的跟踪。代码 13 显示某个跟踪的摘录（为便于阅读，隔开了某些行）：

代码 13. IBM JVM 实现所生成的方法跟踪

Call JNI: java/lang/System.getPropertyList()[Ljava/lang/String; {
00177E00   Arguments: void
00177E00   FindClass("java/lang/String")
00177E00   FindClass("com/ibm/oti/util/Util")
00177E00   Call JNI: com/ibm/oti/vm/VM.useNativesImpl()Z {
00177E00     Arguments: void
00177E00     Return: (jboolean)false
00177E00   }
00177E00   Call JNI: java/security/AccessController.initializeInternal()V {
00177E00     Arguments: void
00177E00     FindClass("java/security/AccessController")
00177E00     GetStaticMethodID(java/security/AccessController, "doPrivileged", 
             "(Ljava/security/PrivilegedAction;)Ljava/lang/Object;")
00177E00     GetStaticMethodID(java/security/AccessController, "doPrivileged", 
             "(Ljava/security/PrivilegedExceptionAction;)Ljava/lang/Object;")
00177E00     GetStaticMethodID(java/security/AccessController, "doPrivileged", 
             "(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)
             Ljava/lang/Object;")
00177E00     GetStaticMethodID(java/security/AccessController, "doPrivileged", 
             "(Ljava/security/PrivilegedExceptionAction;
             Ljava/security/AccessControlContext;)Ljava/lang/Object;")
00177E00     Return: void
00177E00   }
00177E00   GetStaticMethodID(com/ibm/oti/util/Util, "toString", 
             "([BII)Ljava/lang/String;")
00177E00   NewByteArray((jsize)256)
00177E00   NewObjectArray((jsize)118, java/lang/String, (jobject)NULL)
00177E00   SetByteArrayRegion([B@0018F7D0, (jsize)0, (jsize)30, (void*)7FF2E1D4)
00177E00   CallStaticObjectMethod/CallStaticObjectMethodV(com/ibm/oti/util/Util, 
             toString([BII)Ljava/lang/String;, (va_list)0007D758) {
00177E00     Arguments: (jobject)0x0018F7D0, (jint)0, (jint)30
00177E00     Return: (jobject)0x0018F7C8
00177E00   }
00177E00   ExceptionCheck()

代码 13 中的跟踪摘录显示了已调用的本机方法（比如 AccessController.initializeInternal()V）以及本机方法发起的 JNI 回调。

使用 -verbose:jni 选项

Sun 和 IBM JVM 还提供了一个 -verbose:jni 选项。对于 IBM JVM 而言，开启此选项将提供关于当前 JNI 回调的信息。代码 14 显示了一个示例：

代码 14. 使用 IBM JVM 的 -verbose:jni 列出 JNI 回调

 ()V>

对于 Sun JVM 而言，开启 -verbose:jni 选项不会提供关于当前调用的信息，但它会提供关于所使用的本机方法的额外信息。代码 15 显示了一个示例：

代码 15. 使用 Sun JVM 的 -verbose:jni

[Dynamic-linking native method java.util.zip.ZipFile.getMethod ... JNI]
[Dynamic-linking native method java.util.zip.Inflater.initIDs ... JNI]
[Dynamic-linking native method java.util.zip.Inflater.init ... JNI]
[Dynamic-linking native method java.util.zip.Inflater.inflateBytes ... JNI]
[Dynamic-linking native method java.util.zip.ZipFile.read ... JNI]
[Dynamic-linking native method java.lang.Package.getSystemPackage0 ... JNI]
[Dynamic-linking native method java.util.zip.Inflater.reset ... JNI]

开启此选项还会让 JVM 针对使用过多本地引用而未通知 JVM 的情况发起警告。举例来说，IBM JVM 生成了这样一个消息：

JVMJNCK065W JNI warning in FindClass: Automatically grew local reference frame capacity 
from 16 to 48. 17 references are in use. 
Use EnsureLocalCapacity or PushLocalFrame to explicitly grow the frame.

虽然 -verbose:jni 和 -Xcheck:jni:trace 选项可帮助您方便地获取所需的信息，但手动审查此信息是一项艰巨的任务。一个不错的提议是，创建一些脚本或实用工具来处理由 JVM 生成的跟踪文件，并查看警告。

生成转储

运行中的 Java 进程生成的转储包含大量关于 JVM 状态的信息。对于许多 JVM 来说，它们包括关于全局引用的信息。举例来说，最新的 Sun JVM 在转储信息中包括这样一行：

JNI global references: 73

通过生成前后转储，您可以确定是否创建了任何未正常释放的全局引用。

您可以在 UNIX® 环境中通过对 java 进程发起 kill -3 或 kill -QUIT 来请求转储。在 Windows® 上，使用 Ctrl+Break 组合键。

对于 IBM JVM，使用以下步骤获取关于全局引用的信息：

1. 将 -Xdump:system:events=user 添加到命令行。这样，当您在 UNIX 系统上调用 kill -3 或者在 Windows 上按下 Ctrl+Break 时，JVM 便会生成转储。
2. 程序在运行中时会生成后续转储。
3. 运行 jextract -nozip core.XXX output.xml，这将会将转储信息提取到可读格式的 output.xml 中。
4. 查找 output.xml 中的 JNIGlobalReference 条目，它提供关于当前全局引用的信息，如清单 16 所示：

清单 16. output.xml 中的 JNIGlobalReference 条目

通过查看后续 Java 转储中报告的数值，您可以确定全局引用是否出现的泄漏。

参见 参考资料 获取关于使用转储文件以及 IBM JVM 的 jextract 的更多信息。

执行代码审查

代码审查经常可用于确定常见缺陷，并且可以在各种级别上完成。继承新代码时，快速扫描可以发现各种问题，从而避免稍后花费更多时间进行调试。在某些情况下，审查是确定缺陷实例（比如未检查返回值）的唯一方法。举例来说，此代码的问题可能可以通过代码审查轻松确定，但却很难通过调试来发现：

int calledALot(JNIEnv* env, jobject obj, jobject allValues){
   jclass cls = (*env)->GetObjectClass(env,allValues); 
   jfieldID a = (*env)->GetFieldID(env, cls, "a", "I");
   jfieldID b = (*env)->GetFieldID(env, cls, "b", "I");
   jfieldID c = (*env)->GetFieldID(env, cls, "c", "I");
   jfieldID d = (*env)->GetFieldID(env, cls, "d", "I");
   jfieldID e = (*env)->GetFieldID(env, cls, "e", "I");
   jfieldID f = (*env)->GetFieldID(env, cls, "f", "I");

}

jclass getObjectClassHelper(jobject object){ 
   /* use globally cached JNIEnv */
   return cls = (*globalEnvStatic)->GetObjectClass(globalEnvStatic,allValues); 
}

代码审查可能会发现第一个方法未正确缓存字段 ID，尽管重复使用了相同的 ID，并且第二个方法所使用的 JNIEnv 并不在应该在的线程上。

总结

本文阐述了 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 规范书中的使用规则。