- 问题重现
- 错误代码
- 解决办法
- 原因
问题重现
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 局部引用