-server -Xms40M -Xmx40M # 堆内存 40MB -Xmn20M # 新生代内存 20MB -XX:SurvivorRatio=8 # eden 区与 survive 区比例为 8:2 -verbose:gc # 在控制台输出 gc 日志 -XX:+PrintGCDetails # 输出 gc 日志详细信息 -XX:+PrintGCDateStamps # 打印日志时间 -XX:+UseConcMarkSweepGC # 启用 CMS 3.3 执行...
它有两个目标:一是标记老年代中所有的GC Roots;二是标记被年轻代中活着的对象引用的对象。 标记结果如下: 分析: 2016-08-23T11:23:07.321-0200:64.421:[GC (CMS Initial Mark2[1 CMS-initial-mark:10812086K3(11901376K)4]10887844K5(12514816K)6,0.0001997 secs] [Times: user=0.00 sys=0.00, real=0....
2 mark-sweep分为多个阶段,其中一大部分阶段GC的工作是和Application threads的工作同时进行的(当然,gc线程会和用户线程竞争CPU的时间),默认的GC的工作线程为你服务器物理CPU核数的1/4; 补充:当你的服务器是多核同时你的目标是低延时,那该GC的搭配则是你的不二选择。 日志 GC日志初体验 首先对整个GC日志有一...
首先会检查老年代的最大可用空间是否大于新生代所有对象的总和,如果成立可以保证直接可以进行gc。如果不成立,那么有一个担保失败的参数,如果该参数设置为允许,那么继续检查老年代最大可用连续空间是否大于历次晋升到老难带对象的平均大小,如果大于,那么直接进行minorgc,否则那么直接进行一次fullgc。当然这里也是有风险的,...
loggc:file将GC日志输出到文件中,后边的几个选项是开启滚动日志,也就是将日志按大小分割,实际上GC日志文件不是太大,不必要开启日志滚动。 -XX:+PrintGCCause 产生GC的原因,在JDK8已默认打开 -XX:+PrintPromotionFailure 如果有新生代对象晋升到老生代失败出现的FULL GC,打开这个日志可以看到更详细的信息 ...
这个CMS启动的内存使用阈值可以通过参数-XX:CMSInitiatiingOccupancyFranction来设置,默认为68%(这是网上查到的数据),不过这68%应该是JDK1.8之前版本的默认参数,因为上文中初始标记阶段的gc日志分析中显示老年代内存使用到了83%才开始的CMS垃圾收集。我通过在命令行输入java -XX:+PrintFlagsInitial命令查看到的本机...
美团技术团队:Java中9种常见的CMS GC问题分析与解决(下) 1.1 引言 自Sun 发布 Java 语言以来,开始使用 GC 技术来进行内存自动管理,避免了手动管理带来的悬挂指针(Dangling Pointer)问题,很大程度上提升了开发效率,从此 GC 技术也一举成名。GC 有着非常悠久的历史,1960 年有着“Lisp 之父”和“人工智能之父”之...
问题原因:看日志,系统接口超时的时候,系统出现了FullGC,这个时候stop-the-world了,也就停机了。分析gc的日志,发现有promotion failed,根据FullGC触发的条件,这个时候就会出现FullGC了。日志如下: 1 2 2013-11-27T03:00:53.638+0800:35333.562: [GC35333.562: [ParNew (promotion failed): 1877376K->1877376K(...
3.1.2 读懂 GC Cause拿到GC 日志,我们就可以简单分析 GC 情况了,通过一些工具,我们可以比较直观地看到 Cause 的分布情况,如下图就是使用 gceasy 绘制的图表:如上图所示,我们很清晰的就能知道是什么原因引起的 GC,以及每次的时间花费情况,但是要分析 GC 的问题,先要读懂 GC Cause,即 JVM 什么样的条件下选择...
知道了两个 STW 过程执行流程,我们分析解决就比较简单了,由于大部分问题都出在 Final Remark 过程,这里我们也拿这个场景来举例,主要步骤: 【方向】观察详细 GC 日志,找到出问题时 Final Remark 日志,分析下 Reference 处理和元数据处理 real 耗时是否正常,详细信息需要通过 -XX:+PrintReferenceGC 参数开启。基本在...