讲案例实战面对突如其来问题如何下手解决海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

本我们主要从一个实战案例入手分析面对突如其来的GC问题该如何下手解决。

想要下手解决GC问题，我们首先需要掌握下面这三种问题。

如何使用jstat命令查看JVM的GC情况？

面对海量GC日志参数，如何快速抓住问题根源？

你不得不掌握的日志分析工具。

工欲善其事，必先利其器。我们前面讲到的优化，包括代码优化、扩容、参数优化，甚至我们

的估算，都需要一些支撑信息加以判断。

对于JVM来说，一种情况是GC时间过长，会影响用户的体验，这个时候就需要调整某些JVM参数、

观察日志。

另外一种情况就比较严重了，发生了OOM，或者操作系统的内存溢出。服务直接宕机，我们要寻找背

后的。

这时，GC日志能够帮我们找到问题的根源。本，我们就简要介绍一下如何输出这些日志，以及如

何使用这些日志的支撑工具解决问题。

GC日志输出

你可能感受到，最近几年Java的版本更新速度是很快的，JVM的参数配置其实变化也很大。就拿GC日

志这一块来说，Java9几乎是重来。网络上的一些文章，把这些参数写的七八糟，根本不能投入

生产。如果你碰到不能被识别的参数，先确认一下自己的Java版本。

在事故出现的时候，通常并不是那么温柔。你可能在半夜里就能接到，这是因为很多定时任务

都设定在夜深人静的时候执行。

这个时候，再去看jstat已经来不及了，我们需要保留现场。这个便是看门狗的工作，看门狗可以通过

设置一些JVM参数进行配置。

那在实践中，要怎么用呢？请看下面命令行。

###

Java8

我们先看一下JDK8中的使用。

#!/bin/sh

LOG_DIR=/tmp/logs

JAVA_OPT_LOG=-verbose:gc

JAVA_OPT_LOG=${JAVA_OPT_LOG}-XX:+Printetails

JAVA_OPT_LOG=${JAVA_OPT_LOG}-XX:+PrintateStamps

JAVA_OPT_LOG=${JAVA_OPT_LOG}-XX:+PrintGCApplicationStoppedTime

JAVA_OPT_LOG=${JAVA_OPT_LOG}-XX:+PrintTenuringDistribution

JAVA_OPT_LOG=${JAVA_OPT_LOG}-Xloggc:${LOG_DIR}/gc_%p.log

JAVA_OPT_OOM=-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=${LOG_DIR}-

XX:ErrorFile=${LOG_DIR}/hs_error_pid%p.log

JAVA_OPT=${JAVA_OPT_LOG}${JAVA_OPT_OOM}

JAVA_OPT=${JAVA_OPT}-XX:-OmitStackTraceInFastThrow

合成一行。

-verbose:gc-XX:+Printetails-XX:+PrintateStamps

-XX:+PrintGCApplicationStoppedTime-XX:+PrintTenuringDistribution

-Xloggc:/tmp/logs/gc_%p.log-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/tmp/logs-XX:ErrorFile=/tmp/logs/hs_error_pid%p.log

-XX:-OmitStackTraceInFastThrow

然后我们来解释一下这些参数：

|

参数

|

意义

|

|

-verbose:gc

|

打印GC日志

|

|

Printetails

|

打印详细GC日志

|

|

PrintateStamps

|

系统时间，更加可读，PrintGCTimeStamps是JVM启动时间

|

|

PrintGCApplicationStoppedTime

|

打印STW时间

|

|

PrintTenuringDistribution