怎么查看服务器默认的垃圾收集器是哪个?生产上如何配置垃圾收集器的?谈谈你对垃圾收集器的理解?

怎么查看服务器默认的垃圾收集器:

E:\ideaProjects\suanfa>java -XX:+PrintCommandLineFlags -version
-XX:InitialHeapSize=132345856 -XX:MaxHeapSize=2117533696 -XX:+PrintCommandLineFlags -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseParallelGC
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)

-XX:+UseParallelGC 查看结果是 默认并行垃圾回收器

-XX:+UseSerialGC 配置使用串行垃圾回收器

JVM 默认的垃圾收集器有哪些:
UseSerialGC
UseParallelGC
UseConcMarkSweepGC
UseParNewGC
UsePapallelOldGC
UseG1GC

怎么查看服务器默认的垃圾收集器是哪个?生产上如何配置垃圾收集器的?谈谈你对垃圾收集器的理解?_第1张图片
上图中的young区的垃圾回收器 和 old取得垃圾回收器连线 表示,young区垃圾回收器和old垃圾回收器的默认组合

一些单词:
DefNew - - - Default New Generation
Tenured - - - Old
ParNew - - - Parallel New Generation
PSYoungGen - - - Parallel Scavenge
ParOldGen - - - Parallel Old Generation

JVM server / client 模式是什么意思?
32为windows,默认都是用Client的JVM模式;32位其他操作系统,2G内存同时有2个CPU以上用server模式,低于该配置还是用client模式
64位 只有server模式

C:\Users\wangteng>java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

垃圾回收器:

新生代:

串行GC(Serial / Serial Copying):
最古老、最稳定、效率高,没有线程交互的开销可以获得最高的单线程垃圾收集效率,是JVM在client模式下默认的新生代垃圾收集器
-XX:+UseSerialGC

Heap
 def new generation   total 39424K, used 1402K [0x0000000081c00000, 0x00000000846c0000, 0x00000000abd50000)
  eden space 35072K,   4% used [0x0000000081c00000, 0x0000000081d5ebb8, 0x0000000083e40000)
  from space 4352K,   0% used [0x0000000083e40000, 0x0000000083e40000, 0x0000000084280000)
  to   space 4352K,   0% used [0x0000000084280000, 0x0000000084280000, 0x00000000846c0000)
 tenured generation   total 87424K, used 1370K [0x00000000abd50000, 0x00000000b12b0000, 0x0000000100000000)
   the space 87424K,   1% used [0x00000000abd50000, 0x00000000abea6bb8, 0x00000000abea6c00, 0x00000000b12b0000)
 Metaspace       used 5304K, capacity 5440K, committed 5632K, reserved 1056768K
  class space    used 613K, capacity 659K, committed 768K, reserved 1048576K

并行GC(ParNew):
最常见的应用场景是配合老年代的CMS GC工作(见上图的parNew和CMS连线),是很多server模式下新生代的默认垃圾收集器
使用JVM参数:-XX:+UseParNewGC 启用,只影响新生代的收集,不影响老年代
开启上述参数后,会使用ParNew(young) + Serial Old 的收集器组合,新生代使用复制算法,老年代采用标记-整理算法
运行程序JVM会提示ParNew(young) + Serial Old将不再推荐使用
-XX:ParallelGCThreads 限制线程数量,默认开启和CPU数目相同的线程数

Heap
 par new generation   total 3072K, used 371K [0x00000000ff600000, 0x00000000ff950000, 0x00000000ff950000)
  eden space 2752K,  13% used [0x00000000ff600000, 0x00000000ff65cd10, 0x00000000ff8b0000)
  from space 320K,   0% used [0x00000000ff900000, 0x00000000ff900000, 0x00000000ff950000)
  to   space 320K,   0% used [0x00000000ff8b0000, 0x00000000ff8b0000, 0x00000000ff900000)
 tenured generation   total 6848K, used 1153K [0x00000000ff950000, 0x0000000100000000, 0x0000000100000000)
   the space 6848K,  16% used [0x00000000ff950000, 0x00000000ffa70758, 0x00000000ffa70800, 0x0000000100000000)
 Metaspace       used 5278K, capacity 5434K, committed 5632K, reserved 1056768K
  class space    used 611K, capacity 658K, committed 768K, reserved 1048576K
Java HotSpot(TM) 64-Bit Server VM warning: Using the ParNew young collector with the Serial old collector is deprecated and will likely be removed in a future release

并行回收GC(Parallel / Parallel Scavenge):
类似ParNew,也是一个新生代垃圾收集器,使用复制算法,并行多线程,俗称吞吐量优先收集器
并行收集器组合 Parallel Scavenge + Parallel Old
他关注的重点是:
可控制的吞吐量:=运行时间 / (运行时间+垃圾收集时间),高吞吐量意味着CPU高利用率,多用于在后台运算不需要太多交互的任务
自适应调节策略:这也是她和ParNew收集器的一个重要区别:虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间(-XX:MaxGCPauseMillis)或最大的吞吐量
激活参数:-XX:+UseParallelGC 或 -XX:+UseParallelOldGC(可互相激活)

Heap
 PSYoungGen      total 2048K, used 364K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 1024K, 35% used [0x00000000ffd00000,0x00000000ffd5b030,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
  to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
 ParOldGen       total 7168K, used 916K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 12% used [0x00000000ff600000,0x00000000ff6e5038,0x00000000ffd00000)
 Metaspace       used 5274K, capacity 5430K, committed 5632K, reserved 1056768K
  class space    used 611K, capacity 658K, committed 768K, reserved 1048576
老年代:

串行GC(Serial Old / Serial MSC):
是Serial收集器的老年代版本,单线程,标记整理算法。是Client模式下老年代的默认垃圾收集器
作用:1.5之前和Parllel Scavenge 收集器搭配使用;作为老年代CMS收集器的后备垃圾收集方案

并行GC(Parallel Old / Parallel MSC):
是Parallel Scavenge的老年代版本,使用多线程的标记-整理算法
在1.6之前,新生代使用Parallel Scavenge只能搭配老年代的Serial Old收集器,只能保证新生代的吞吐量优先,无法保证整体的吞吐量
Parallel Old正是为了老年代同样提供吞吐量优先的垃圾收集器,如果系统对吞吐量要求比较高,1.8之后可以优先考虑新生代Parallel Scavenge+ Parallel Old老年代的搭配策略

启用参数:-XX:+UseParallelOldGC 启用后也会激活新生代 Parallel Scavenge

并发标记清除GC(CMS):
是一种以获取最短回收停顿时间为目标的收集器,适合堆内存大、CPU核数多的服务器端应用,也是G1出现之前大型应用的首选收集器
并发收集低停顿,和用户线程一起执行

开启参数:-XX:UseConcMarkSweepGC,开启该参数后会自动将-XX:UseParNewGC激活,使用ParNew(young区) + CMS(old区) + Serial Old 的收集器组合(上面图上的连线也连到了这三个),Serial Old将作为CMS出错的后备收集器

CMS GC步骤:

  1. 初始标记:标记一下GC Roots能直接关联的对象,速度很快,仍然需要暂停所有的工作线程
  2. 并发标记:进行GC Roots跟踪的过程,和用户线程一起,不需要暂停工作线程标记全部对象
  3. 重新标记:为了修正在并发标记期间,因用户程序继续运行而导致标记产生变动的那一部分对象的记录,需要在那挺所有的工作线程
    由于并发标记期间,用户线程依然运行,因此正式清理前,再做修正
  4. 并发清除:清除GC Roots不可达对象,和用户线程一起工作,不需要暂停线程,基于标记结果,直接清理对象

耗时最长的并发标记和并发清除过程中,垃圾收集线程可以和用户线程一起工作

优点:并发收集 低停顿
缺点:并发执行,对CPU压力大;采用标记清除算法会导致大量碎片。
标记清除算法无法整理空间碎片,老年代会随着应用时长被逐步耗尽,最后几那个不得不通过担保机制对堆内存进行压缩。CMS也提供了参数-XX:+CMSFullGCsBeforeCompaction(默认0,即每次都进行内存整理)来指定多少次CMS收集之后,进行一次压缩的Full GC

如何选择垃圾收集器:
  • 单CPU或小内存,单机程序:-XX:+UseSerialGC
  • 多CPU,需要大吞吐量,如后台计算应用:-XX:+ParallelGC 或 -XX:+ParallelOldGC
  • 多CPU,追求低停顿时间,需要快速响应,如互联网应用: -XX:+UseConcMarkSweepGC

总结:

参数 新生代垃圾收集器 新生代算法 老年代垃圾收集器 老年代算法
-XX:+UseSerialGC SerialGC 复制 SerialOldGC 标整
-XX:+UseParNewGC ParNewGC 复制 SerialOldGC 标整
-XX:+UseParallelGC Parallel [Scavenge] GC 复制 ParallelOldGC 标整
-XX:+UseConcMarkSweepGC ParNewGC 复制 CMS + Serial Old GC 标清
-XX:+UseG1GC G1整体上采用标记整理算法 局部是通过复制算法,不会产生碎片

你可能感兴趣的:(#,JVM)