Android C++ 系列:JNI 引用管理
在 Native 代码中有时候会接收 Java 传入的引用类型参数,有时候也会通过 NewObject 方法来创建一个 Java 的引用类型变量。在编写 Native 代码时,要注意这个代表 Java 数据结构类型的引用在使用时会被 GC 回收的可能性。
我们知道,在 Java 中提供了四个级别的引用:强引用,软引用,弱引用和虚引用:
强应用:Java 中默认声明的就是强引用,比如:
Object obj = new Object(); //只要obj还指向Object对象,Object对象就不会被回收
,只要强引用存在,垃圾回收器将永远不会回收被引用的对象,哪怕内存不足时,JVM 也会直接抛出 OutOfMemoryError,不会去回收。如果想中断强引用与对象之间的联系,可以显示的将强引用赋值为 null,这样一来,JVM 就可以适时的回收对象了;软引用:软引用是用来描述一些非必需但仍有用的对象。在内存足够的时候,软引用对象不会被回收,只有在内存不足时,系统则会回收软引用对象,如果回收了软引用对象之后仍然没有足够的内存,才会抛出内存溢出异常。这种特性常常被用来实现缓存技术,比如网页缓存,图片缓存等。在 JDK1.2 之后,用 java.lang.ref.SoftReference 类来表示软引用。
弱引用:弱引用的引用强度比软引用要更弱一些,无论内存是否足够,只要 JVM 开始进行垃圾回收,那些被弱引用关联的对象都会被回收。在 JDK1.2 之后,用 java.lang.ref.WeakReference 来表示弱引用。
虚引用:虚引用是最弱的一种引用关系,如果一个对象仅持有虚引用,那么它就和没有任何引用一样,它随时可能会被回收,在 JDK1.2 之后,用 PhantomReference 类来表示,通过查看这个类的源码,发现它只有一个构造函数和一个 get() 方法,而且它的 get() 方法仅仅是返回一个 null,也就是说将永远无法通过虚引用来获取对象,虚引用必须要和 ReferenceQueue 引用队列一起使用。而引用队列可以与软引用、弱引用以及虚引用一起配合使用,当垃圾回收器准备回收一个对象时,如果发现它还有引用,那么就会在回收对象之前,把这个引用加入到与之关联的引用队列中去。程序可以通过判断引用队列中是否已经加入了引用,来判断被引用的对象是否将要被垃圾回收,这样就可以在对象被回收之前采取一些必要的措施。
Native 代码并不能直接通过引用来访问其内部的数据接口,必须要通过调用 JNI 接口来间接操作这些引用对象,就如在之前的系列文章中写的那样。并且 JNI 还提供了和 Java 相对应的引用类型,因此,我们就需要通过管理好这些引用来管理 Java 对象,避免在使用时被 GC 回收了。
引用简介
JNI 提供了三种引用类型:
局部引用
全局引用
弱全局引用
局部引用
局部引用是最常见的一种引用。绝大多数 JNI 函数创建的都是局部引用,比如:NewObject、FindClass、NewObjectArray 函数等等。
局部引用会阻止 GC 回收所引用的对象,同时,它不能在本地函数中跨函数传递,不能跨线程使用。 局部引用在 Native 函数返回后,所引用的对象会被 GC 自动回收,也可以通过 DeleteLocalRef 函数来手动回收。 JNI 调用时缓存字段和方法 ID,第一种方法采用的是使用时缓存,把字段 ID 通过 static 变量缓存起来。
如果把 FindClass 函数创建的局部引用也通过 static 变量缓存起来,那么在函数退出后,局部引用被自动释放了,static 静态变量中存储的就是一个被释放后的内存地址,成为了一个野指针,再次调用时就会引起程序崩溃了。
局部引用手动释放时机
局部引用除了自动释放外,还可以通过 DeleteLocalRef 函数手动释放,它一般存在于以下场景中:
当要创建大量的局部引用对象时,会造成 JNI 局部引用表的溢出。 假如有以下代码,则要特别注意,及时释放局部引用,防止溢出。
编写工具类时,即时释放局部引用。 在编写工具类时,很难知道被调用者具体会是谁,考虑到通用性,完成工具类的任务之后,就要及时释放相应的局部引用,防止被占着内存空间。
不需要返回的 Native 方法,即时释放局部引用。 如果 Native 方法不会返回,那么自动释放局部引用就失效了,这时候就必须要手动释放。比如,在某个一直等待的循环中,如果不及时释放局部引用,很快就会溢出了。
局部引用使用完了就删除,不必要等到函数结尾。 比如,通过局部引用创建了一个大对象,然后这个对象在函数中间就完成了任务,那么就可以早早地通过手动释放了,而不是等到函数的结尾才释放。
管理局部引用
Java 还提供了一些函数来管理局部引用的生命周期:
EnsureLocalCapacity
NewLocalRef
PushLocalFrame
PopLocalFrame
EnsureLocalCapacity 函数
JNI 的规范指出,JVM 要确保每个 Native 方法至少可以创建 16 个局部引用,经验表明,16 个局部引用已经足够平常的使用了。
但是,如果要与 JVM 的中对象进行复杂的交互计算,就需要创建更多的局部引用了,这时就需要使用 EnsureLocalCapacity 来确保可以创建指定数量的局部引用,如果创建成功返回 0 ,失败返回小于 0 ,如下代码示例:
引用确保可以创建了足够的局部引用数量,所以在循环处理局部引用时可以不进行删除了,但是显然会消耗更多的内存空间了。
PushLocalFrame 与 PopLocalFrame 函数对
PushLocalFrame 与 PopLocalFrame 是两个配套使用的函数对。
它们可以为局部引用创建一个指定数量内嵌的空间,在这个函数对之间的局部引用都会在这个空间内,直到释放后,所有的局部引用都会被释放掉,不用再担心每一个局部引用的释放问题了。
常见的使用场景就是在循环中:
使用 PushLocalFrame & PopLocalFrame 函数对,就可以在期间放心地处理局部引用,最后统一释放掉。
全局引用
全局引用和局部引用一样,也会阻止它所引用的对象被回收。但是它不会在方法返回时被自动释放,必须要通过手动释放才行,而且,全局引用可以跨方法、跨线程使用。
全局引用只能通过 NewGlobalRef 函数来创建,然后通过 DeleteGlobalRef 函数来手动释放。
还是上面提到的缓存字段的例子,现在就可以使用全局引用来缓存了。
弱全局引用
弱全局引用有点类似于 Java 中的弱引用,它所引用的对象可以被 GC 回收,并且它也可以跨方法、跨线程使用。
弱引用使用 NewWeakGlobalRef 方法创建,使用 DeleteWeakGlobalRef 方法释放。
在使用弱引用时,要先检查弱引用所指的类对象是否被 GC 给回收了。通过 isSameObject 方法进行检查。
isSameObject 方法可以用来比较两个引用类型是否相同,也可以用来比较引用是否为 NULL。同时,还可以用 isSameObject 来比较弱全局引用所引用的对象是否被 GC 了,返回 JNI_TRUE 则表示回收了,JNI_FALSE 则表示未被回收。
合理管理引用
总结一些关于引用管理方面的知识点,可以减少内存的使用和避免因为对象被引用不能释放而造成的内存浪费。
通常来说,Native 代码大体有两种情况:
直接实现 Java 层声明的 Native 函数的代码
用在任何场景下的工具函数
对于直接实现 Java 层声明的 Native 函数,不要造成全局引用和弱全局引用的累加,因为它们在函数返回后并不会自动释放。
对于工具类的 Native 函数,由于它的调用场合和次数是不确定的,所以要格外小心各种引用类型,避免造成累积而导致内存溢出,比如如下规则:
返回基础类型的 Native 工具函数,不能造成全局引用、弱全局引用、局部引用的积累。
返回引用类型的 Native 工具函数,除了要返回的引用之外,也不能造成任何的全局引用、弱全局引用、局部引用的积累。 同时,对于工具类的 Native 函数,使用缓存技术来保存一些全局引用也是能够提高效率的,正如 Android JNI 调用时缓存字段和方法 ID 文章中写到的一样。同时,在工具类中,如果返回的是引用类型,最好说明返回的引用是哪一种类型,如下代码所示:
因为不清楚返回的引用是什么类型,导致不知道调用哪种方式来删除这个引用类型。
JNI 中提供了 NewLocalRef 函数来保证工具类函数返回的总是一个局部引用类型,如下代码:
正如之前提到的,static 缓存是不能缓存一个局部引用的,而 cachedString 正是一个缓存的全局引用,但是通过 NewLocalRef 函数确保将返回的是一个局部引用,这样再使用后局部引用就会被自动释放掉了。
对于引用的管理,最好的方式还是使用 PushLocalFrame 与 PopLocalFrame 函数对,在这个函数对之间的局部引用就可以自动被 PushLocalFrame 和 PopLocalFrame 接管了。
总结
本文介绍了 JNI 层的引用类型和引用管理。JNI 层主要提供了对标 Java 强应用的局部引用和全局引用以及对标 Java 弱引用的全局弱引用。对于全局引用一定要切记用完时 Delete;局部引用要注意循环时找好实际实时删除避免浪费内存空间,如果一个方法内局部引用太多,试试 EnsureLocalCapacity ;一定要谨慎管理引用,避免内存泄露和野指针,空指针问题。
版权声明: 本文为 InfoQ 作者【轻口味】的原创文章。
原文链接:【http://xie.infoq.cn/article/4d334c959912580dfa80cf9a3】。文章转载请联系作者。
评论