如何通过正确管理局部引用和全局引用来避免JNI导致的程序崩溃

当本地代码需要回调到Java对象，但又不想控制该对象的生命周期时，弱引用就非常有用。例如，一个本地音频引擎在用户离开屏幕后不应该继续维持UI组件的存活状态，但只要UI组件还存在，音频引擎就应该能够与之进行交互。

误区4：直接使用弱全局引用

使用弱引用的错误在于将它们当作强引用来使用。

static jweak gCallback;

void NotifyProgress(JNIEnv* env, jint percent) {
  if (!env->IsSameObject(gCallback, nullptr)) {
    env->CallVoidMethod(gCallback, gOnProgress, percent);  // 这个代码存在隐患：可能会与垃圾回收器发生竞争条件
  }
}

这段代码会检查gCallback所引用的对象是否已经被垃圾回收器回收，如果没有被回收，就会调用该对象的方法。这个检查步骤和调用步骤是分开进行的，而垃圾回收器可能在它们之间运行。如果垃圾回收器在调用之前就回收了对象，那么CallVoidMethod就会尝试访问一个已经不存在的对象，这就是典型的“检查时存在，使用时已消失”的竞争条件问题，这种问题通常只在内存压力较大的情况下才会出现。

安全的做法是先将该弱引用转换为强引用，然后再进行后续操作。

void NotifyProgress(JNIEnv* env, jint percent) {
  jobject callback = env->NewLocalRef(gCallback);
  if (callback == nullptr) return;
  env->CallVoidMethod(callback, gOnProgress, percent);
  env->DeleteLocalRef(callback);
}

NewLocalRef会返回null（表示对象已经被回收），或者返回一个强类型的本地引用。一旦代码获得了这个本地引用，垃圾回收器就无法再回收该对象了，因此这样的调用是安全的。

NewLocalRef这一功能是在JNI 1.2版本中添加的，目前所有现代版本的JVM以及所有Android系统中都支持它。当不再需要某个弱引用时，应该使用DeleteWeakGlobalRef来释放它，而不是DeleteGlobalRef。

误区5：在多线程环境中共享JNIEnv

每个本地方法中传递的JNIEnv*指针都与当前线程相关联。该指针指向与特定线程相关的状态信息，例如本地引用表和未处理的异常信息。如果将这样的指针存储在全局变量中，并在另一个线程中使用它，就会导致这些状态数据被破坏。

static JNIEnv* gEnv;  // 注意：JNIEnv是指针是针对每个线程而言的

extern "C" JNIEXPORT void JNICALL
Java_com_example_Downloader_start(JNIEnv* env, jobject thiz) {
  gEnv = env;
  std::thread([] {
    DownloadFile();
    gEnv->CallStaticVoidMethod(gDownloaderClass, gOnComplete);
  }).detach();
}

这个本地方法会保存自己的JNIEnv*指针，然后启动一个工作线程，在文件下载完成后使用该指针。但此时，被保存的指针实际上属于另一个线程（也就是调用start方法的那个线程），而那个线程可能同时还在执行其他JNI代码。在使用了CheckJNI功能的ART环境中，这种情况会立即导致程序失败，并会出现“JNIEnv被错误地用于了其他线程”这样的错误信息；如果没有使用CheckJNI，就会导致不可预测的数据损坏。

正确的处理方式是：将JavaVM*指针缓存起来，让所有线程都能共享这个全局变量，然后每个线程在需要时再获取自己专属的JNIEnv*指针。

static JavaVM* gVm;

JNI jint JNI_OnLoad(JavaVM* vm, void* reserved) {
  gVm = vm;
  // 在这里缓存类和方法ID等信息。
  return JNI_VERSION_1_6;
}

void WorkerThread() {
  JNIEnv* env = nullptr;
  if (gVm->AttachCurrentThread(&env, nullptr) != JNI_OK) return;

  DownloadFile();
  env->CallStaticVoidMethod(gDownloaderClass, gOnComplete);
  if (env->ExceptionCheck()) env->ExceptionClear();

  gVm->DetachCurrentThread();
}

JNI_OnLoad方法会保存JavaVM*指针，这个指针在整个进程的生命周期内都是有效的。工作线程会通过调用AttachCurrentThread来向JVM注册自己，并获取属于自己的JENV* 指针；在退出之前，它会再次调用DetachCurrentThread来释放这个指针。需要注意的是，Android NDK中定义的AttachCurrentThread方法接受的是JNV* 类型的参数，而桌面JDK的头文件中定义的方法则接受void* 类型的参数，因此桌面代码需要使用reinterpret_cast(&env)来进行类型转换。

调用DetachCurrentThread是必须的。在通过AttachCurrentThread连接到JVM的线程中创建的本地引用，永远不会被自动释放，因为没有相应的本地方法返回来触发清理操作；只有当线程被分离时，这些引用才会被释放。

在Android系统中，如果一个仍在与JVM连接的本地线程退出了，那么ART系统会立即终止整个进程。因此，如果某个线程在整个运行过程中都保持与JVM的连接状态，那么一种常见的做法是注册一个pthread_key_create类型的销毁函数，在该线程退出时调用这个函数来执行DetachCurrentThread操作，这样就可以确保没有任何代码路径会忘记执行这个清理步骤。

陷阱6：从本地线程调用FindClass

当一个新的本地线程尝试调用应用程序自身类的FindClass方法时，也会出现类似的问题。

void WorkerThread() {
  JNIEnv* env = nullptr;
  gVm->AttachCurrentThread(&env, nullptr);
  jclass cls = env->FindClass("com/example/Downloader");  // 返回nullptr
  // ...
  gVm->DetachCurrentThread();
}

当在本地方法内部调用FindClass时，JVM会使用声明该方法的Java类的类加载器，因此应用程序中的类能够被正确地查找到。

通过AttachCurrentThread附加到的本地线程其栈中并不包含任何Java相关的信息。在这种情况下，JVM会转而使用系统的类加载器，但该加载器仅能处理框架类，因此查询会失败，FindClass会返回nullptr，进而引发ClassNotFoundException异常。如果代码没有检查返回值，那么在下次使用cls时程序就会崩溃。

标准的解决方法是在JNI_OnLoad中查找所有需要的类，并将它们存储为全局引用；绝对不要从本地线程调用FindClass。如果某个类需要动态加载，那么可以在JNI_OnLoad期间将其对应的ClassLoader对象的引用缓存起来，然后由工作线程来调用其loadClass方法。

陷阱7：忽略未处理的异常

当JNI调用失败或从本地代码调用的Java代码抛出异常时，该异常并不会导致本地线程栈中的执行流程中断。相反，这个异常会被标记为“待处理”，而本地函数会继续执行。在异常仍未被处理的情况下继续调用大多数JNI函数属于未定义的行为。

jstring name = static_cast(env->CallObjectMethod(user, gGetName));
const char* utf = env->GetStringUTFChars(name, nullptr);  // 如果getName()抛出异常，这里就会出错

如果getName()方法抛出了异常，那么CallObjectMethod会返回nullptr，并且让这个异常处于“待处理”状态。接下来的一行代码会将这个nullptr值传递给GetStringUTFChars方法，而此时异常仍然存在，这就违反了编程规范。使用CheckJNI工具时，ART会抛出类似“JNI GetStringUTFChars在异常未处理的情况下被调用”的错误信息；如果没有使用该工具，程序通常会因为尝试访问空指针而崩溃。

jstring name = static_cast(env->CallObjectMethod(user, gGetName));
if (env->ExceptionCheck()) {
  return nullptr;
}
const char* utf = env->GetStringUTFChars(name, nullptr);
if (utf == nullptr) {
  return nullptr;
}

在每次可能引发异常的调用之后，固定代码会检查ExceptionCheck()，如果存在未处理的异常，就会立即返回结果。从原生方法中返回时携带未处理的异常是允许且有益的：一旦控制权回到Java代码部分，该异常会被重新抛出，因此Java调用者会将其视为来自native方法的普通异常。

如果原生代码希望自行处理这些错误，它可以在进行任何进一步的JNI调用之前先调用ExceptionClear()。在存在未处理的异常时，有一小部分函数是被明确允许使用的，例如DeleteLocalRef、DeleteGlobalRef以及Release函数，这样就可以在返回之前完成必要的清理工作。

陷阱8：使用相等运算符比较引用

由于引用实际上是某种标识符而非对象地址，因此两个不同的标识符可以指向同一个Java对象。

if (listener == gListener) {  // 错误：这里比较的是标识符，而不是对象
  RemoveListener();
}

在这种比较中，listener是当前调用中传递进来的局部引用，而gListener则是之前创建的全局引用。即使它们都指向同一个Java对象，但由于在不同的数据结构中占据不同的位置，因此这些标识符代表的是不同的值，比较结果自然是错误的。这样一来，RemoveListener()方法也永远不会被执行。

if (env->IsSameObject(listener, gListener)) {
  RemoveListener();
}

IsSameObject方法会询问JVM这两个标识符是否都指向同一个对象，这正是你想要进行的比较操作。将null作为第二个参数传递也是检查弱全局引用是否已被清除的标准方法；不过正如陷阱4中所提到的，如果你之后还需要使用该对象，那么使用NewLocalRef会更为安全。

如何利用CheckJNI捕获引用相关错误

本文中提到的大多数错误要么是偶然发生的，要么会导致与实际问题无关的异常。CheckJNI是一种扩展验证机制，它会让这些错误立即以明显的形式显现出来，并且会提供有关出错位置的具体信息。

在Android系统中，对于那些使用了android:debuggable="true"属性构建的应用程序，以及模拟器环境，CheckJNI都是默认启用的。如果你想在真实设备上为所有应用程序启用这一功能，可以运行以下命令，然后重新启动应用程序：

adb shell setprop debug.checkjni 1

这个命令会设置一个系统属性，让ART在之后启动的每个应用程序进程中都启用CheckJNI。不过这对已经正在运行的进程没有影响，因此需要重新启动应用程序才能使设置生效。

当CheckJNI处于启用状态时，ART会对每一个JNI调用进行验证：它会拒绝无效的局部引用、在错误线程上使用的引用、在存在未处理异常的情况下进行的调用、从错误线程使用的JNIEnv*指针、不匹配的Release调用以及非法的方法ID。一旦检测到错误，ART会在logcat中输出“JNI DETECTED ERROR IN APPLICATION”这样的提示信息，同时还会附带问题的详细描述和原生代码的堆栈跟踪信息，之后程序就会终止运行。

在桌面版的JVM上，应使用-Xcheck:jni参数来启用这一功能。

java -Xcheck:jni -Djava.library.path=build/libs -jar app.jar

这样运行应用程序时，HotSpot的JNI检查功能就会被激活，并且会从build/libs目录中加载本地库。对于许多类似的问题，比如在异常尚未被处理的情况下进行调用或使用了无效的引用，HotSpot都会发出警告。不过它的检查机制通常比ART的宽松一些，因此那些在桌面环境下使用-Xcheck:jni能够正常运行的应用程序，在Android平台上使用CheckJNI时仍有可能出现问题。如果在两个平台上都启用CheckJNI来进行测试，包括那些涉及处理大型数组或在本地线程中执行操作的测试，那么大多数引用相关的问题都能在程序发布之前被及时发现。

如何使用RAII机制安全地管理引用

手动调用DeleteLocalRef和DeleteGlobalRef很容易被遗忘，尤其是在函数返回路径较早的地方。C++允许将引用的生命周期与某个作用域绑定在一起，就像std::unique_ptr管理堆内存一样。

template 
class ScopedLocalRef {
 public:
 ScopedLocalRef(JNIEnv* env, T ref) : env_(env), ref_(ref) {}
  ~scopedLocalRef() {
    if (ref_ != nullptr) env_->DeleteLocalRef(ref_);
  }
  scopedLocalRef(const scopedLocalRef&) = delete;
  scopedLocalRef& operator=(const scopedLocalRef&) = delete;

  T get() const { return ref_; }

 private:
  JNIEnv* env_;
  T ref_;
};

ScopedLocalRef会拥有对某个局部引用的所有权，并会在其析构函数中删除该引用，因此无论外部作用域是如何结束的（无论是正常执行完毕、提前返回，还是发生了C++异常），这个引用都会被正确释放。由于两个持有相同引用的对象尝试同时删除同一个引用可能会导致问题，因此ScopedLocalRef没有提供拷贝构造函数和拷贝赋值运算符。而get()方法则用于返回原始的引用句柄，以便将其传递给JNI函数。

for (jsize i = 0; i < count; i++) {
  ScopedLocalRef name(
      env, static_cast(env->GetObjectArrayElement(names, i)));
  const char* utf = env->>GetStringUTFChars(name.get(), nullptr);
  if (utf == nullptr) return;
  LogName(utf);
  env->>ReleaseStringUTFChars(name.get(), utf);
}

class ScopedGlobalRef {
 public:
  ScopedGlobalRef(JNIEnv* env, jobject obj)
      : ref_(obj ? env->NewGlobalRef(obj) : nullptr) {
    env->GetJavaVM(&vm_);
  }
  ~ScopedGlobalRef() {
    JNIEnv* env = nullptr;
    if (ref_ != nullptr && vm->GetEnv(reinterpret_castDeleteGlobalRef(ref_);
    }
  }
  ScopedGlobalRef(const ScopedGlobalRef&) = delete;
  ScopedGlobalRef& operator=(constScopedGlobalRef&) = delete;

  jobject get() const { return ref_; }

 private:
  JavaVM* vm_ = nullptr;
  jobject ref_;
};