Android JNI局部变量表溢出问题知识点汇总

1.概述

压测情况下，jni数据解析完成后传递给Java层时，局部变量表溢出导致crash。

2.日志

 A/art: art/runtime/indirect_reference_table.cc:132] JNI ERROR (app bug): local reference table overflow (max=512)
A/art: art/runtime/indirect_reference_table.cc:132] 512 of java.lang.String (512 unique instances)

3.知识点

1.jni局部变量表

1.什么是JNI局部引用表？

在JNI函数中使用Java的对象所产生的局部引用，存放在一张表中，这个表就称为局部引用表。在Android dalvik实现中，每个归属于dalvik管理的线程都有一个局部引用表，表的大小为512.

2.局部引用表爆掉的可能性

局部引用表回收的时机：当从Java层调用native函数的时候，当函数结束之后，会回收掉函数调用所产生的局部引用。但是，当从native线程（一个很显著的例子就是binder线程），通过JNI调用Java的函数所产生的局部引用，如果没有显示的delete，那么虚拟机就不会帮助我们清除。（？）

局部引用只有在创建它的本地方法返回前有效，本地方法返回到Java层之后，如果Java层没有对返回的局部引用使用的话，局部引用就会被JVM自动释放。

由此有两个点需要注意：

a.从java层调用native函数时候避免for循环占用局部引用——问题场景

b.当从native调用java函数的时候，一定要记得清除局部引用。因为虚拟机不会帮助我们清除。（存疑问？？）

3.释放局部引用

有两种方式，一个是本地方法执行完毕后JVM自动释放，另外一个是自己调用DeleteLocalRef手动释放。

4.问题解决

DeleteLocalRef手动释放局部引用

2.为什么Android8.0以上的手机没有出现同一问题

ART 在 Android 8.0 中提供了新的并发压缩式垃圾回收器 (GC)。该回收器会在每次执行 GC 时以及应用正在运行时对堆进行压缩，且仅在处理线程根时短暂停顿一次。该回收器具有以下优势：

• GC 始终会对堆进行压缩：堆的大小平均比 Android 7.0 中的小 32%。
• 得益于压缩，系统现可实现线程局部碰撞指针对象分配：分配速度比 Android 7.0 中的快 70%。
• H2 基准的停顿次数比 Android 7.0 GC 的少 85%。
• 停顿次数不再随堆的大小而变化，应用在使用较大的堆时也无需担心造成卡顿。
• GC 实现细节 - 读取屏障：
  • 读取屏障是在读取每个对象字段时所做的少量工作。
  • 它们在编译器中经过了优化，但可能会减慢某些用例的速度。

Android GC发展史

1. Dalvik GC : 第一阶段的GC，对应系统版本为Android KitKat之前。Dalvik GC使用了比较旧的"stop the world"设计，在垃圾回收期间会暂停虚拟机上的所有线程。

2. ART GC (Lollipop & Marshamllow) : GC发展历程中最大的一次改动，ART/Dalvik的开发团队重写了整个GC。这一阶段的GC也被叫做“分代GC”，因为对象会因存活时间不同而具有不同的“代”（或者叫年龄），另外还有其他方面的大的改进，比如分配内存的方式等。

3. ART GC(Nougat) : ART/Dalvik团队用汇编重写了整个内存分配的过程。

4. ART GC(Oreo) : 对第一版ART GC进行了优化，最明显的改进是把垃圾回收过程改为并发执行。这一代的GC也叫“并发复制垃圾回收器（Concurrent Copying Garbage Collector）”，同时在其他方面也做了不少优化。

4.参考文档

• jni局部引用 https://blog.csdn.net/xyang81/article/details/44657385
• GC进化史 https://www.cnblogs.com/cottony/p/12675072.html
• Android 8.0 GC并发压缩式垃圾回收器 https://source.android.google.cn/devices/tech/dalvik/improvements?hl=zh-cn