谈到JVM GC，我们不得不先了解一下会在GC当中用到的算法，这方面我觉得一下这篇博文总结得就很好了http://www.cnblogs.com/yulinfeng/p/7188609.html
一、垃圾回收算法
在Java堆上分配一个内存给实例对象时，此时在虚拟机栈上引用型变量就会存放这个实例对象的起始地址。
Object obj = new Object();
image.png
现在如果我们将变量赋值为null。
obj = null;
image.png
此时可以看到Java堆上的实例对象无法再次引用它，那么它就是被GC的对象，我们称之为对象“已死”。那虚拟机栈上的obj变量呢？虚拟机栈是线程独占的，也就是说随着线程初始而初始，消亡而消亡，当线程被销毁后，虚拟机栈上的内存自然会被回收，也就是说虚拟机栈上的这块内存空间不在虚拟机GC范围。下图展示了垃圾回收的内存范围：
image.png
判断对象是否“已死”
1.引用计数器算法
对象中添加一个引用计数器，如果引用计数器为0则表示没有其它地方在引用它。如果有一个地方引用就+1，引用失效时就-1。看似搞笑且简单的一个算法，实际上在大部分Java虚拟机中并没有采用这种算法，因为它会带来一个致命的问题——对象循环引用。对象A指向B，对象B反过来指向A，此时它们的引用计数器都不为0，但它们俩实际上已经没有意义因为没有任何地方指向它们。所以又引出了下面的算法。
2.对象是否“已死”算法——可达性分析算法
这种算法可以有效地避免对象循环引用的情况，整个对象实例以一个树呈现，根节点是一个称为“GC Roots”的对象，从这个对象开始向下搜索并作标记，遍历完这棵树过后，未被标记的对象就会判断“已死”，即为可被回收的对象。
image.png
垃圾回收
1.标记-清除算法
等待被回收对象的“标记”过程在上文已经提到过，如果在被标记后直接对对象进行清除，会带来另一个新的问题——内存碎片化。如果下次有比较大的对象实例需要在堆上分配较大的内存空间时，可能会出现无法找到足够的连续内存而不得不再次触发垃圾回收。
2.复制算法（Java堆中新生代的垃圾回收算法）
此GC算法实际上解决了标记-清除算法带来的“内存碎片化”问题。首先还是先标记处待回收内存和不用回收的内存，下一步将不用回收的内存复制到新的内存区域，这样旧的内存区域就可以全部回收，而新的内存区域则是连续的。它的缺点就是会损失掉部分系统内存，因为你总要腾出一部分内存用于复制。
Java堆中被分为了新生代和老年代，这样的划分是方便GC。Java堆中的新生代就使用了GC复制算法。在新生代中又分为了三个区域：Eden 空间、To Survivor空间、From Survivor空间。不妨将注意力回到这张图的左边新生代部分：
image.png
新的对象实例被创建的时候通常在Eden空间，发生在Eden空间上的GC称为Minor GC，当在新生代发生一次GC后，会将Eden和其中一个Survivor空间的内存复制到另外一个Survivor中，如果反复几次有对象一直存活，此时内存对象将会被移至老年代。可以看到新生代中Eden占了大部分，而两个Survivor实际上占了很小一部分。这是因为大部分的对象被创建过后很快就会被GC（这里也许运用了是二八原则）。
3.标记-压缩算法（或称为标记-整理算法，Java堆中老年代的垃圾回收算法）
对于新生代，大部分对象都不会存活，所以在新生代中使用复制算法较为高效，而对于老年代来讲，大部分对象可能会继续存活下去，如果此时还是利用复制算法，效率则会降低。标记-压缩算法首先还是“标记”，标记过后，将不用回收的内存对象压缩到内存一端，此时即可直接清除边界处的内存，这样就能避免复制算法带来的效率问题，同时也能避免内存碎片化的问题。老年代的垃圾回收称为“Major GC”。
4. 对比
这边我们具体看一下复制算法和标记-压缩算法的区别，以及年轻代和老年代选择它们的理由。
所谓的copying collector（或者叫scavenger）是空间换时间，而mark-compact则是时间换空间。
scavenger在工作的时候是不没有独立的“mark”与“copy”阶段的，而是合在一起做一个动作，就叫scavenge（或evacuate，或者就叫copy）。也就是说，每发现一个这次收集中尚未访问过的活对象就直接copy到新地方，同时设置forwarding pointer。
这样的工作方式就需要多一份空间。
mark-compact collector在工作的时候则需要分别的mark与compact阶段，mark阶段用来发现并标记所有活的对象，然后compact阶段才移动对象来达到compact的目的。如果compact方式是sliding compaction，则在mark之后就可以按顺序一个个对象“滑动”到空间的某一侧。因为已经先遍历了整个空间里的对象图，知道所有的活对象了，所以移动的时候就可以在同一个空间内而不需要多一份空间。
经典的做法叫做“LISP2” collector。可以去看看相关资料。
无论是scavenger还是mark-compact，一旦要并行化都会变复杂。要避免过多的锁竞争带来的性能瓶颈。所以很有可能会采用稍微浪费一点空间的“LAB”做法（local allocation buffer）。也可以用这个关键字搜些资料来读
二、HotSpot JVM
当我们提及GC，不能说Java的minor GC和major GC采用了某某方法，这样是不恰当的。最准确的说法是JVM的某某实现中，minor GC采用了某某方法。
具体的JVM实现实际上不止一种，有JRockit、J9等待，当然最有名当属HotSpot JVM。下面是HotSpot JVM的整体架构图。
image.png
现有的HotSpot垃圾回收器以及之间的关系和应用范围如下图所示：
image.png
其中G1 GC非常显眼的处于新生代和老年代之间，可以猜测这个G1 GC可同时运用在新生代和老年代，确实可以说G1是一个划时代新概念GC。
在介绍上面的垃圾回收器之前要先说明JVM虚拟机的Client模式和Server模式，Java所能做的事一是做客户端简单说就是GUI桌面应用程序，二是可以用作服务器端。两种模式Client模式启动快，启动后性能较差，Server模式启动慢，启动后性能较高。
1. Serial GC（-XX:+UseSerialGC，复制算法，新生代）
这是一个比较古老的垃圾收集器，我理解它为“简单粗暴”，简单粗暴的方法往往可以应对简单的环境，事实上Serial GC在Client模式下正是如此。它是一个串行的垃圾收集器，串行意味着就算是有多核处理器也不会有多个线程来并行回收，在串行的同时，其它的正常工作线程也要停止工作，称为“Stop the world”。这实际很好理解，你在清扫垃圾的时候，总不希望有人同时在丢垃圾吧。当然Serial GC在如今的HotSpot JVM中Server模式下已经几乎废弃。另外，它工作使用垃圾回收的“复制算法”工作在Java堆的新生代。
2. ParNew GC（-XX:+UseParNewGC，复制算法，新生代）
ParNew GC实际上是Serial GC的多线程版本。上面提到了Serial GC即使是多核CPU的环境下也是单线程进行垃圾内存的回收。此垃圾收集器侧可以做到多线程环境下进行垃圾内存的回收，这个多线程也仅仅是垃圾回收的多线程，而不是与用户线程并发执行。并且只有它能与CMS老年代的垃圾回收器配合使用，而CMS又恰恰是划时代意义的垃圾回收器，所以当JVM的老年代垃圾回收器是CMS的话，新生代的垃圾回收器通常是ParNew GC。
3. Parallel GC（-XX:+UseParallelGC，复制算法，新生代）
它有点和ParaNew GC类似，从名字上来看也是并行的多线程收集器。我们之前提到过，在进行GC的过程中要“Stop the world”，停顿时间越短当然越好，很多垃圾回收器（包括前两个）关注的就是如何提高停顿时间。而Parallel GC关注的则是吞吐量。它关注的是垃圾回收的整体耗时，如果垃圾回收所占用的整体耗时较短，则吞吐量高，CPU就能将越多的时间用于任务的执行上,（吞吐量 = 任务运行时间 / （任务运行时间 + 垃圾回收时间））。
4. Serial Old GC（-XX:+UseSerialOldGC，标记-压缩算法，老年代）
它是Serial GC的老年代版本，同样也是单线程，也能与Parallel GC配合使用作为它的老年代GC。
5. Parallel Old GC（-XX：+UseParallelOldGC，标记-压缩算法，老年代）
为了避免如果在新生代选择了Parallel GC而老年代则只有选择Serial Old GC的困境，出现了Parallel GC的老年代版本——Parallel Old GC。故如果在一些需要高吞吐量的常量利用Parallel GC和Parallel Old GC组合将会是一个很好的选择。
6. ☆Concurrent Mark Sweep(CMS) GC （-XX:+UseConcMarkSweepGC，标记-清除算法，老年代）
CMS GC几乎占据着JVM老年代垃圾收集器的半壁江山，它划时代的意义就是垃圾回收线程几乎能用户线程做到同时工作。“几乎”是因为它还是不能做到完全不需要“Stop the world”，只是它尽可能的缩短了停顿时间。
它的整个垃圾回收过程可分为以下4个步骤：
- 初始标记
- 并发标记
- 重新标记
- 并发清理
这4个步骤“初始标记”和“重新标记”需要进行短暂的“Stop the world”，并发标记的过程实际上就是和用户线程同时工作，也就是“一边丢垃圾，一边打扫”，这样就会带来一个问题，如果垃圾的产生是在标记后发生，那么这次垃圾就只有等到下次再回收。当然等到标记完了过后垃圾自然不会和用户线程产生冲突，而清理过程就能和用户线程同时处理了。对于此垃圾回收器有一个比较显著且不可避免的一个问题就是它所采用的是“标记-清除”算法，也就是说它不同会压缩存活的对象，这样就会带来内存空间碎片化的问题，如果出现需要分配一个连续的较大的内存空间则只能触发一次Full GC。在新生代的垃圾回收称为“Minor GC”，老年代的垃圾回收称为“Major GC”，而“Full GC”则是在整个堆上触发一次垃圾回收，可想而知代价会相当高，而且此时不得不暂停用户线程，只能针对具体使用场景通过调整CMS GC的参数对其进行调整优化。
7. ☆gabbage-First(G1) GC（-XX:+UseG1GC）
G1 GC较之前所有的垃圾回收器都不同，从开头的第二幅图就能看出，它涵盖了新生代和老年代，或者说仅仅是从逻辑上还保留“新生代”和“老年代”这种说法，实际上它已不存在内存分代，它在JDK6中仅仅是实验版，在JDK7u4过后才正式商用，对于此垃圾回收器的论文地址在：http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.6386&rep=rep1&type=pdf。
三、参数调整
-XX:Newratio: 设置Yong 和 Old的比例，比如值为2，则Old Generation是 Yong Generation的2倍，即Yong Generation占据内存的1/3
-XX:Newsize : 设置Yong Generation的初始值大小
-XX:Maxnewsize：设置Yong Generation的最大值大小
-XX:Surviorratio : 设置Eden和一个Suivior的比例，比如值为5，即Eden是To(S2)的比例是5，（From和To是一样大的），此时Eden占据Yong Generation的5/7
一般情况下，不允许-XX:Newratio值小于1，即Old要比Yong大。
网友评论