JVM之选择合适的垃圾收集器(CMS、G1)

JDK1.8为例:

1.JVM(Java Virtual Machine)是用于运行Java字节码的虚拟机,Java虚拟机包括一个类加载器子系统(Class Loader SubSystem)、运行时数据区(Runtime Data Area)、执行引擎和本地接口库(Native Interface Library)。本地接口库通过调用本地方法库(Native Method Library)与操作系统交互

运行时数据区是JVM参数调优的主要区域,有栈、程序计数器、堆、方法区-元空间、本地方法区,除程序计数器外其他区域都能进行垃圾收集
在这里插入图片描述

2.栈,它的生命周期与线程相同,线程私有,会使用操作系统原生内存,方法内的局部变量、对象引用等,使用的内存会随着方法执行完,线程销毁而被操作系统回收,栈内存默认1M,JVM通过 -Xss256k 命令设置大小,.栈设置的越大,允许的栈深度越深(如递归),如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常

3.本地方法栈是执行本地Native方法的相关的区域

4.程序计数器,保存代码执行位置,CPU下次再次执行时会从保存的位置处往下执行

5.方法区(元空间)用来存储类型的元数据信息,如:存储常量、静态变量、类信息、字段信息、方法名、方法代码、方法返回类型、常量池、JIT即时编译后的机器码等数据,在Java 8中,JVM将类的元数据放入本地内存(Native Memory)中,将常量池和类的静态变量放入Java堆中,这样JVM能够加载多少元数据信息就不再由JVM的最大可用内存(MaxPermSize)空间决定,而由操作系统的实际可用内存空间决定。

6.堆,JVM最大内存区域,参数调优主要是该区域,虚拟机把堆内存按 分代 模型划分 新生代、老年代

6.1.新生代中的对象大多数都符合“朝生夕灭”,使用Young GC 往往能快速清理掉大部分垃圾,留下来的会在Survivor1与Survivor2直接来回拷贝,并增加对象的年龄,达到年龄的和大对象一起放到老年代

6.2.老年代存放新生代中多次未被回收的对象和大对象, 使用 Full GC,(1.每次Young GC之前会进行一些判断,看看是否需要老年代先进行一下Full GC,2.Young GC之后,存活对象Survivor区放不下,老年代也放不下了,那么触发一次Full GC)如果收集后还无法申请到内存,则会抛出OutOffMemoryError

6.3.垃圾对象判定标准:1.引用计数法(2个类互相引用时无法释放),2.可达性分析算法(JVM使用此方法)

6.4.垃圾回收算法:堆内存中,JVM根据不同年代(或JDK版本),使用不同垃圾回收算法

  • 标记-清除:标记出垃圾对象,直接清楚掉,会有内存碎片
  • 复制:复制算法速度快,内存使用率不高,新生代回收后只保留少量存活对象,复制到Survivor区
  • 标记-整理:标记所有可达对象,完成后未被标记的对象将会被清理掉,然后将所有存活的对象压缩到内存的一端,标记-整理算法解决复制算法内存减半的高额代价问题

6.5.JVM垃圾回收算法

  • Serial垃圾收集器:单线程回收,进行 Young GC 和 Full GC时所有的应用线程都会被暂停,适用于32位小型机小内存环境,使用 -XX:+UseSerialGC
  • ParallelGC垃圾收集器:多线程回收,进行 Young GC 和 Full GC时所有的应用线程都会被暂停,JDK 7u4 及之后版本的默认该收集器,使用 -XX:+UseParallelGC -XX:+UseParallelOldGC显示指定(前者是收集新生代、后者是收集老年代)
  • CMS收集器:多线程回收,进行 Young GC时所有的应用线程都会被暂停,Full GC 时不再暂停应用线程,(使用多个后台线程收集老年代,付出的代价是更高的 CPU 使用),JDK8中CMS收集器默认是关闭的,使用 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 显示开启(前者是收集新生代、后者是收集老年代)
  • G1垃圾收集器:多线程回收,新生代的垃圾收集仍然采用暂停所有应用线程,它把整个堆分成了2048个小区域,独立使用这些区域的内存资源并且跟踪这些区域的垃圾收集进度,同时在后台维护一个优先级列表,在垃圾回收过程中根据系统允许的最长垃圾收集时间,优先回收垃圾最多的区域,JDK8中使用 -XX:+UseG1GC 开启
  • ZGC垃圾收集器 :JDK11中可使用的回收算法,在G1上进行了多项优化,使用XX:+UnlockExperimentalVMOptions -XX:+UseZGC ,可以参考腾讯开源的Tencent Kona JDK11

6.6.怎么选择垃圾回收算法,建议如下:

  • CPU核心少,内存1-2GB的,使用JDK默认的收集器即可
  • CPU核心大于4,内存4-6GB的,使用CMS垃圾收集器: ‐XX:+UseParNewGC -XX:+UseConcMarkSweepGC
  • CPU核心大于8,内存6-32GB的,使用G1垃圾收集器: ‐XX:+UseG1GC

与CPU有关是因为CMS、G1都会开启多个后台线程来收集垃圾,如果CPU核心不够,会造成CPU资源竞争、退化为单线程收集,性能更慢

6.7.JVM关键参数设置:

  • 默认启动:java -jar xxx.jar
  • 设置最大内存启动:java -jar -Xms2g -Xmx2g xxx.jar
  • 设置新生代启动:java -jar -Xms4g -Xmx4g -Xmn1g xxx.jar
  • 使用CMS收集器启动:java -jar -Xms6g -Xmx6g ‐XX:+UseParNewGC -XX:+UseConcMarkSweepGC xxx.jar
  • 使用G1收集器启动:java -jar -Xms16g -Xmx16g ‐XX:+UseG1GC -XX:MaxGCPauseMillis=120 -XX:ParallelGCThreads=8 xxx.jar
预期停顿时间是120ms:-XX:MaxGCPauseMillis=120
垃圾收集线程数:-XX:ParallelGCThreads= N ,N = 8 + ((N - 8) * 5 / 8), N代表CPU 的数目
如果服务器上有多个JVM实例,则需要调整ParallelGCThreads数量,过多的线程数会导致争抢CPU资源,ParallelGCThreads = min(CPU数量/JVM实例数, 8+((N-8)*5/8))

更多其他参数请自行查阅

7.直接内存,NIO相关类使用了直接内存,避免数据在内核与JVM之间来回拷贝

8.JVM工具

 1.jps 查看java进程
 2.jstat 虚拟机统计工具
  jstat -gcutil 2764
   S0    S1   E    O     M    YGC YGCT FGC FGCT   GCT
   0.00 0.00 6.20 41.42 47.20 16 0.105 3   0.472 0.577
   E表示新生代Eden区使用了6.2%的空间,2个S0、S1表示Survivor0、Survivor1,老年代(O,表示Old)和元空间(M)则分别使用了41.42%和47.20%的空间。
   程序运行以来共发生Minor GC(YGC,表示YoungGC)16次,总耗时0.105秒;发生Full GC(FGC,表示Full GC)3次,总耗时(FGCT,表示Full GCTime)为0.472秒;
   所有GC总耗时(GCT,表示GC Time)为0.577秒
   
 3.jinfo 实时查看和调整虚拟机各项参数, jinfo pid
 4.jmap 用于生成堆转储快照dump文件,jmap pid ,jmap -dump:format=b,file=zy.bin 30790
 5.jhat 分析jmap生成的快照文件,jhat zy.bin (一般使用VisualVM,不用此命令工具)
 6.jstack 用来查看线程停顿情况,jstack [option] pid ,jstack -l 30790,option有 -F(当正常请求不被响应时,强制输出线程堆栈),-l(除堆栈外还输出锁信息),-m(可以显示c/c++本地方法堆栈)
 7.VisualVM https://visualvm.github.io
 8.JVM参数调优可以应用到eclipse或Idea,如:
   -XX:+UseParNewGC
   -XX:+UseConcMarkSweepGC
   或单独使用-XX:+UseG1GC

 9.查看JVM运行时长:jcmd process_id VM.uptime
 10.查看JVM属性:jcmd process_id VM.system_properties 或 jinfo -sysprops process_id
 11.获取JVM版本:jcmd process_id VM.version
 12.查看JVM内存:jinfo -flags process_id
 13.查看每个线程栈信息:jstack process_id

以上是个人学习JVM知识和日常工作中的理解,如有错误,请包含与留言指正

猜你喜欢

转载自blog.csdn.net/zhuyu19911016520/article/details/133267236