Jni 内存泄露(Failed adding to JNI pinned array ref table (1024 entries))

释放双眼,带上耳机,听听看~!
  • 问题重现
  • 错误代码
  • 解决办法
  • 原因

问题重现

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

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

错误代码

下面是出现错误的函数:


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

解决办法

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


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

原因

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

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

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

java 测试代码:


1
2
3
4
5
6
7
8
9
1    byte[] b = {0x00};
2
3    public void test() {
4        for (int i = 0; i < 20000; i++) {
5            System.out.println("aaaaaa::" + i);
6            EAJniUtils.test2(b);
7        }
8    }
9

JNI 代码:


1
2
3
4
5
6
7
8
9
1JNIEXPORT jbyteArray JNICALL xxx_utils_EAJniUtils_test2
2  (JNIEnv *env, jclass jobj, jbyteArray pkt){
3    jbyte *pBuffer = (*env)->GetByteArrayElements(env, pkt, 0);
4    int bufLen = (*env)->GetArrayLength(env,pkt);
5    jbyteArray array = (*env)->NewByteArray(env, bufLen);
6    (*env)->SetByteArrayRegion(env, array, 0, bufLen, pBuffer);
7    return array;
8  }
9

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

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

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

参考资料

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

给TA打赏
共{{data.count}}人
人已打赏
安全经验

职场中的那些话那些事

2021-9-24 20:41:29

安全经验

高并发解决方案限流技术-----使用RateLimiter实现令牌桶限流

2021-11-28 16:36:11

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索