JNI内存管理——引用类型与泄漏防范

JNI内存管理------引用类型与泄漏防范

在Android NDK开发中，JNI（Java Native Interface）是连接Java层与Native层（C/C++）的核心桥梁，它允许两种语言相互调用、共享数据。但由于Java层采用自动垃圾回收（GC）机制，而Native层需要手动管理内存，两者的内存管理模型差异极大，稍有不慎就会引发内存泄漏，导致应用卡顿、崩溃、内存溢出（OOM）等问题。

JNI内存管理的核心是引用类型的管理------所有Java对象在Native层的访问都必须通过JNI引用，不同类型的引用对应不同的生命周期和使用场景，若引用创建、释放不当，必然导致内存泄漏。本文将从JNI引用类型的区别、创建与释放、泄漏案例分析，以及Android Studio工具排查四个维度，详细讲解如何规范管理JNI内存，写出稳定、无泄漏的Native代码。

一、JNI核心引用类型：区别与适用场景

JNI定义了三种核心引用类型：局部引用（Local Reference）、全局引用（Global Reference）、弱全局引用（Weak Global Reference）。它们的生命周期、作用域、是否阻止GC回收，以及适用场景存在本质区别，这是避免内存泄漏的基础，必须精准掌握。

1.1 局部引用（Local Reference）：最常用，自动回收但需警惕溢出

局部引用是JNI开发中最常见的引用类型，绝大多数JNI函数返回的引用（如FindClass、NewObject、GetObjectArrayElement等）默认都是局部引用。

核心特性

生命周期：仅限于当前Native方法调用期间，当Native方法执行完毕、返回Java层时，JVM会自动释放所有局部引用，无需手动调用释放函数。
作用域：仅在创建它的Native线程中有效，不能跨线程使用；也不能存储在全局变量中，供后续其他Native方法调用（否则会导致引用失效，引发崩溃）。
GC影响：会阻止被引用的Java对象被GC回收，只要局部引用存在，即使Java层已无引用指向该对象，GC也无法回收。
数量限制：JVM对每个线程的局部引用数量有上限（通常为512~65536个，视JVM实现而定），超过限制会抛出java.lang.OutOfMemoryError: Cannot create Local Reference异常。

适用场景

适用于Native方法内部临时使用的Java对象，比如方法内获取的Java类、创建的临时对象、从Java层传入的参数对象等，使用完毕后无需手动释放（特殊场景除外）。

注意点

虽然局部引用会自动回收，但在以下场景必须手动释放，否则会导致局部引用表溢出或内存泄漏：

循环中频繁创建局部引用（如遍历大数组，每次迭代创建局部引用）；
创建大对象（如大数组、复杂Java对象）的局部引用，且后续还有大量计算操作，导致GC无法及时回收该对象；
Native方法进入无限循环或长期运行（如事件调度循环），无法触发JVM的自动回收机制。

1.2 全局引用（Global Reference）：跨作用域，手动管理生命周期

全局引用是手动创建的、生命周期由开发者控制的引用，用于需要跨Native方法、跨线程使用的Java对象。

核心特性

生命周期：由开发者手动创建（NewGlobalRef）和释放（DeleteGlobalRef），只要不手动释放，会一直存在，直到应用进程终止。
作用域：全局有效，可跨所有Native方法、跨所有线程使用，可存储在全局变量中供后续调用。
GC影响：会强制阻止被引用的Java对象被GC回收，即使Java层已无引用，只要全局引用存在，对象就会一直驻留内存。
数量限制：无明确上限，但过度创建未释放的全局引用，会导致Java对象无法回收，引发内存泄漏。

适用场景

适用于需要长期复用、跨方法/跨线程访问的Java对象，比如：

缓存频繁使用的Java类（如FindClass获取的类对象）、方法ID（jmethodID）、字段ID（jfieldID）；
Native层需要长期持有、反复访问的Java对象（如回调接口实例、全局配置对象）。

注意点

全局引用是内存泄漏的"重灾区"，必须严格遵循"创建即释放"的原则，在不需要使用时及时调用DeleteGlobalRef释放，否则会导致对象永久驻留内存。

1.3 弱全局引用（Weak Global Reference）：弱引用，不阻止GC回收

弱全局引用（Weak Global Reference）是一种特殊的全局引用，引入的目的是解决"全局引用阻止GC回收"的问题，适用于"缓存可回收对象"的场景。

核心特性

生命周期：由开发者手动创建（NewWeakGlobalRef）和释放（DeleteWeakGlobalRef），但即使不释放，当被引用的Java对象被GC回收后，弱全局引用会自动失效。
作用域：全局有效，可跨方法、跨线程使用，可存储在全局变量中。
GC影响：不阻止被引用的Java对象被GC回收，当Java层无其他强引用（局部引用、全局引用）指向该对象时，GC会正常回收，此时弱全局引用变为无效（指向NULL）。
使用限制：不能直接使用弱全局引用访问Java对象，必须先通过NewLocalRef将其转为局部引用，且使用前需判断引用是否有效（避免访问已被回收的对象）。

适用场景

适用于缓存"可重新创建、非必须长期持有"的Java对象，比如：

缓存非核心配置对象，即使被GC回收，后续可重新创建；
避免全局引用导致的内存泄漏，比如缓存Java类对象（若类可被卸载，弱引用不会阻止其卸载）。

1.4 三种引用类型对比表

引用类型	生命周期	作用域	是否阻止GC	创建方法	释放方法	适用场景
局部引用	Native方法执行期间，自动回收	当前线程、当前方法	是	默认（FindClass等）、NewLocalRef	DeleteLocalRef（手动）、JVM自动回收	方法内临时使用的对象
全局引用	手动创建到手动释放	全局、跨线程、跨方法	是	NewGlobalRef	DeleteGlobalRef（必须手动）	长期复用、跨作用域对象
弱全局引用	手动创建到对象被GC回收或手动释放	全局、跨线程、跨方法	否	NewWeakGlobalRef	DeleteWeakGlobalRef（手动）	可回收的缓存对象

二、引用的创建与释放：规范操作是关键

JNI引用的创建和释放有明确的API规范，不同引用类型的操作方法不同，错误的操作（如用错释放方法、遗漏释放）是导致内存泄漏的主要原因。下面详细讲解每种引用的创建、释放API及规范示例。

2.1 局部引用：创建与释放

创建方式

局部引用的创建主要有两种方式，无需手动调用专门的"创建"API，大多是JNI函数的返回值：

默认创建：大多数JNI函数返回的引用都是局部引用，如FindClass（获取Java类）、NewObject（创建Java对象）、GetObjectField（获取对象字段）、GetObjectArrayElement（获取数组元素）等。
手动创建：通过NewLocalRef函数，将已有的引用（如全局引用、弱全局引用）转为局部引用，用于临时访问。

释放方式

正常情况下，Native方法返回后JVM自动释放，但特殊场景（循环、大对象）需手动释放，使用DeleteLocalRef函数。

规范示例

c 复制代码

// 局部引用规范使用示例
JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_processData(JNIEnv *env, jobject thiz, jobjectArray dataArray) {
    jsize length = env->GetArrayLength(dataArray);
    for (int i = 0; i < length; i++) {
        // 1. 默认创建局部引用（获取数组元素）
        jobject element = env->GetObjectArrayElement(env, dataArray, i);
        if (element == NULL) {
            continue;
        }
        // 处理element对象...
        // 2. 手动释放局部引用（循环中必须释放，避免引用表溢出）
        env->DeleteLocalRef(env, element);
    }
    // 方法返回后，未手动释放的局部引用会被JVM自动回收
}

2.2 全局引用：创建与释放

创建方式

必须通过NewGlobalRef函数手动创建，参数是一个已有的局部引用（不能直接用弱全局引用创建），创建成功后返回全局引用。

注意：创建全局引用后，应立即释放对应的局部引用（避免局部引用冗余）。

释放方式

必须通过DeleteGlobalRef函数手动释放，且释放后需将全局引用变量置为NULL，避免后续误使用（访问已释放的引用会引发崩溃）。

规范示例

c 复制代码

// 定义全局引用变量（存储在全局变量中，供跨方法使用）
static jclass g_StringClass = NULL;

// 初始化全局引用
JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_initGlobalRef(JNIEnv *env, jobject thiz) {
    // 1. 获取局部引用（FindClass返回局部引用）
    jclass localStringClass = env->FindClass(env, "java/lang/String");
    if (localStringClass == NULL) {
        return; // 避免空指针
    }
    // 2. 创建全局引用（将局部引用转为全局引用）
    g_StringClass = (jclass)env->NewGlobalRef(env, localStringClass);
    // 3. 释放局部引用（创建全局引用后，局部引用已无用）
    env->DeleteLocalRef(env, localStringClass);
}

// 释放全局引用
JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_releaseGlobalRef(JNIEnv *env, jobject thiz) {
    if (g_StringClass != NULL) {
        // 手动释放全局引用
        env->DeleteGlobalRef(env, g_StringClass);
        // 置为NULL，避免后续误使用
        g_StringClass = NULL;
    }
}

2.3 弱全局引用：创建与释放

创建方式

通过NewWeakGlobalRef函数手动创建，参数可以是局部引用或全局引用，创建成功后返回弱全局引用。

释放方式

通过DeleteWeakGlobalRef函数手动释放，即使不释放，当被引用对象被GC回收后，弱引用也会失效，但建议手动释放（避免弱引用本身占用的内存无法回收）。

使用注意

弱全局引用不能直接访问Java对象，必须先通过NewLocalRef转为局部引用，且使用前需通过IsSameObject判断引用是否有效（避免访问已被GC回收的对象）。

规范示例

c 复制代码

// 定义弱全局引用变量
static jweak g_ConfigWeakRef = NULL;

// 设置弱全局引用（缓存配置对象）
JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_setConfig(JNIEnv *env, jobject thiz, jobject config) {
    // 若已有弱引用，先释放
    if (g_ConfigWeakRef != NULL) {
        env->DeleteWeakGlobalRef(env, g_ConfigWeakRef);
        g_ConfigWeakRef = NULL;
    }
    // 创建弱全局引用
    g_ConfigWeakRef = env->NewWeakGlobalRef(env, config);
}

// 使用弱全局引用
JNIEXPORT jboolean JNICALL Java_com_example_jnimemory_MainActivity_useConfig(JNIEnv *env, jobject thiz) {
    if (g_ConfigWeakRef == NULL) {
        return JNI_FALSE;
    }
    // 1. 将弱全局引用转为局部引用（才能访问对象）
    jobject config = env->NewLocalRef(env, g_ConfigWeakRef);
    // 2. 判断引用是否有效（对象是否已被GC回收）
    if (config == NULL || env->IsSameObject(env, config, NULL) == JNI_TRUE) {
        return JNI_FALSE; // 对象已回收
    }
    // 处理config对象...
    // 3. 释放局部引用
    env->DeleteLocalRef(env, config);
    return JNI_TRUE;
}

// 释放弱全局引用
JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_releaseWeakRef(JNIEnv *env, jobject thiz) {
    if (g_ConfigWeakRef != NULL) {
        env->DeleteWeakGlobalRef(env, g_ConfigWeakRef);
        g_ConfigWeakRef = NULL;
    }
}

2.4 关键注意事项

释放引用时，必须匹配引用类型：不能用DeleteLocalRef释放全局引用/弱全局引用，也不能用DeleteGlobalRef释放局部引用，否则会引发崩溃。
避免"悬空引用"：引用释放后，必须将对应的变量置为NULL，避免后续代码误访问已释放的引用。
jmethodID和jfieldID：这两个类型不是JNI引用，无需手动释放，获取后可长期使用（只要对应的类未被卸载）。

三、JNI内存泄漏案例分析：常见场景与解决方案

JNI内存泄漏的本质是：Native层持有Java对象的引用（局部、全局、弱全局），但在不需要使用时未释放，导致Java对象无法被GC回收，长期占用内存。下面结合实际开发中最常见的泄漏场景，分析原因并给出解决方案。

案例1：未释放的全局引用（最常见）

泄漏场景

开发者创建全局引用后，忘记在应用退出、组件销毁（如Activity的onDestroy）时调用DeleteGlobalRef释放，导致全局引用一直持有Java对象，GC无法回收，随着应用运行时间增长，内存持续泄漏。

c 复制代码

// 错误示例：创建全局引用后未释放
static jclass g_UserClass = NULL;

JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_init(JNIEnv *env, jobject thiz) {
    jclass localClass = env->FindClass(env, "com/example/jnimemory/User");
    if (localClass != NULL) {
        g_UserClass = (jclass)env->NewGlobalRef(env, localClass);
        // 遗漏：未释放局部引用localClass
        // 遗漏：未在合适时机释放g_UserClass
    }
}

// 未实现释放全局引用的方法，当Activity销毁、应用退出时，g_UserClass依然存在
// 导致User类对象无法被GC回收，长期占用内存

泄漏原因

全局引用g_UserClass未手动释放，生命周期与进程一致；
创建全局引用后，未释放对应的局部引用localClass（虽不导致泄漏，但浪费内存）。

解决方案

为全局引用提供对应的释放方法，在组件销毁（如Activity.onDestroy）或应用退出时调用；
创建全局引用后，立即释放对应的局部引用。

c 复制代码

// 正确示例
static jclass g_UserClass = NULL;

JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_init(JNIEnv *env, jobject thiz) {
    jclass localClass = env->FindClass(env, "com/example/jnimemory/User");
    if (localClass != NULL) {
        g_UserClass = (jclass)env->NewGlobalRef(env, localClass);
        env->DeleteLocalRef(env, localClass); // 释放局部引用
    }
}

// 在Activity销毁时调用此方法，释放全局引用
JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_release(JNIEnv *env, jobject thiz) {
    if (g_UserClass != NULL) {
        env->DeleteGlobalRef(env, g_UserClass);
        g_UserClass = NULL;
    }
}

案例2：线程局部缓存导致的局部引用泄漏

泄漏场景

在Native线程中，将局部引用存储在线程局部存储（TLS）或线程全局变量中，用于缓存频繁使用的Java对象，但线程长期运行（如后台线程），且未手动释放局部引用，导致局部引用表持续膨胀，最终引发OOM。

c 复制代码

// 错误示例：线程局部缓存未释放局部引用
void *nativeThreadFunc(void *arg) {
    JNIEnv *env = NULL;
    // 附加线程到JVM，获取JNIEnv
    (*g_vm)->AttachCurrentThread(g_vm, &env, NULL);
    
    while (1) { // 线程无限循环运行
        // 创建局部引用（缓存Java对象）
        jclass localClass = env->FindClass(env, "com/example/jnimemory/Utils");
        // 处理localClass...
        // 遗漏：未释放局部引用，线程一直运行，局部引用表持续增长
        sleep(1);
    }
    
    (*g_vm)->DetachCurrentThread(g_vm);
    return NULL;
}

泄漏原因

线程无限循环运行，每次迭代都创建局部引用，且未手动释放，JVM无法自动回收（因为线程未退出，Native方法未返回），导致局部引用表溢出，进而引发内存泄漏和OOM。

解决方案

线程中创建的局部引用，使用完毕后立即调用DeleteLocalRef释放；
若需长期缓存，改用全局引用或弱全局引用，并在线程退出时释放。

c 复制代码

// 正确示例
void *nativeThreadFunc(void *arg) {
    JNIEnv *env = NULL;
    (*g_vm)->AttachCurrentThread(g_vm, &env, NULL);
    
    // 若需长期缓存，使用全局引用
    static jclass g_UtilsClass = NULL;
    if (g_UtilsClass == NULL) {
        jclass localClass = env->FindClass(env, "com/example/jnimemory/Utils");
        g_UtilsClass = (jclass)env->NewGlobalRef(env, localClass);
        env->DeleteLocalRef(env, localClass);
    }
    
    while (1) {
        // 使用全局引用g_UtilsClass，无需每次创建局部引用
        // 处理逻辑...
        sleep(1);
    }
    
    // 线程退出时，释放全局引用
    if (g_UtilsClass != NULL) {
        env->DeleteGlobalRef(env, g_UtilsClass);
        g_UtilsClass = NULL;
    }
    (*g_vm)->DetachCurrentThread(g_vm);
    return NULL;
}

案例3：异常路径遗漏引用释放

泄漏场景

在Native方法中，创建引用后，若在异常分支（如if判断失败、函数返回）中遗漏释放引用，导致引用无法释放，引发内存泄漏。

c 复制代码

// 错误示例：异常路径遗漏引用释放
JNIEXPORT jobject JNICALL Java_com_example_jnimemory_MainActivity_createUser(JNIEnv *env, jobject thiz) {
    jclass userClass = env->FindClass(env, "com/example/jnimemory/User");
    if (userClass == NULL) {
        return NULL; // 异常分支：未释放userClass（局部引用）
    }
    
    jmethodID constructor = env->GetMethodID(env, userClass, "<init>", "()V");
    if (constructor == NULL) {
        return NULL; // 异常分支：未释放userClass
    }
    
    jobject user = env->NewObject(env, userClass, constructor);
    // 遗漏：未释放userClass（局部引用）
    return user;
}

泄漏原因

当FindClass或GetMethodID失败时，直接返回NULL，未释放已创建的局部引用userClass；即使创建User对象成功，也未释放userClass，导致局部引用无法回收。

解决方案

采用"创建即释放"的原则，在所有异常分支、函数返回前，确保释放已创建的引用；可使用goto语句统一处理释放逻辑（Native层常用技巧）。

c 复制代码

// 正确示例：统一处理引用释放
JNIEXPORT jobject JNICALL Java_com_example_jnimemory_MainActivity_createUser(JNIEnv *env, jobject thiz) {
    jclass userClass = NULL;
    jobject user = NULL;
    
    userClass = env->FindClass(env, "com/example/jnimemory/User");
    if (userClass == NULL) {
        goto END; // 异常分支，跳转到释放逻辑
    }
    
    jmethodID constructor = env->GetMethodID(env, userClass, "<init>", "()V");
    if (constructor == NULL) {
        goto END; // 异常分支，跳转到释放逻辑
    }
    
    user = env->NewObject(env, userClass, constructor);
    
END:
    // 统一释放局部引用
    if (userClass != NULL) {
        env->DeleteLocalRef(env, userClass);
    }
    return user;
}

案例4：弱全局引用使用不当导致的泄漏

泄漏场景

开发者使用弱全局引用缓存Java对象，但未在弱引用失效后释放弱引用本身，导致弱引用占用的内存无法回收；或误将弱引用当作强引用使用，频繁创建局部引用未释放。

c 复制代码

// 错误示例：弱全局引用使用不当
static jweak g_ImageWeakRef = NULL;

JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_cacheImage(JNIEnv *env, jobject thiz, jobject image) {
    // 未释放已有弱引用，直接覆盖
    g_ImageWeakRef = env->NewWeakGlobalRef(env, image);
}

JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_useImage(JNIEnv *env, jobject thiz) {
    if (g_ImageWeakRef == NULL) {
        return;
    }
    // 每次调用都创建局部引用，未释放
    jobject image = env->NewLocalRef(env, g_ImageWeakRef);
    if (image != NULL) {
        // 处理image...
    }
    // 遗漏：未释放局部引用image
}

泄漏原因

缓存新的弱引用时，未释放旧的弱引用，导致旧弱引用占用的内存无法回收；
每次使用弱引用时，创建局部引用后未释放，导致局部引用表膨胀。

解决方案

缓存新的弱引用前，先释放旧的弱引用；
使用弱引用创建的局部引用，使用完毕后立即释放。

c 复制代码

// 正确示例
static jweak g_ImageWeakRef = NULL;

JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_cacheImage(JNIEnv *env, jobject thiz, jobject image) {
    // 释放旧的弱引用
    if (g_ImageWeakRef != NULL) {
        env->DeleteWeakGlobalRef(env, g_ImageWeakRef);
    }
    g_ImageWeakRef = env->NewWeakGlobalRef(env, image);
}

JNIEXPORT void JNICALL Java_com_example_jnimemory_MainActivity_useImage(JNIEnv *env, jobject thiz) {
    if (g_ImageWeakRef == NULL) {
        return;
    }
    jobject image = env->NewLocalRef(env, g_ImageWeakRef);
    if (image != NULL) {
        // 处理image...
        env->DeleteLocalRef(env, image); // 释放局部引用
    }
}

四、使用Android Studio的Memory Profiler检测Native内存泄漏

即使遵循规范开发，也可能因疏忽导致JNI内存泄漏。此时需要借助工具排查，Android Studio自带的Memory Profiler（内存分析器）可以直观地监控Native层内存使用情况，定位泄漏点。

Memory Profiler不仅能监控Java堆内存，还能监控Native堆内存（Android 8.0及以上系统支持），并提供JNI引用查看功能，帮助开发者快速定位未释放的引用。

4.1 准备工作

环境要求：Android Studio 4.0及以上版本，测试设备需为Android 8.0（API 26）及以上（支持Native内存监控）；
开启调试模式：测试设备开启USB调试，连接到Android Studio；
配置NDK：确保项目已配置NDK，且Native代码已编译成功（生成.so文件）。

4.2 打开Memory Profiler

打开Android Studio，运行项目，确保应用在测试设备上正常启动；
点击顶部菜单栏的「View」→「Tool Windows」→「Profiler」（或直接点击工具栏的「Profile」按钮）；
在Profiler窗口中，选择当前运行的应用进程（若未显示，确保设备已正确连接，且USB调试已开启）；
点击Profiler窗口中的「Memory」标签，进入Memory Profiler界面，此时会显示应用的内存使用实时曲线（包括Java堆、Native堆、系统内存等）。

4.3 监控Native内存泄漏

步骤1：观察Native内存曲线

Memory Profiler的内存曲线中，「Native」部分对应Native层内存使用情况。若出现以下现象，大概率存在Native内存泄漏：

Native内存持续增长，即使执行GC（点击Profiler中的「Force GC」按钮），内存也不会明显下降；
多次操作应用（如反复进入/退出包含JNI调用的页面）后，Native内存持续攀升，无趋于稳定的迹象。

步骤2：捕获Native内存快照（Heap Dump）

为了定位泄漏点，需要捕获Native内存快照，查看当前Native层的内存分配和引用情况：

在Memory Profiler界面，点击「Capture heap dump」按钮（垃圾桶图标旁边）；
在弹出的对话框中，选择「Native heap」（仅Android 8.0及以上支持），点击「OK」；
等待快照捕获完成（耗时可能较长，取决于内存大小），捕获完成后会显示Native堆的详细信息。

步骤3：查看JNI引用，定位泄漏点

Memory Profiler支持查看全局JNI引用，这是定位JNI引用泄漏的关键：

在快照查看界面，点击顶部的「JNI heap」下拉菜单，选择「Global JNI References」；
此时会显示所有当前存在的全局JNI引用，包括引用的Java对象类型、创建位置（Native调用栈）等信息；
排查异常引用：若某个全局引用对应的Java对象已无需使用，但仍存在于列表中，且引用数量持续增加，说明该引用未被释放，存在泄漏；
双击引用对应的「Allocation Call Stack」（分配调用栈），可跳转到Native代码中创建该引用的位置，进而修复泄漏问题。

步骤4：验证修复效果

修复代码后，重新运行应用，再次使用Memory Profiler监控Native内存：

若Native内存曲线趋于稳定，执行GC后内存能明显下降，说明泄漏已修复；
若仍存在内存增长，重复上述步骤，排查其他可能的泄漏点（如未释放的局部引用、弱全局引用）。

4.4 补充技巧

开启CheckJNI：通过命令adb shell setprop debug.checkjni 1开启CheckJNI模式，可检测JNI引用使用错误（如用错释放方法），并在Logcat中输出错误信息；
结合Logcat：在Native代码中添加日志，打印引用的创建和释放情况，辅助定位泄漏点；
对比快照：多次捕获Native堆快照，对比引用数量变化，找出持续增加的引用。

五、总结：写出稳定无泄漏Native代码的核心原则

JNI内存管理的核心是"明确引用生命周期，规范创建与释放"，结合本文内容，总结以下核心原则，帮助开发者规避内存泄漏：

明确引用类型：根据使用场景选择合适的引用类型，避免滥用全局引用（优先用局部引用，需跨作用域时用全局/弱全局引用）；
规范操作API：严格按照"创建-使用-释放"的流程操作，全局引用和弱全局引用必须手动释放，局部引用在循环、大对象场景下手动释放；
规避常见陷阱：避免跨线程使用局部引用、异常路径遗漏释放、全局引用未释放、弱引用使用不当等问题；
善用工具排查：开发过程中定期用Memory Profiler监控Native内存，及时发现并修复泄漏点；
养成良好习惯：编写Native代码时，始终考虑引用的释放，可借助goto语句统一处理释放逻辑，减少遗漏。

JNI内存泄漏排查往往比较复杂，需要开发者熟悉引用类型的特性和内存管理机制，同时结合工具耐心分析。只要遵循上述原则，就能大幅减少内存泄漏问题，写出稳定、高效的Native代码。

如果觉得本文对你有帮助，欢迎点赞、收藏、转发，也欢迎在评论区留言讨论JNI内存管理中遇到的问题～