了解 GC Log （垃圾收集日志）并不是一件容易的事情，至少对于大多数技术人员而已。毕竟，对于这玩意，需要我们能够深入地了解 Java 虚拟机的工作原理以及对应用程序的内存使用情况的理解。在此篇文章中，我们将跳过应用程序的分析，因为它与应用程序的应用程序不同，并且需要对代码的知识。我们将讨论的是可以借助哪些工具使得我们能够读取和分析从 JVM 中获取的垃圾收集日志，以便正确定位问题。
在实际的业务场景中，基于不同的特性存在各种不同的 JVM 厂商及版本和多个垃圾收集器实现。可能，在绝大多数环境中可以遇到 Java 7、8、11甚者15等。当然，由于各种历史原因，一些传统企业或许仍然使用 Java 6。每个版本可能都可以运行不同的垃圾收集器 - 串行，并行，并发标记扫描，G1 甚至是即将流行的 ZGC 等。
那么，既然 GC Log 如此重要，它能够给我们回答哪些“硬核”的问题呢？基于通用型角度而言，主要涉及以下：
1、什么时候使用年轻代垃圾收集器？
2、什么时候使用老年代垃圾收集器？
3、回收了多少垃圾？
4、垃圾收集器运行多久了？
5、垃圾收集之前和之后的内存利用率是多少？
现在让我们看看一个 JVM 垃圾收集器日志中取出的示例，并分析每个片段，突出显示它的关键部分。下面我们将展示一个标准的基于 G1 垃圾收集日志示例，具体如下所示：
[2021-04-26T14:19:14.307+0000][info][gc,heap] Heap region size: 1M [2021-04-26T14:19:14.317+0000][info][gc ] Using G1 [2021-04-26T14:19:14.318+0000][info][gc,heap,coops] Heap address: 0x00000007e0000000, size: 512 MB, Compressed Oops mode: Zero based, Oop shift amou nt: 3 [2021-04-26T14:19:15.011+0000][info][gc,start ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) [2021-04-26T14:19:15.011+0000][info][gc,task ] GC(0) Using 4 workers of 4 for evacuation [2021-04-26T14:19:15.014+0000][info][gc,phases ] GC(0) Pre Evacuate Collection Set: 0.1ms [2021-04-26T14:19:15.014+0000][info][gc,phases ] GC(0) Evacuate Collection Set: 2.3ms [2021-04-26T14:19:15.014+0000][info][gc,phases ] GC(0) Post Evacuate Collection Set: 0.4ms [2021-04-26T14:19:15.015+0000][info][gc,phases ] GC(0) Other: 0.9ms [2021-04-26T14:19:15.015+0000][info][gc,heap ] GC(0) Eden regions: 25->0(306) [2021-04-26T14:19:15.015+0000][info][gc,heap ] GC(0) Survivor regions: 0->1(4) [2021-04-26T14:19:15.015+0000][info][gc,heap ] GC(0) Old regions: 0->0 [2021-04-26T14:19:15.015+0000][info][gc,heap ] GC(0) Humongous regions: 0->0 [2021-04-26T14:19:15.015+0000][info][gc,metaspace ] GC(0) Metaspace: 5775K->5775K(1056768K) [2021-04-26T14:19:15.015+0000][info][gc ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 25M->0M(512M) 3.965ms [2021-04-26T14:19:15.015+0000][info][gc,cpu ] GC(0) User=0.01s Sys=0.00s Real=0.00s [2021-04-26T14:19:17.216+0000][info][gc,start ] GC(1) Pause Young (Normal) (G1 Evacuation Pause) [2021-04-26T14:19:17.216+0000][info][gc,task ] GC(1) Using 4 workers of 4 for evacuation [2021-04-26T14:19:17.232+0000][info][gc,phases ] GC(1) Pre Evacuate Collection Set: 0.0ms [2021-04-26T14:19:17.233+0000][info][gc,phases ] GC(1) Evacuate Collection Set: 12.7ms [2021-04-26T14:19:17.233+0000][info][gc,phases ] GC(1) Post Evacuate Collection Set: 3.0ms [2021-04-26T14:19:17.233+0000][info][gc,phases ] GC(1) Other: 0.7ms [2021-04-26T14:19:17.233+0000][info][gc,heap ] GC(1) Eden regions: 306->0(306) [2021-04-26T14:19:17.233+0000][info][gc,heap ] GC(1) Survivor regions: 1->1(39) [2021-04-26T14:19:17.233+0000][info][gc,heap ] GC(1) Old regions: 0->0 [2021-04-26T14:19:17.233+0000][info][gc,heap ] GC(1) Humongous regions: 0->0 [2021-04-26T14:19:17.233+0000][info][gc,metaspace ] GC(1) Metaspace: 5863K->5863K(1056768K) [2021-04-26T14:19:17.233+0000][info][gc ] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 306M->0M(512M) 16.875ms [2021-04-26T14:19:17.233+0000][info][gc,cpu ] GC(1) User=0.01s Sys=0.00s Real=0.02s [2021-04-26T14:19:19.855+0000][info][gc,start ] GC(2) Pause Young (Normal) (G1 Evacuation Pause) [2021-04-26T14:19:19.859+0000][info][gc,task ] GC(2) Using 4 workers of 4 for evacuation [2021-04-26T14:19:19.889+0000][info][gc,phases ] GC(2) Pre Evacuate Collection Set: 0.0ms [2021-04-26T14:19:19.889+0000][info][gc,phases ] GC(2) Evacuate Collection Set: 28.1ms [2021-04-26T14:19:19.889+0000][info][gc,phases ] GC(2) Post Evacuate Collection Set: 0.5ms
众所周知，Java 垃圾收集器（GC）日志用于内存管理和对象分配和回收。GC Log 包括众多关键信息，例如 GC 进程的持续时间，升级的对象数等等，除此，整个 GC 进程的详细信息以及它使用的资源信息等一一展示。基于这些日志的分析以便能够有效检测问题并提高 JVM 应用程序的整体性能。
那么它是如何工作的？
与开发人员需要标记和删除对象的手动进程不同，Java 垃圾收集器会自动识别并清除 Java 程序不再使用的对象或组件。整个释放空间的过程中，帮助开发人员节省时间并更高效。
基于应用程序性能调整复杂、繁琐的特性，在其初衷的设计理念中，Java GC 日志为我们提供了一种独特的方法，可以获得基于 Java 的应用程序的深入进行了解。GC 日志显示对象分配模式、诊断磁盘、CPU和内存相关问题等问题，并增强基于 Java 的应用程序性能。
为什么使用 Java GC 日志分析工具？
GC 日志的可视化有限会导致耗时的搜索和未识别的过时对象。它还可以导致内存泄漏，长 GC 暂停，慢慢分析和监控。它还可以增加分辨率的平均时间，并影响基于 Java 的应用程序的性能。此外，在使用多个框架，服务器和应用程序的分布式环境中，手动分析大规模卷的 Java GC 日志将变得挑战。
因此，集中式日志管理工具或平台的产生，使得其能够自动执行 Java GC 日志分析。这些工具帮助 IT团队关联不同的基础架构和应用程序日志，提供完美的日志记录体验。
下面笔者以自身的经验将简要概述一些常用的 GC Log 分析工具，基于不同的业务环境以用于进行分析、监视和管理 Java GC 日志。
GC PLOT
GCplot 是一个开源日志分析，旨在即时收集 Java GC 日志。它使日志分析随着根本原因分析，易于理解的图形和统计数据而努力。该工具采用高端技术，如端到端 SSL加密和强大的可视化功能，以确保安全流量。我们可以使用该工具的数据库备份，健康检查和聚类功能保护业务关键信息，可以在详细报告和图表中可视化 Java GC 日志和关键信息。 GCplot 可以在 Docker 容器上运行，而无需外部配置。
[administrator@JavaLangOutOfMemory MyDemo] % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b13d6ff910fd gcplot/gcplot "/start.sh" 4 hours ago Up 4 hours 2424/tcp, 2480/tcp, 0.0.0.0:80->80/tcp, 9042/tcp gcplot_lee
GC Easy
Gc Easy 是用于分析 Java GC 日志的记录工具。它使用机器学习和自动检测功能来跟踪 Java虚拟机上的问题。利用其机器学习算法，IT 团队可以轻松检测异组织，解决内存泄漏问题，GC 日志问题，并保存开发人员的时间。
基于此工具，还可以生成详细的报告，具有指标，例如关键性能指示符和 GC 统计信息，以帮助团队解决 GC 日志问题。此外，Gc Easy 使用 REST API 快速监视和分析简单代码的所有日志。只需启用 GC 日志，上载所有 Java GC 日志，使用 REST API 立即监视大规模的日志，并可视化报告以识别改进区域。
SOLARWINDS Loggly
SolarWinds®Loggly® 是一个强大的日志分析工具，具有独特的管理和监控 Java GC日志的方法。凭借其无代理架构，该工具会在不安装专有代理的情况下快速收集信息。通过 rsyslog 汇总，集中和导入日志。开发人员使用这些日志来关联数据并解决 GC 问题，例如内存泄漏和过早的对象分配。
除此之外，此工具可以基于 Lucene 查询语法自动从分布式堆栈中检测 GC 日志。 凭借其增强的搜索和分析功能，该工具可以更快地检测和排除问题。 此外，我们可以在AWS S3 存储桶上使用 Loggly 存档旧的 GC 日志，以满足合规要求。 此外，基于其直观和可定制的仪表板能够反映包括图表，图形和旨在简化 GC 活动的跟踪的表，使得整个技术团队可以在其组织中共享仪表板。
GC Viewer
GC Viewer 是一个免费的日志查看器和分析器，可帮助团队检测和可视化 Java 虚拟
机生成的 GC 日志。该工具在检测 Java 应用程序减速背后的原因方面发挥着重要作用。要使用该工具，开发人员需要汇总有用的 GC 日志文件并将其上传到 GCViewer 中。 该工具显示图表和图表，其中包含关于 GC 事件的信息、内存池大小、堆消耗、GC暂停、内存用法等的频率和持续时间。
综上所述，GC 日志分析是为了识别问题，修复瓶颈和无缝运行基于 Java 的应用程序的最佳方法之一。在实际的业务场景中，基于上述所分享的工具使得我们能够对 GC 日志的分析有更全面、深入的了解，以便支撑我们在面对 Java 虚拟机问题时，能够游刃有余地去解决。
以上为基于 Java GC Log 分析工具的相关分享，本文到此为止，大家有任何问题或建议，可以随时留言、沟通。
