在本地函数中会使用Java服务,这些服务都可以通过调用JNIEnv中封装的函数获取。我们在本地函数中可以访问所传入的引用类型参数,也可以通过JNI函数创建新的 Java 对象。这些 Java 对象显然也会受到GC的影响。所以我们需要通过JNI 的局部引用(Local Reference)和全局引用(Global Reference)来保证不让GC回收这些本地函数中可能引用到的 Java 对象。
无论是局部引用还是全局引用,其实都是通过句柄进行引用。其中,局部引用所对应的句柄有两种存储方式,一是在本地方法栈帧中,主要用于存放 C 函数所接收的来自 Java 层面的引用类型参数;另一种则是线程私有的句柄块,主要用于存放本地函数运行过程中创建的局部引用(实际是通过JNI函数来完成来这些操作)。无论是传入的引用类型参数,还是通过JNI函数(除NewGlobalRef
及NewWeakGlobalRef
之外)返回的引用类型对象,都属于局部引用。
关于句柄我们不应该陌生,在《深入剖析Java虚拟机:源码剖析与实例详解(基础卷)》一书中详细介绍过,Java栈在引用Java堆中的对象时会通过句柄的方式来引用,句柄指的是内存中 Java 对象的指针的指针。同时也介绍了HandleMark、HandleArea与Chunk这几个类的用法,它是为解决JVM内部的本地代码引用情况。当发生垃圾回收时,如果 Java 对象被移动了,那么句柄指向的指针值也将发生变动,但句柄本身保持不变。
HotSpot VM的JNI句柄是放在若干不同的区域里的,但不会放在GC堆中。传递参数用的句柄直接在栈上;局部句柄放在每个Java线程中的JNIHandleBlock里;全局句柄放在HotSpot VM全局的JNIHandleBlock里。
JNIHandles类的定义如下:
源代码位置:openjdk/hotspot/src/share/vm/runtime/jniHandles.hpp class JNIHandles : AllStatic { private: // 保存全局引用的JNIHandleBlock链表的头元素 static JNIHandleBlock* _global_handles; // 保存全局弱引用的JNIHandleBlock链表的头元素 static JNIHandleBlock* _weak_global_handles; static oop _deleted_handle; ... }
调用JNIHandles类的initialize()函数初始化如上的属性,如下:
void JNIHandles::initialize() { _global_handles = JNIHandleBlock::allocate_block(); _weak_global_handles = JNIHandleBlock::allocate_block(); // 宏扩展为如下的形式: // Thread* __the_thread__ = 0; // ExceptionMark __em(__the_thread__); EXCEPTION_MARK; Klass* k = SystemDictionary::Object_klass(); _deleted_handle = InstanceKlass::cast(k)->allocate_instance(CATCH); }
HotSpot VM会在启动时调用init_globals()函数初始化全局模块,init_globals()函数会间接调用到JNIHandles::initialize()函数,在这个函数中对全局的变量分配对应的JNIHandleBlock块。所以说,全局对象的句柄存储在JNIHandleBlock中。
JNIHandle分为两种,全局和局部对象引用,大部分的对象引用属于局部对象引用,最终还是调用了JNIHandleBlock来管理,因为JNIHandle没有设计一个JNIHandleMark的机制,所以在创建局部对象引用时需要明确调用JNIHandles::mark_local()函数,在回收时也需要明确调用JNIHandles::destroy_local()函数。
在线程中定义的、与局部引用对象相关的变量如下:
// 保存活跃的JNIHandleBlock块,块中存储的句柄对象也是活跃的 JNIHandleBlock* _active_handles; // 保存空闲JNIHandleBlock块,在必要时进行重用 JNIHandleBlock* _free_handle_block; HandleMark* _last_handle_mark;
无论是全局还是局部对象引用,其句柄都存储在JNIHandleBlock块中。当需要分配一个新的块时,调用JNIHandleBlock::allocate_block()函数;当不需要块时,调用JNIHandleBlock::release_block()来释放JNIHandleBlock块。其中分配新块和释放块的操作的最典型应用就是在JavaCallWrapper类的构造函数和析构函数中,这个JavaCallWrapper我们在之前接触过,就是在介绍HotSpot VM调用Java主类的main()方法时,会调用到JavaCalls::call_helper()函数,这个函数中有如下调用:
{ // 使用JavaCallWrapper保存相关信息 JavaCallWrapper link(method, receiver, result, CHECK); { HandleMark hm(thread); StubRoutines::call_stub()( (address)&link, result_val_address, result_type, method(), entry_point, args->parameters(), args->size_of_parameters(), CHECK ); result = link.result(); if (oop_result_flag) { thread->set_vm_result((oop) result->get_jobject()); } } } // Exit JavaCallWrapper (can block - potential return oop must be preserved)
这个link会从C/C++函数调用到Java方法时,存储到栈上,如下图所示。
其中的call wrapper就是保存的link值。
其实任何从C/C++调用到Java方法时都会在C/C++的栈帧中保存call wrapper,其中保存的信息非常重要,因为寄生在C/C++栈中的C/C++函数和Java方法对应的栈帧混合在一起,我们有时候要遍历C/C++栈帧,有时候需要遍历Java栈帧,当C/C++函数或Java函数执行完成后,还要能正确恢复调用者的栈帧信息并执行,这里我们不对这些内容做过多介绍,我们只关心C/C++函数使用的局部变量句柄即可。
如上图所示,在第1个C/C++栈帧(非当前执行的函数对应的C/C++栈帧)中可通过call wrapper找到JavaCallWrapper,然后通过JavaCallWrapper::_handles找到之前使用的JNIHandleBlock单链表,这样就能遍历到之前的C/C++栈帧中引用的堆中对象了。在第2个C/C++栈帧(当前正在执行的函数)中,通过Thread::_active_handles就能找到当前使用的JNIHandleBlock单链表,这样就能遍历引用的堆中对象了。对于Java栈引用的堆中对象来说,在《深入剖析Java虚拟机:源码剖析与实例详解(基础卷)》一书中介绍过,可通过HandleMark、HandleArea与Chunk等进行管理。
如果发生GC,那么需要遍历线程中的所有C/C++栈找到所有使用的JNIHandleBlock块,这样才能不产生漏标现象。
在JavaCallWrapper类中有如下属性定义:
JNIHandleBlock* _handles; // 实际保存JNI引用的内存块的指针
在JavaCallWrapper构造函数中有如下实现:
JavaCallWrapper::JavaCallWrapper( methodHandle callee_method, Handle receiver, JavaValue* result, TRAPS ) { JavaThread* thread = (JavaThread *)THREAD; // ... // 分配一个新的JNIHandleBlock JNIHandleBlock* new_handles = JNIHandleBlock::allocate_block(thread); // ... _thread = (JavaThread *)thread; // 保存当前线程的active_handles _handles = _thread->active_handles(); // 将新分配的JNIHandleBlock作为线程的active_handles _thread->set_active_handles(new_handles); }
无论是全局变量还是局部变量,都需要分配调用JNIHandleBlock::allocate_block()函数分配JNIHandleBlock。JNIHandleBlock类的定义如下:
class JNIHandleBlock : public CHeapObj<mtInternal> { private: enum SomeConstants { // 每个JNIHandleBlock中只能分配出32个句柄,所以只能存储32个oop block_size_in_oops = 32 }; // 句柄中保存的是oop,本地函数只能通过句柄来操作oop oop _handles[block_size_in_oops]; // 下一个没有使用的_handles中的slot,可以在这个slot上存储oop, // 然后返回此slot的地址给本地函数进行操作 int _top; // 通过_next字段将所有的JNIHandleBlock连接成单链表 JNIHandleBlock* _next; // 指向JNIHandleBlock链表中的最后一个块,这个块中的_handles正在负责为当前线程分配句柄区域 JNIHandleBlock* _last; JNIHandleBlock* _pop_frame_link; // 将空闲的句柄区域通过列表连接起来 oop* _free_list; // 将空闲的JNIHandleBlock通过如下字段连接成单链表,注意这是 // 一个静态变量,所以这个列表保存的JNIHandleBlock块可被任何线程重用 static JNIHandleBlock* _block_free_list; // ... }
其中各个属性的说明如下图所示。
注意,在线程中分配局部变量的句柄时,会从_last指向的JNIHandleBlock块的_handles数组中分配,如果top已经指向了_handles数组的下一个位置,则表示此数组已经无法分配出额外的句柄空间,需要调用JNIHandleBlock::allocate_block()函数分配一个新的JNIHandleBlock并连接到单链表中。
在JavaCallWrapper::JavaCallWrapper()构造函数中调用的JNIHandleBlock类的allocate_block()函数的实现如下:
JNIHandleBlock* JNIHandleBlock::allocate_block(Thread* thread) { JNIHandleBlock* block; // 如果当前线程的Thread::_free_handle_block中有空闲 // 的JNIHandleBlock,则从空闲的列表中获取即可 if (thread != NULL && thread->free_handle_block() != NULL) { block = thread->free_handle_block(); thread->set_free_handle_block(block->_next); } else { MutexLockerEx ml(JNIHandleBlockFreeList_lock,Mutex::_no_safepoint_check_flag); if (_block_free_list == NULL) { // 如果空闲列表中没有空闲的JNIHandleBlock,则分配一个新的JNIHandleBlock
// JNIHandleBlock的内存是通过调用os::malloc()函数进行分配的 block = new JNIHandleBlock(); _blocks_allocated++; if (ZapJNIHandleArea) block->zap(); } else { // 从JNIHandleBlock::_block_free_list中获取空闲块 block = _block_free_list; _block_free_list = _block_free_list->_next; } } block->_top = 0; block->_next = NULL; block->_pop_frame_link = NULL; return block; }
如上函数会在线程启动时调用,如在VMThread::run()、WatcherThread::run()和JavaThread::run()函数中调用,因为这几个函数都可能会执行native方法。当从线程的_free_handle_block和JNIHandleBlock::__block_free_list列表中都无法分配出空闲的JNIHandleBlock块时,就需要通过new关键字创建新的JNIHandleBlock了,JNIHandleBlock继承自CHeapObj<mtInternal>,所以会通过调用os::malloc()函数从本地内存中分配块的内存。
JavaCallWrapper::~JavaCallWrapper()析构函数的实现如下:
JavaCallWrapper::~JavaCallWrapper() { // 校验执行析构的是同一个Java线程 assert(_thread == JavaThread::current(), "must still be the same thread"); // 获取当前线程的active_handles JNIHandleBlock *_old_handles = _thread->active_handles(); // 恢复方法调用前的active_handles _thread->set_active_handles(_handles); // ... // 释放方法调用中新分配的JNIHandleBlock JNIHandleBlock::release_block(_old_handles, _thread); }
析构函数在Java方法返回到C/C++函数时调用,调用JNIHandleBlock::release_block()函数就相当于在释放本地函数栈帧中的句柄。所以我们也能看到,一旦从本地函数中返回到Java 方法中,那么局部引用将失效。也就是说,垃圾回收器在标记垃圾时不再考虑这些局部引用。这就意味着,我们不能缓存局部引用,以供另一个线程或下一次 native 方法调用时使用。对于这种应用场景,我们需要借助 JNI 函数NewGlobalRef
,将该局部引用转换为全局引用,以确保其指向的 Java 对象不会被垃圾回收。相应的,我们还可以通过 JNI 函数DeleteGlobalRef
来消除全局引用,以便回收被全局引用指向的 Java 对象。
调用的release_block()函数的实现如下:
void JNIHandleBlock::release_block(JNIHandleBlock* block, Thread* thread) { JNIHandleBlock* pop_frame_link = block->pop_frame_link(); if (thread != NULL ) { if (ZapJNIHandleArea) block->zap(); JNIHandleBlock* freelist = thread->free_handle_block(); block->_pop_frame_link = NULL; thread->set_free_handle_block(block); // 将新的空闲块添加到列表头部,其它的空闲块添加到列表尾部 if ( freelist != NULL ) { while ( block->_next != NULL ) block = block->_next; block->_next = freelist; } block = NULL; } if (block != NULL) { MutexLockerEx ml(JNIHandleBlockFreeList_lock,Mutex::_no_safepoint_check_flag); while (block != NULL) { if (ZapJNIHandleArea) block->zap(); // 如果函数传入的参数thread为NULL,那么会将block连接到静态变量 // _block_free_list列表中 JNIHandleBlock* next = block->_next; block->_next = _block_free_list; _block_free_list = block; block = next; } } // ... }
当线程不为NULL时,将空闲的JNIHandleBlock连接到Thread::_free_handle_block上,否则连接到JNIHandleBlock::_block_free_list上。一般来说,线程使用的JNIHandleBlock如果空闲了,都会连接到Thread::_free_handle_block上,但是当线程退出或者ClassLoaderData::_handles(用来对已经连接的对象的引用,之前介绍过)卸载时会归还给JNIHandleBlock::_block_free_list,这样其它的线程也能使用这些空闲的JNIHandleBlock,不像Thread::_free_handle_block一样,只能在本线程内重用。
公众号 深入剖析Java虚拟机HotSpot 已经更新虚拟机源代码剖析相关文章到60+,欢迎关注,如果有任何问题,可加作者微信mazhimazh,拉你入虚拟机群交流