JNI 内存泄露(Failed adding to JNI pi

2018-06-13  本文已影响0人  maintel

问题重现

Failed adding to JNI pinned array ref table (1024 entries)

在开发蓝牙模块升级的时候, 由于要传送的升级文件较大,而 BLE 模块一次传输数据大小有限制,因此需要拆包,并需要频繁的通过JNI调用so库来组装报文,结果在低版本手机测试时遇到Failed adding to JNI pinned array ref table (1024 entries).

错误代码

下面是出现错误的函数:

JNIEXPORT jbyteArray JNICALL xxx_BleUtils_sendUpdatePkt(
        JNIEnv *env, jclass jobj, jbyteArray pkt, jint pkt_sn, jint pktLen, jint token
) {
    unsigned long outbuf[APPAPI_MAXSENDLEN / 4];
    unsigned char *pBuffer = (*env)->GetByteArrayElements(env, pkt, NULL);   //<==引起错误的地方
    int ret = ynLockSendPkt((uint16_t) token, (uint16_t) pkt_sn, pktLen,
                            pBuffer,
                            (char *) outbuf,
                            APPAPI_MAXSENDLEN);
    jbyteArray array = (*env)->NewByteArray(env, ret);
    (*env)->SetByteArrayRegion(env, array, 0, ret, outbuf);
    return array;
}

解决办法

查询官方文档也可以知道需要通过 ReleaseByteArrayElements来及时的释放资源:

(*env)->ReleaseByteArrayElements(env,pkt, pBuffer, 0); //pkt为java层传递过来的数组,pBuffer为指针

原因

其实 GetByteArrayElements 就类似于一个 new 的操作,而在 new 以后没有进行释放,而 C 并不会自动的去回收这些内容,所以频繁调用的情况下,引用次数不断增加,最终导致溢出。

后来查阅资料发现,上面的说法并不准确,首先 GetByteArrayElements 会创造出一个局部引用,JNI 会将创建的局部引用都存储在一个局部引用表中,如果这个表超过了最大容量限制,就会造成局部引用表溢出(比如本例中的 1024,在配置更低的手机中这个值可能更小),使程序崩溃。但是关于局部引用的释放问题,除了我们可以手动进行释放以外,函数被调用完成后,JVM 会自动释放函数中创建的所有局部引用

那么在上面的错误代码中,很显然方法执行结束后会自动释放 GetByteArrayElements 所创建的局部引用,而实验证明确实是这样:

java 测试代码:

    byte[] b = {0x00};

    public void test() {
        for (int i = 0; i < 20000; i++) {
            System.out.println("aaaaaa::" + i);
            EAJniUtils.test2(b);
        }
    }

JNI 代码:

JNIEXPORT jbyteArray JNICALL xxx_utils_EAJniUtils_test2
  (JNIEnv *env, jclass jobj, jbyteArray pkt){
    jbyte *pBuffer = (*env)->GetByteArrayElements(env, pkt, 0);
    int bufLen = (*env)->GetArrayLength(env,pkt);
    jbyteArray array = (*env)->NewByteArray(env, bufLen);
    (*env)->SetByteArrayRegion(env, array, 0, bufLen, pBuffer);
    return array;
  }

可以看到上面 test2 函数没有释放局部变量,而在 java 层对他进行了 20000 此循环调用,程序没有崩溃。(分别在魅族MX5(andorid 5.0)和一加3T(android 8.0)上进行的测试)

因此正确的原因应该是在原始代码的ynLockSendPkt函数中某个地方持有了 pBuffer 指针,导致它一直不被释放,所以我们后面手动的对它进行了释放。然而事实上问题到这里并没有完全被解决,因为是引入的第三方so所以也没办法看到具体原因,但是至少知道了问题出在什么地方。

以上是针对这个问题的个人看法,如果错误之处还请指正。

参考资料

在 JNI 编程中避免内存泄漏
JNI 局部引用

上一篇 下一篇

猜你喜欢

热点阅读