简书 占小狼
转载请注明原创出处，谢谢！
GC locker是什么？
概念太抽象，一两句话说不清...
先看看它被使用的场景，jni.cpp类中有一对函数，分别是jni_GetStringCritical和jni_ReleaseStringCritical，看名字也知道一个Get，一个Release，有点像锁的感觉。
当使用本地方法JNI函数访问JVM中的字符串或数组数据时，就需要用到上面的两个函数，如下是JNI读取JVM中的字符串实现：
实现步骤：
1、从JVM返回字符串指针
2、通过MALLOC_MIN4分配内存
3、如果内存不足，抛出OOM异常
4、拷贝字符串的值
5、执行ReleaseStringCritical
这里GetStringCritical和ReleaseStringCritical有何用？
这两个函数之间的代码必须在"critical region"（临界区）执行，即在调用GetStringCritical函数开始，到数据复制完成期间，必须保证原始数据不被修改，那应该如何防止其它线程的操作、或发生GC回收改字符串对象？
GetStringCritical函数实现：
可以发现，在返回字符串指针之前执行了GC_locker::lock_critical(thread);对临界区进行了加锁。
GC_locker::lock_critical(thread)方法实现：
每个线程都有一个参数_jni_active_critical，记录当前进入的临界区个数，如果_jni_active_critical > 0，说明该线程已经在临界区。
如果该线程还没进入临界区，且_need_gc标识为true，则执行jni_lock方法。_need_gc默认为false，只有在特殊情况下才会被设置为true。
如果现在有线程在临界区中，且_need_gc标识为true，则通过JNICritical_lock锁阻塞线程等待，实现如下：
假设现在线程A执行了enter_critical()，第一次进入临界区，这时不争气的JVM发生了YGC，而临界区的代码还没有执行完，怎么办？
我们先来看一段代码，触发年轻代的垃圾回收之前，会进行如下判断：
if (GC_locker::check_active_before_gc()) {
return; // GC is disabled (e.g. JNI GetXXXCritical operation)
}
check_active_before_gc()的实现：
如果发现有线程进入了临界区，本次的GC需要被disabled（丢弃），并设置_need_gc为true，这正好和前面的对应起来。
技巧：通过添加-XX+PrintJNIGCStalls可以打印出进入临界区的线程信息。
因为有线程进入了临界区，导致本次触发的YGC被丢弃了，那内存分配时空间不足的问题怎么解决？
线程执行完临界区的代码之后，执行ReleaseStringCritical方法，离开临界区：
GC_locker::unlock_critical的方法实现：
如果这个临界区是该线程最后一个临界区，且_need_gc为true，就是上次YGC丢弃时设置的true，则执行jni_unlock方法，实现如下：
实现有点复杂，总之就是把进入临界区时对一些字段进行+1操作，现在执行-1操作，如果发现已经没有任何线程在临界区了，说明该线程是最后一个离开临界区的线程。
如果当前没有其它地方持有CG locker的lock锁，则触发一次原因为GCCause::_gc_locker的GC，最后通过JNICritical_lock->notify_all()唤醒被阻塞在临界区外面的线程。
collect(GCCause::Cause cause)的方法实现：
先通过should_do_concurrent_full_gc判断是否可以使用并发GC，判断逻辑如下：
bool GenCollectedHeap::should_do_concurrent_full_gc(GCCause::Cause cause) {
return UseConcMarkSweepGC &&
((cause == GCCause::_gc_locker && GCLockerInvokesConcurrent) ||
(cause == GCCause::_java_lang_system_gc && ExplicitGCInvokesConcurrent));
}
前提是使用CMS垃圾算法
1、GCCause::_gc_locker 对应 -XX+GCLockerInvokesConcurrent
2、GCCause::_java_lang_system_gc 对应 -XX+ExplicitGCInvokesConcurrent
如果开启了-XX+GCLockerInvokesConcurrent，并发的实现如下：
VM_GenCollectFullConcurrent::doit()实现，这是GC开始的入口：
大吃一惊，居然有3情况，然后傻傻分不清楚：
1、只收集年轻代，如果你真的以为只收集年轻代，那就太年轻了，实现如下：
注意：如果_incremental_collection_failed标识为false，那么会执行一次真正意义的full gc，真的很惨！
2、触发一次CMS，如何触发？
设置_full_gc_requested参数为true，在周期性触发CMS的条件中，包含了对该标识的判断，如果为true，则会执行CMS
3、啥都不做
如果没有开启-XX+GCLockerInvokesConcurrent，则执行collect(cause, n_gens() - 1)
VM_GenCollectFull::doit()实现如下：
do_full_collection的逻辑和并发情况下只收集年轻代的逻辑差不多，正常情况下，也只会对年轻代收集，如果incremental_collection_will_fail返回true的话，就对年轻代和老年代都收集了。
这么分析下来，GC locker导致的GC问题，真是飘忽不定，头有点晕...我前面都在说什么？
