Java应用频繁FullGC分析

简介: ### 一、JVM的内存分布 #### 1.1 JVM内存分布概况 ![img](https://img.alicdn.com/tfs/TB1bhRnRFXXXXa2XVXXXXXXXXXX-510-401.png) * 堆内存划分为: Eden、Survivor 和 Tenured/Old 空间 ![img](https://img.alicdn.com/tfs/TB1EVh

一、JVM的内存分布

1.1 JVM内存分布概况

img

  • 堆内存划分为: Eden、Survivor 和 Tenured/Old 空间
    img

1.2 Minor GC、Major GC、Full GC

1.3 JVM垃圾回收算法

img

二、应用的GC日志配置

2.1 应用GC日志配置

JVM的GC日志的主要参数包括如下几个:

-XX:+PrintGC 输出GC日志
-verbose:gc 示输出虚拟机中GC的详细情况
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳(以基准时间的形式)
-XX:+PrintGCDateStamps 输出GC的时间戳(以日期的形式,如 2013-05-04T21:53:59.234+0800)
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:../logs/gc.log 日志文件的输出路径

-verbose:gc 中参数-verbose:gc 表示输出虚拟机中GC的详细情况.

使用后输出如下:

[Full GC 168K->97K(1984K), 0.0253873 secs]

解读如下:

  箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量,说明有168K-97K=71K的对象容量被回收,括号内的数据1984K为堆内存的总容量,收集所需要的时间是0.0253873秒(这个时间在每次执行的时候会有所不同)

2.2 线上应用配置实例

img

2.2 应用GC日志分析

2017-06-02T15:10:11.930+0800: 68752.147: [GC2017-06-02T15:10:11.930+0800: 68752.147: [ParNew: 1679677K->1878K(1887488K), 0.0176620 secs] 2204253K->526489K(6753536K), 0.0178770 secs] [Times: user=0.07 sys=0.00, real=0.02 secs]
2017-06-02T15:10:18.522+0800: 68758.739: [GC2017-06-02T15:10:18.522+0800: 68758.739: [ParNew: 1679702K->2122K(1887488K), 0.0184380 secs] 2204313K->526767K(6753536K), 0.0186610 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
2017-06-02T15:10:22.812+0800: 68763.029: [GC2017-06-02T15:10:22.812+0800: 68763.030: [ParNew: 1679946K->2104K(1887488K), 0.0166490 secs] 2204591K->526796K(6753536K), 0.0168640 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]
2017-06-02T15:10:29.874+0800: 68770.091: [GC2017-06-02T15:10:29.874+0800: 68770.091: [ParNew: 1679928K->1646K(1887488K), 0.0174360 secs] 2204620K->526439K(6753536K), 0.0176530 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]

取倒数第一条记录分析一下各个字段都代表了什么含义

2017-06-02T15:10:29.874+0800: 68770.091: (时间)[GC(Young GC)2017-06-02T15:10:29.874+0800: 68770.091: [ParNew()使用ParNew作为年轻代的垃圾回收): 1679928K(年轻代垃圾回收前的大小)->1646K年轻代垃圾回收以后的大小)(1887488K)(年轻代的总大小), 0.0174360 secs(回收时间)]] 2204620K(堆区垃圾回收前的大小)->526439K(堆区垃圾回收后的大小)(6753536K(堆区总大小), 0.0176530 secs(回收时间)] [Times: user=0.06Young GC用户耗时) sys=0.00(Young GC系统耗时), real=0.02 secsYoung GC实际耗时)]

我们再对数据做一个简单的分析:

从最后一条GC记录中我们可以看到 Young GC回收了 1679928-1646=1678282K的内存
Heap区通过这次回收总共减少了 2204620-526439=1678181K的内存。

1678282-1678181=101K说明通过该次Young GC有101K的内存被移动到了Old Gen

我们来验证一下

在最后一次Young GC的回收以前 Old Gen的大小为526796(倒数第二条堆内存)-2104=524692 <br/>
回收以后Old Gen的内存使用为526439-1646=524793
Old Gen在该次Young GC以后内存增加了524793-524692=10K 与预计的相符

三、常见GC查看工具

img

待续

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
15天前
|
移动开发 Java Android开发
构建高效Android应用:探究Kotlin与Java的性能差异
【4月更文挑战第3天】在移动开发领域,性能优化一直是开发者关注的焦点。随着Kotlin的兴起,其在Android开发中的地位逐渐上升,但关于其与Java在性能方面的对比,尚无明确共识。本文通过深入分析并结合实际测试数据,探讨了Kotlin与Java在Android平台上的性能表现,揭示了在不同场景下两者的差异及其对应用性能的潜在影响,为开发者在选择编程语言时提供参考依据。
|
16天前
|
缓存 算法 Java
Java内存管理与调优:释放应用潜能的关键
【4月更文挑战第2天】Java内存管理关乎性能与稳定性。理解JVM内存结构,如堆和栈,是优化基础。内存泄漏是常见问题,需谨慎管理对象生命周期,并使用工具如VisualVM检测。有效字符串处理、选择合适数据结构和算法能提升效率。垃圾回收自动回收内存,但策略调整影响性能,如选择不同类型的垃圾回收器。其他优化包括调整堆大小、使用对象池和缓存。掌握这些技巧,开发者能优化应用,提升系统性能。
|
15天前
|
Java
深入理解Java并发编程:线程池的应用与优化
【4月更文挑战第3天】 在Java并发编程中,线程池是一种重要的资源管理工具,它能有效地控制和管理线程的数量,提高系统性能。本文将深入探讨Java线程池的工作原理、应用场景以及优化策略,帮助读者更好地理解和应用线程池。
|
8天前
|
Java 调度
Java中常见锁的分类及概念分析
Java中常见锁的分类及概念分析
14 0
|
8天前
|
Java
Java中ReentrantLock中tryLock()方法加锁分析
Java中ReentrantLock中tryLock()方法加锁分析
10 0
|
22天前
|
Java 编译器 Android开发
构建高效Android应用:探究Kotlin与Java的性能差异
在开发高性能的Android应用时,选择合适的编程语言至关重要。近年来,Kotlin因其简洁性和功能性受到开发者的青睐,但其性能是否与传统的Java相比有所不足?本文通过对比分析Kotlin与Java在Android平台上的运行效率,揭示二者在编译速度、运行时性能及资源消耗方面的具体差异,并探讨在实际项目中如何做出最佳选择。
17 4
|
24天前
|
数据采集 分布式计算 大数据
Java语言在大数据处理中的应用
传统的大数据处理往往依赖于庞大的数据中心和高性能的服务器,然而随着大数据时代的到来,Java作为一种强大的编程语言正在被广泛应用于大数据处理领域。本文将探讨Java语言在大数据处理中的优势和应用,以及其在分布式计算、数据处理和系统集成等方面的重要作用。
|
24天前
|
人工智能 监控 算法
java智慧城管源码 AI视频智能分析 可直接上项目
Java智慧城管源码实现AI视频智能分析,适用于直接部署项目。系统运用互联网、大数据、云计算和AI提升城市管理水平,采用“一级监督、二级指挥、四级联动”模式。功能涵盖AI智能检测(如占道广告、垃圾处理等)、执法办案、视频分析、统计分析及队伍管理等多个模块,利用深度学习优化城市管理自动化和智能化,提供决策支持。
142 4
java智慧城管源码 AI视频智能分析 可直接上项目
|
6天前
|
Java
探秘jstack:解决Java应用线程问题的利器
探秘jstack:解决Java应用线程问题的利器
14 1
探秘jstack:解决Java应用线程问题的利器
|
8天前
|
Java
Java中关于ConditionObject的分析
Java中关于ConditionObject的分析
17 3