gcroot是怎么存储的
Ⅰ JVM垃圾回收的“三色标记算法”实现，内容太干
三色标记法是一种垃圾回收法，它可以让JVM不发生或仅短时间发生STW(Stop The World)，从而达到清除JVM内存垃圾的目的。JVM中的 CMS、G1垃圾回收器 所使用垃圾回收算法即为三色标记法。
三色标记法将对象的颜色分为了黑、灰、白，三种颜色。
白色 ：该对象没有被标记过。（对象垃圾）
灰色 ：该对象已经被标记过了，但该对象下的属性没有全被标记完。（GC需要从此对象中去寻找垃圾）
黑色 ：该对象已经被标记过了，且该对象下的属性也全部都被标记过了。（程序所需要的对象）
从我们main方法的根对象（JVM中称为GC Root）开始沿着他们的对象向下查找，用黑灰白的规则，标记出所有跟GC Root相连接的对象,扫描一遍结束后，一般需要进行一次短暂的STW(Stop The World)，再次进行扫描，此时因为黑色对象的属性都也已经被标记过了，所以只需找出灰色对象并顺着继续往下标记（且因为大部分的标记工作已经在第一次并发的时候发生了，所以灰色对象数量会很少，标记时间也会短很多）, 此时程序继续执行，GC线程扫描所有的内存，找出扫描之后依旧被标记为白色的对象（垃圾）,清除。
具体流程:
在JVM虚拟机中有两种常见垃圾回收器使用了该算法：CMS(Concurrent Mark Sweep)、G1(Garbage First) ，为了解决三色标记法对对象漏标问题各自有各自的法:
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求(但是实际由于某些问题,很少有使用CMS作为主要垃圾回收器的)。
从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于标记-清除算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤，包括：1）初始标记（CMS initial mark） 2）并发标记（CMS concurrent mark） 3）重新标记（CMS remark） 4）并发清除（CMS concurrent sweep）
其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GCRoots能直接关联到的对象，速度很快；
并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；
重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；
最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。由于在整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
在应对漏标问题时，CMS使用了增量更新(Increment Update)方法来做：
在一个未被标记的对象（白色对象）被重新引用后， 引用它的对象若为黑色则要变成灰色，在下次二次标记时让GC线程继续标记它的属性对象 。
但是就算是这样，其仍然是存在漏标的问题：
G1(Garbage First)物理内存不再分代，而是由一块一块的Region组成,但是逻辑分代仍然存在。G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。
Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。每个Region的大小可以通过参数-XX：G1HeapRegionSize设定，取值范围为1MB～32MB，且应为2的N次幂。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待，如图所示
Card Table（多种垃圾回收器均具备）
RSet(Remembered Set)
是辅助GC过程的一种结构，典型的空间换时间工具，和Card Table有些类似。
后面说到的CSet(Collection Set)也是辅助GC的，它记录了GC要收集的Region集合，集合里的Region可以是任意年代的。
在GC的时候，对于old->young和old->old的跨代对象引用，只要扫描对应的CSet中的RSet即可。逻辑上说每个Region都有一个RSet，RSet记录了其他Region中的对象引用本Region中对象的关系，属于points-into结构（谁引用了我的对象）。
而Card Table则是一种points-out（我引用了谁的对象）的结构，每个Card 覆盖一定范围的Heap（一般为512Bytes）。G1的RSet是在Card Table的基础上实现的：每个Region会记录下别的Region有指向自己的指针，并标记这些指针分别在哪些Card的范围内。这个RSet其实是一个Hash Table，Key是别的Region的起始地址，Value是一个集合，里面的元素是Card Table的Index。每个Region中都有一个RSet，记录其他Region到本Region的引用信息；使得垃圾回收器不需要扫描整个堆找到谁引用当前分区中的对象，只需要扫描RSet即可。
CSet(Collection Set)
一组可被回收的分区Region的集合, 是多个对象的集合内存区域。
新生代与老年代的比例
5% - 60%，一般不使用手工指定，因为这是G1预测停顿时间的基准,这地方简要说明一下,G1可以指定一个预期的停顿时间,然后G1会根据你设定的时间来动态调整年轻代的比例,例如时间长,就将年轻代比例调小,让YGC尽早行。
SATB(Snapshot At The Beginning), 在应对漏标问题时，G1使用了SATB方法来做,具体流程：
因为SATB在重新标记环节只需要去重新扫描那些被推到堆栈中的引用，并配合Rset来判断当前对象是否被引用来进行回收；
并且在最后G1并不会选择回收所有垃圾对象，而是根据Region的垃圾多少来判断与预估回收价值（指回收的垃圾与回收的STW时间的一个预估值），将一个或者多个Region放到CSet中，最后将这些Region中的存活对象压缩并复制到新的Region中，清空原来的Region。
会，当内存满了的时候就会进行Full GC；且JDK10之前的Full GC，为单线程的，所以使用G1需要避免Full GC的产生。
解决方案：
Ⅱ 对象和内存溢出怎么处理
1. 对象。
A．创建。首先检查指令的参数能不能在常量区找到类的符号引用，并检查这个类是否加载、解析和初始化过，如果没有就执行类的加载过程。其次是内存分配，类加载之后就知道要分配的内存大小，分配方法有两种，一种是指针碰撞，就是一块内存是使用过的，一块是未使用的，用一个指针分割，新分配的内存指针就向空闲的挪动，compact功能的虚拟机是用指针碰撞；另一种是空闲列表，就是一个列表记录空闲的内存块，不断更新列表，新分配的内存在列表中寻找一个合适大小的内存块，sweep功能的虚拟机是使用空闲列表。第三，在分配内存空间的时候，还要考虑并发性。有两个方法，一种是同步处理，如采用CAS和失败重试的方法；另外一种是把内存分配动作按照线程划分在不同的空间之中，每个线程在堆中预先分配一小块内存，本地线程分配缓冲TLAB，那个线程需要分配内存在那个TLAB上分配，只有TLAB用完了，才要同步锁定，重新分配。第四、对对象进行必要设置，比方说对象属于那个类，如何找到类的元数据信息和对象hashcode以及对象GC分代年龄等。
B．对象的内存布局。分为对象头、实例数据和对齐填充。对象头包括两部分，第一部分是存储对象自身信息，如hashcode，GC分代年龄，锁状态等；第二部分是类型指针，对象指向它的类的元数据的指针，虚拟机通过这个指针确定这是那个类的实例。
C．对象访问定位。两种方式，一种是句柄访问，句柄池有访问对象实例数据的指针和访问对象数据类型的指针。这个访问最大好处是reference是稳定的句柄池地址，对象改变都是改变句柄池里面的指针，而reference本身不动。另外一种就是直接指针，它有到对象类型数据的指针和实例数据。这个访问的好处是速度更快，节省了一次指针定位的开销。
2. 内存溢出OOM。
A．堆溢出。堆存放的是对象实例，只要不断创建对象，并且保证GC Root到对象有可大路径避免被垃圾回收清除掉对象，那么对象数量达到最大堆容量限制就会OOM。用内存映象分析工具，Eclipse Memory Analyzer分析一下。
B．虚拟机栈和本地方法栈溢出。分为两种，一种是如果线程请求的栈深度大于虚拟机所允许的最大深度，抛出StackOverFlowError异常；另一种是如果虚拟机在扩展栈时无法申请到足够内存空间，抛出OutOfMemoryError异常。可以减小最大堆和栈容量来获取更多的线程数量。
C．方法区和常量池溢出。会有额外提示 PermGen space。
D．本机直接内存溢出。这个Heap Dump文件看不到内存占用，但是如果有直接或简介使用了NIO，那有可能就是本机直接内存溢出了。
Ⅲ jvm如何gc，新生代，老年代，持久代，都存储哪些东西
虚拟机中共划分为三个代：年轻代（即新生代）、年老代和持久代。
持久代主要存放的是Java类的类信息，与垃圾收集要收集的Java对象关系不大。
年轻代和年老代的划分是对垃圾收集影响比较大的。
所有新生吵行亏成的对象首先都是放在年轻代的
年老代中存放的都是一些生命周期较长的对象。
持久代：用于存放静态文件，升神如今Java类、方法等带森。持久代对垃圾回收没有显着影响。
Ⅳ majorgc触发条件
Major GC通常是跟full GC是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是old gen。
最简单的分代式GC策略，按HotSpot VM的serial GC的实现来看，触发条件是：
young GC：当young gen中的eden区分配满的时候触发。注意young GC中有部分存活对象会晋升到old gen，所以young GC后old gen的占用量通常会有所升高。
full GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（因为HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，所以不需要事先触发一次单独的young GC）；或者，如果有perm gen的话，要在perm gen分配空间但已经没有足够空间时，也要触发一次full GC；或者System.gc()、heap mp带GC，默认也是触发full GC。
HotSpot VM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。
当然也总有例外。Parallel Scavenge（-XX:+UseParallelGC）框架下，默认是在要触发full GC前先执行一次young GC，并且两次GC之间能让应用程序稍微运行一小下，以期降低full GC的暂停时间（因为young GC会尽量清理了young gen的死对象，减少了full GC的工作量）。这是HotSpot VM里的奇葩嗯。
并发GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查old gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对old gen做并发收集。