JVM 学习笔记

垃圾回收算法

1. 标记整理算法
2. 分代回收算法

垃圾收集器

Serial收集器

单线程的收集器，但它 的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作， 更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。Stop The World”

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之 外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX： PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对 象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相 当多的代码。

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行 的多线程收集器 Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点 是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到 一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总 消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚 拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整 理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式 下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge 收集器搭配使用[1]，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。 这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直 处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了 Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无 法与CMS收集器配合工作吗？）。由于老年代Serial Old收集器在服务端应用性能上的“拖 累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于 单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较 高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。 直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组 合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old 收集器

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集 器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重 视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常 符合这类应用的需求。 从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现。

执行步骤：

• 初始标记（CMS initial mark）
• 并发标记（CMS concurrent mark）
• 重新标记（CMS remark）
• 并发清除（CMS concurrent sweep）

其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是 标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC RootsTracing 的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变 动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远 比并发标记的时间短。 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起 工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。 CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停 顿，Sun公司的一些官方文档中也称之为并发低停顿收集器（Concurrent Low Pause Collector）。但是CMS还远达不到完美的程度，它有以下3个明显的缺点：

• CMS收集器对CPU资源非常敏感
• CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
• CMS是一款基于“标记—清除”算法实现的收集 器，就可能想到这意味着收集结束时会有大量 空间碎片产生。

G1收集器

特点如下

1. G1（Garbage-First）收集器是当今收集器技术发展的最前沿成果之一
2. G1是一款面向服务端应用的垃圾收集器
3. 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者 CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的 GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
4. 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其 他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已 经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
5. 空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实 现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这 两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种 特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一 次GC。
6. 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关 注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一 个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实 时Java（RTSJ）的垃圾收集器的特征了。

执行步骤：

• 初始标记（Initial Marking）
• 并发标记（Concurrent Marking）
• 最终标记（Final Marking）
• 筛选回收（Live Data Counting and Evacuation）

垃圾收集器参数总结

-XX：+PrintGCDetails

Minor GC和Full GC有什么不一样吗？

• 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝 生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
• 老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴 随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行 Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。

Sun JDK监控和故障处理工具- JDK的命令行工具

JDK的bin目录中命令行工具,这些命令行工具大多数是jdk/lib/tools.jar类库的一层薄包装而已，它们主要的功能代码是 在tools类库中实现

jps

JVM Process Status Tool,显示指定系统内所有的HotSpot 虚拟机进程

jstat

JVM Statistices Monitoring Tool,用于收集HotSpot虚拟机各方面的运行数据

jinfo

Configuration Info for Java ,显示虚拟机配置信息

jmap

Memory Map for Java , 生成虚拟机的内存转出快照（heapdump文件）

jhat

JVM Heap Dump Brower,用户分析headdump文件，它会建立一个HTTP/HTML服务器，让用户可以再浏览器上查看分析结果

jstack

Stack Trace for java,显示虚拟机的线程快照

JVM 学习笔记

原文：https://www.cnblogs.com/javarice/p/11815164.html