JVM内存管理GC模型编写GC友好代码.ppt

分代算法(Generational GC) 永久代 也就是前面提到的方法区，并不属于堆(Heap).但是GC也会光顾这个区域 存放了每个Class的结构信息，包括常量池、字段描述、方法描述。与垃圾收集要收集的Java对象关系不大 GC的时机 在分代模型的基础上，GC从时机上分为两种: Scavenge GC和Full GC Scavenge GC (Minor GC) 触发时机：新对象生成时，Eden空间满了 理论上Eden区大多数对象会在Scavenge GC回收，复制算法的执行效率会很高, Scavenge GC时间比较短。 Full GC 对整个JVM进行整理，包括Young、Old和Perm 主要的触发时机: 1）Old满了 2）Perm满了 3) system.gc() 效率很低，尽量减少Full GC。 垃圾回收器(Garbage Collector) 分代模型：GC的战略；垃圾回收器：GC的战术(具体实现） Hotspot JVM提供多种垃圾回收器，我们需要根据具体应用的需要采用不同的回收器 没有万能的垃圾回收器，每种垃圾回收器都有自己的适用场景 垃圾回收器的“鱼与熊掌” GC时延 VS 吞吐量，二者不可兼得 GC时延（GC停顿） GC是Stop the world，停顿是避免不了(哪怕Java 7最新推出的G1收集器)。收集器只能尽量减少停顿。 为了良好的用户体验，我们希望停顿越短越好 吞吐量 吞吐量是运行应用代码所占CPU的比例 我们希望吞吐量越高越好 矛盾：为了减少停顿，需要投入更多的CPU资源去进行GC（比如多线程的并发GC），但是会降低吞吐量 出路：根据应用的场景选择合适的收集器 对于计算密集型应用，比如结算，计费，后台计算等，应该选择偏重吞吐量的收集器 对于时延敏感的应用，比如Web，游戏，通信等，应该选择偏重时延的收集器 主要的垃圾回收器 垃圾收集器的“并行”和“并发” 并行（Parallel）：指多个收集器的线程同时工作，但是用户线程处于等待状态 并发（Concurrent)：指收集器在工作的同时，可以允许用户线程工作。 并发不代表解决了GC停顿的问题，在关键的步骤还是要停顿。比如在收集器标记垃圾的时候。但在清除垃圾的时候，用户线程可以和GC线程并发执行。 Serial收集器 最早的收集器，单线程进行GC New和Old Generation都可以使用 在新生代，采用复制算法；在老生代，采用Mark-Compact算法 因为是单线程GC，没有多线程切换的额外开销，简单实用 Hotspot Client模式缺省的收集器 图片来自于《深入理解Java虚拟机-JVM高级特性与最佳实践》 ParNew收集器 Serial收集器在新生代的多线程版本 使用复制算法（因为针对新生代） 只有在多CPU的环境下，效率才会比Serial收集器高 可以通过-XX:ParallelGCThreads来控制GC线程数的多少。需要结合具体CPU的个数 Server模式下新生代的缺省收集器 Parallel Scavenge 类似于ParNew，针对新生代的多线程收集器 使用复制算法（因为针对新生代） 区别于ParNew，更注重吞吐量 可以通过定义参数来精确控制吞吐量 Parallel Old Parallel Scavenge在老生代的实现 在JVM 1.6才出现Parallel Old 采用多线程，Mark-Compact算法 更注重吞吐量 Parallel Scavenge + Parallel Old = 高吞吐量，但GC停顿可能不理想 图片来自于《深入理解Java虚拟机-JVM高级特性与最佳实践》 CMS收集器(Concurrent Mark-Swap) 追求最短停顿时间，非常适合Web应用 只针对老年区，一般结合ParNew使用 Concurrent，GC线程和用户线程并发工作（尽量并发） Mark-Swap 只有在多CPU环境下才有意义 使用-XX:+UseConcMarkSweepGC打开 CMS收集器(Concurrent Mark-Swap) CMS分为4个步骤: 初始标记，并发标记，重新标记，并发清除 初始标记和重新标记还是会出现GC停顿，用户线程需要等待 并发标记和并发清除不会出现GC停顿，用户线程可以继续工作。而这两步是整个GC最耗费时间的步骤。这样可以最大程度减少用户线程的停顿。 CMS收集器的缺点 CMS以牺牲CPU资源的代价来减少用户线程的停顿。当CPU个数少于4的时候，有可能对吞吐量影响非常大 CMS在并发清理的过程中，用户线程还在跑。这时候需要预留一部分空间给用户线程 CMS用Mark-Swap，会带来碎片问题。碎片过多的时候会容易频繁触发Full GC G1收集器(Ga