GC之详解CMS收集过程和日志分析

2016-08-23   关于GC的算法和垃圾收集器的种类就暂且不说了,网上有大把的资料供参考

话题引入

让我们先简单的看下整个堆年轻代和年老代的垃圾收集器组合(以下配合java8完美支持,其他版本可能稍有不同),其中标红线的则是我们今天要着重讲的内容:

ParNew and CMS

"Concurrent Mark and Sweep" 是CMS的全称,官方给予的名称是:“Mostly Concurrent Mark and Sweep Garbage Collector”;

年轻代:采用 stop-the-world mark-copy 算法;

年老代:采用 Mostly Concurrent mark-sweep 算法;

设计目标:年老代收集的时候避免长时间的暂停;

能够达成该目标主要因为以下两个原因:

1  它不会花时间整理压缩年老代,而是维护了一个叫做 free-lists 的数据结构,该数据结构用来管理那些回收再利用的内存空间;

2  mark-sweep分为多个阶段,其中一大部分阶段GC的工作是和Application threads的工作同时进行的(当然,gc线程会和用户线程竞争CPU的时间),默认的GC的工作线程为你服务器物理CPU核数的1/4;

补充:当你的服务器是多核同时你的目标是低延时,那该GC的搭配则是你的不二选择。

日志

GC日志初体验

首先对整个GC日志有一个大概的认知

2016-08-23T02:23:07.219-0200: 64.322: [GC (Allocation Failure) 64.322: [ParNew: 613404K->68068K(613440K), 0.1020465 secs] 10885349K->10880154K(12514816K), 0.1021309 secs] [Times: user=0.78 sys=0.01, real=0.11 secs]

2016-08-23T02:23:07.321-0200: 64.425: [GC (CMS Initial Mark) [1 CMS-initial-mark: 10812086K(11901376K)] 10887844K(12514816K), 0.0001997 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2016-08-23T02:23:07.321-0200: 64.425: [CMS-concurrent-mark-start]
2016-08-23T02:23:07.357-0200: 64.460: [CMS-concurrent-mark: 0.035/0.035 secs] [Times: user=0.07 sys=0.00, real=0.03 secs]
2016-08-23T02:23:07.357-0200: 64.460: [CMS-concurrent-preclean-start]
2016-08-23T02:23:07.373-0200: 64.476: [CMS-concurrent-preclean: 0.016/0.016 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
2016-08-23T02:23:07.373-0200: 64.476: [CMS-concurrent-abortable-preclean-start]
2016-08-23T02:23:08.446-0200: 65.550: [CMS-concurrent-abortable-preclean: 0.167/1.074 secs] [Times: user=0.20 sys=0.00, real=1.07 secs]
2016-08-23T02:23:08.447-0200: 65.550: [GC (CMS Final Remark) [YG occupancy: 387920 K (613440 K)]65.550: [Rescan (parallel) , 0.0085125 secs]65.559: [weak refs processing, 0.0000243 secs]65.559: [class unloading, 0.0013120 secs]65.560: [scrub symbol table, 0.0008345 secs]65.561: [scrub string table, 0.0001759 secs][1 CMS-remark: 10812086K(11901376K)] 11200006K(12514816K), 0.0110730 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2016-08-23T02:23:08.458-0200: 65.561: [CMS-concurrent-sweep-start]
2016-08-23T02:23:08.485-0200: 65.588: [CMS-concurrent-sweep: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2016-08-23T02:23:08.485-0200: 65.589: [CMS-concurrent-reset-start]
2016-08-23T02:23:08.497-0200: 65.601: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

Minor GC

2016-08-23T02:23:07.219-02001: 64.3222:[GC3(Allocation Failure4) 64.322: [ParNew5: 613404K->68068K6(613440K)7, 0.1020465 secs8] 10885349K->10880154K9(12514816K)10, 0.1021309 secs11][Times: user=0.78 sys=0.01, real=0.11 secs]12

Full/Major GC

参考资料

https://plumbr.eu/handbook/garbage-collection-algorithms-implementations#concurrent-mark-and-sweep

时间: 2024-10-13 10:47:36

GC之详解CMS收集过程和日志分析的相关文章

Android学习Scroller(五)——详解Scroller调用过程以及View的重绘

MainActivity如下: package cc.ww; import android.os.Bundle; import android.widget.ImageView; import android.widget.ImageView.ScaleType; import android.widget.RelativeLayout; import android.widget.RelativeLayout.LayoutParams; import android.app.Activity;

TOMCAT原理详解及请求过程(转)

https://www.cnblogs.com/hggen/p/6264475.html TOMCAT原理详解及请求过程 Tomcat: Tomcat是一个JSP/Servlet容器.其作为Servlet容器,有三种工作模式:独立的Servlet容器.进程内的Servlet容器和进程外的Servlet容器. Tomcat目录: tomcat |---bin:存放启动和关闭tomcat脚本 |---conf:存放不同的配置文件(server.xml和web.xml): |---doc:存放Tomc

详解CMS垃圾回收机制

原创不易,未经允许,不得转载~~~ 什么是CMS? Concurrent Mark Sweep. 看名字就知道,CMS是一款并发.使用标记-清除算法的gc. CMS是针对老年代进行回收的GC. CMS有什么用? CMS以获取最小停顿时间为目的. 在一些对响应时间有很高要求的应用或网站中,用户程序不能有长时间的停顿,CMS 可以用于此场景. CMS如何执行?  总体来说CMS的执行过程可以分为以下几个阶段: 3.1 初始标记(STW) 3.2 并发标记 3.3 并发预清理 3.4 重标记(STW)

ASP.NET 运行时详解 揭开请求过程神秘面纱

对于ASP.NET开发,排在前五的话题离不开请求生命周期.像什么Cache.身份认证.Role管理.Routing映射,微软到底在请求过程中干了哪些隐秘的事,现在是时候揭晓了.抛开乌云见晴天,接下来就一步步揭开请求管道神秘面纱. 上篇回顾 在介绍本篇内容之前,让我们先回顾下上一篇<ASP.NET运行时详解 集成模式和经典模式>的主要内容.在上一篇随笔中,我们提到ASP.NET运行时通过Application的InitInternal方法初始化运行管道.ASP.NET运行时提供了两种初始化管道模

JVM快速调优手册之五: ParNew收集器+CMS收集器的产品案例分析(响应时间优先)

服务器 双核,4个cores; 16G memory [[email protected] ~]# cat /proc/cpuinfo | grep "cpu cores" cpu cores : 2 cpu cores : 2 公式简述 响应时间优先的并发收集器,主要是保证系统的响应时间,减少垃圾收集时的停顿时间.适用于应用服务器.电信领域等. ParNew收集器 ParNew收集器是Serial收集器的多线程版本,许多运行在Server模式下的虚拟机中首选的新生代收集器,除Seri

Java虚拟机(JVM)与垃圾回收机制(GC)的详解

一.JVM结构 根据<java虚拟机规范>规定,JVM的基本结构一般如下图所示: 从左图可知,JVM主要包括四个部分: 1.类加载器(ClassLoader):在JVM启动时或者在类运行时将需要的class加载到JVM中.(右图表示了从java源文件到JVM的整个过程,可配合理解. 关于类的加载机制,可以参考http://blog.csdn.net/tonytfjing/article/details/47212291) 2.执行引擎:负责执行class文件中包含的字节码指令(执行引擎的工作机

TOMCAT原理详解及请求过程

Tomcat: Tomcat是一个JSP/Servlet容器.其作为Servlet容器,有三种工作模式:独立的Servlet容器.进程内的Servlet容器和进程外的Servlet容器. Tomcat目录: tomcat |---bin:存放启动和关闭tomcat脚本 |---conf:存放不同的配置文件(server.xml和web.xml): |---doc:存放Tomcat文档: |---lib/japser/common:存放Tomcat运行需要的库文件(JARS): |---logs:

mdadm命令详解及实验过程

一.概念 mdadm是multiple devices admin的简称,它是Linux下的一款标准的软件 RAID 管理工具,作者是Neil Brown 二.特点 mdadm能够诊断.监控和收集详细的阵列信息          mdadm是一个单独集成化的程序而不是一些分散程序的集合,因此对不同RAID管理命令有共通的语法          mdadm能够执行几乎所有的功能而不需要配置文件(也没有默认的配置文件) 三.作用 (引用) 在linux系统中目前以MD(Multiple Device

TCP/IP 协议详解和运作过程

一.TCP/IP协议族 TCP/IP协议族体系结构及主要协议.png 1.数据链路层 ARP协议和RARP协议,它们实现了IP地址和机器物理地址之间的相互转化 ARP协议(Address Resolve Protocol,地址解析协议) RARP协议(Reverse Address Resolve Protocol,逆地址解析协议) 作用:网络层是用IP地址寻址一台机器,而数据链路层是用物理地址寻址一台机器,因此网络层必须先将目标机器的IP地址转化成其物理地址,这就是ARP协议的用途.RARP协