【Java】JVM

初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”

并发标记阶段就是进行GC Roots Tracing的过程

重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短，仍然需要“Stop The World”

并发清除阶段会清除对象

要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了

将要被回收的区块集合。GC 时，在这些区块中的对象会被复制到其他区块中，总体上 Collection Sets 消耗的内存小于 1%。

每个区块都有一个 RSet，用于记录进入该区块的对象引用（如区块 A 中的对象引用了区块 B，区块 B 的 Rset 需要记录这个信息），它用于实现收集过程的并行化以及使得区块能进行独立收集。总体上 Remembered Sets 消耗的内存小于 5%。记录老年代该Region的即可（即old-young、old-old）

RSet究竟是怎么辅助GC的呢？

三色标记法：
白：对象没有被标记到，标记阶段结束后，会被当做垃圾回收掉。
灰：对象被标记了，但是它的field还没有被标记或标记完。
黑：对象被标记了，且它的所有field也被标记完了。

1. 在开始标记的时候生成一个快照图，标记存活对象
2. 在并发标记的时候所有被改变的对象入队（在write barrier里把所有旧的引用所指向的对象都变成非白的，即对于gray对象移除的目标引用对象标记为gray，对于black引用的新产生的对象标记为black）
3. 可能存在浮动垃圾，将在下次被收集

如何解决GC过程中新创建的对象？

如何解决GC过程中引用对象发生变化？

选定所有年轻代里的Region。通过控制年轻代的region个数，即年轻代内存大小，来控制young GC的时间开销。注意：依然是在新生代满了的时候，对整个新生代进行回收--整个新生代中的对象，要么被回收，要么晋升，至于新生代也采取分区机制的原因，则是因为这样跟老年代的策略统一，方便调整代的大小

选定所有年轻代里的Region，外加根据global concurrent marking统计得出收集收益高的若干老年代region。在用户指定的开销目标范围内尽可能选择收益高的老年代region。注意：Mixed GC不是full GC，它只能回收部分老年代的Region，如果mixed GC实在无法跟上程序分配内存的速度，导致老年代填满无法继续进行Mixed GC，就会使用serial old GC（full GC）来收集整个GC heap。所以我们可以知道，G1是不提供full GC的。

1. global concurrent marking

2. 拷贝存活对象

子主题

当Mixed GC跟不上创建对象的速度，将导致Serial Old进行Full GC

根类加载器

扩展类加载器

系统类加载器

用户自定义的类加载器

获取当前类的classLoader clazz.getClassLoader()

获取线程上下文的ClassLoader Thread.currentThread().getContextClassLoader()

获取系统的ClassLoader ClassLoader.getSystemClassLoader()

获取调用者的ClassLoader DriverManage.getCallerClassLoader()

在双亲委托模型下，类加载是由下至上的，即下层的类加载器会委托上层进行加载。但是对于SPI来说，有些接口是由Java核心库所提供的，
而Java核心库是由启动类加载器来加载的，而这些接口的实现却来自于不同的jar包（厂商提供），Java的启动类加载器是不会加载其他
来源的jar包，这样传统的双亲委托模型就无法满足SPI的要求。而通过给当前线程设置上下文类的加载器，就可以由设置的上下文类加载器来实现对于接口实现类的加载。