调用DeleteLocalRef的正确姿势

本文讨论了在AndroidJNI开发中遇到的内存泄漏问题,重点在于理解JNI方法在不同线程环境下对jfloatArray等对象的正确管理,包括何时使用DetachCurrentThread和DeleteLocalRef以避免内存泄漏。

做安卓jni相关开发的总会在涉及到jni变量释放时怀疑人生,what? where? when? who? why? how? how much?

最近碰到一个比较奇怪的问题,有一个jni方法的耗时在随着调用次数的增加而上涨,但是没有明显的内存泄漏,经过我缜密分析之后,终于解决了深埋多年的疑惑。代码如下:

void HENativeUtils::vectorFloatToJArray(JNIEnv* env, const std::vector<float>& src, jobject obj, jfieldID fieldId)
{
    jfloatArray jArray = ( jfloatArray )env->GetObjectField(obj, fieldId);
    if (!jArray || env->GetArrayLength(jArray) != src.size())
    {
        jArray = env->NewFloatArray(src.size());
        env->SetObjectField(obj, fieldId, jArray);
    }
    jfloat* array = env->GetFloatArrayElements(jArray, nullptr);
    std::copy(src.begin(), src.end(), array);
    env->ReleaseFloatArrayElements(jArray, array, 0);
}

这个方法提供了对一个java对象obj中的float[]成员变量进行操作的功能,如果该对象为空或者size与需要被设置的对象size不一致则创建一个新的float[]并覆盖该对象。从上面代码可知我在使用完成后已经调用env->ReleaseFloatArrayElements将对应的jni数组释放,为什么还存在泄漏?甚至有动手能力比较强的小伙伴如果把这段代码复制到自己的jni代码中去调用,可能也不会有泄漏。

关于类

<think>我们正在讨论JNI中的引用管理问题。用户之前询问了GetObjectClass是否需要调用DeleteLocalRef,现在转向CallObjectMethod方法。 回顾:在JNI中,CallObjectMethod用于调用Java对象的方法并返回一个jobject(或子类型如jstring、jarray等)。这个返回值是一个局部引用(local reference)。 关键点: 1. 局部引用在本地方法返回时由JVM自动释放,但在以下两种情况需要手动管理: a) 在长时间运行的本地方法中(特别是循环体内)创建大量局部引用时,可能超出JVM的局部引用表容量(默认容量有限,通常为16-64,可通过JNI函数或启动参数调整)。 b) 当局部引用在同一个本地方法中不再需要,但方法还有很长的执行时间,为了及时释放资源避免占用过多内存(或引用表溢出),应提前删除。 2. 因此,对于CallObjectMethod返回的局部引用,处理原则与GetObjectClass相同: - 一般情况下,如果方法很快结束,可以不调用DeleteLocalRef。 - 在循环中或可能创建大量局部引用的地方,必须调用DeleteLocalRef来释放。 3. 示例: - 不需要手动删除的情况(方法简短): jobject result = env->CallObjectMethod(obj, methodID); // 使用result ... // 方法很快结束,无需删除 - 需要手动删除的情况(循环中): for (int i=0; i<1000; i++) { jobject result = env->CallObjectMethod(obj, methodID); // 使用result ... env->DeleteLocalRef(result); // 必须删除,否则循环1000次会创建1000个局部引用! } 4. 注意:如果CallObjectMethod返回的是基本类型(如CallIntMethod),则不需要删除,因为它们不是对象引用。 5. 引用用户提供的参考信息: 用户提供的引用[^2]和[^3]是关于Java类定义的示例,与引用管理无直接关系。但引用[^1]提到在Invocation API中FindClass的类加载器行为,这与当前问题无关。 结论: 和GetObjectClass一样,CallObjectMethod返回的局部引用在循环或可能创建大量引用的场景中必须调用DeleteLocalRef,否则在长时间运行的方法中可能造成引用表溢出。 生成相关问题: 1. JNI中哪些函数返回的引用需要手动释放? 2. 如何避免JNI局部引用表溢出? 3. 在JNI中,全局引用和局部引用的使用场景有何不同? </think>### JNI中`CallObjectMethod`的引用管理 在JNI中,**`CallObjectMethod`返回的jobject需要根据使用场景决定是否调用`DeleteLocalRef`**,核心原则如下: #### 1. **默认生命周期管理** - `CallObjectMethod`返回的是**局部引用(Local Reference)**,其生命周期默认与当前本地方法绑定 - 当本地方法返回Java层时,所有局部引用会自动释放,此时**无需手动调用`DeleteLocalRef`**[^1] ```cpp void nativeMethod(JNIEnv* env, jobject obj) { jmethodID mid = env->GetMethodID(...); jobject result = env->CallObjectMethod(obj, mid); // 局部引用 // 使用result... } // 方法结束时result自动释放 ``` #### 2. **必须手动删除的两种情况** - **场景1:循环内大量创建引用** 在循环中反复调用`CallObjectMethod`会累积局部引用,超出JVM默认容量(通常16-64个)导致崩溃: ```cpp for (int i=0; i<100; i++) { jobject result = env->CallObjectMethod(obj, mid); // 使用result... env->DeleteLocalRef(result); // 必须手动释放! } ``` - **场景2:长时间阻塞操作** 若方法包含阻塞调用(如I/O等待)或复杂计算,需及时释放避免内存泄漏: ```cpp jobject result = env->CallObjectMethod(obj, mid); processResult(result); env->DeleteLocalRef(result); // 显式释放 blockingIOOperation(); // 长时间阻塞 ``` #### 3. **特殊返回值处理** - **返回基本类型**:如`CallIntMethod()`等返回基本类型(非对象),无需释放 - **返回字符串**:`CallObjectMethod`返回`jstring`时,规则与普通jobject一致 ```cpp jstring jstr = (jstring)env->CallObjectMethod(obj, mid); const char* cstr = env->GetStringUTFChars(jstr, 0); // 使用cstr... env->ReleaseStringUTFChars(jstr, cstr); env->DeleteLocalRef(jstr); // 需手动释放jstring ``` #### 4. **最佳实践建议** | **场景** | **操作** | |---------------------------|------------------------------| | 方法简单且快速返回 | 无需`DeleteLocalRef` | | 循环/迭代操作 | **必须**在每次迭代后删除 | | 跨线程传递引用 | 转换为全局引用(非本问题范畴)| | 返回集合/自定义对象 | 同普通jobject处理[^2][^3] | > ⚠️ **关键结论**: > `CallObjectMethod`返回的引用**在循环或长时间操作中必须显式调用`DeleteLocalRef`**,否则会造成局部引用表溢出(`FatalError: local reference table overflow`)。 --- ### 相关问题 1. **JNI中哪些函数返回的引用必须调用`DeleteLocalRef`?** 2. **如何处理`CallObjectMethod`返回的集合对象(如ArrayList)的内存管理?** 3. **跨JNI层传递自定义Java对象(如Person类[^3])时如何避免内存泄漏?** [^1]: 局部引用在方法结束时自动释放 [^2]: 自定义对象在JNI中的处理原则 [^3]: 数据传输时的引用管理策略
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值