JVM优化 - 使用 jstack 查看死锁

最新推荐文章于 2024-09-22 14:40:40 发布

yinni11

最新推荐文章于 2024-09-22 14:40:40 发布

阅读量878

点赞数

分类专栏：内存监控和Dump

内存监控和Dump 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

# JVM优化 - 第一天

## 今日内容

- 了解下我们为什么要学习JVM优化

- 掌握jvm的运行参数以及参数的设置

- 掌握jvm的内存模型（堆内存）

- 掌握jamp命令的使用以及通过MAT工具进行分析

- 掌握定位分析内存溢出的方法

- 掌握jstack命令的使用

- 掌握VisualJVM工具的使用

## 1、我们为什么要对jvm做优化？

在本地开发环境中我们很少会遇到需要对jvm进行优化的需求，但是到了生产环境，我们可能将有下面的需求：

- 运行的应用“卡住了”，日志不输出，程序没有反应

- 服务器的CPU负载突然升高

- 在多线程应用下，如何分配线程的数量？

- ……

在本次课程中，我们将对jvm有更深入的学习，我们不仅要让程序能跑起来，而且是可以跑的更快！可以分析解决在生产环境中所遇到的各种“棘手”的问题。

> 说明：本套课程使用的jdk版本为1.8。

## 2、jvm的运行参数

在jvm中有很多的参数可以进行设置，这样可以让jvm在各种环境中都能够高效的运行。绝大部分的参数保持默认即可。

### 2.1、三种参数类型

jvm的参数类型分为三类，分别是：

- 标准参数

- -help

- -version

- -X参数（非标准参数）

- -Xint

- -Xcomp

- -XX参数（使用率较高）

- -XX:newSize

- -XX:+UseSerialGC

### 2.2、标准参数

jvm的标准参数，一般都是很稳定的，在未来的JVM版本中不会改变，可以使用java -help检索出所有的标准参数。

~~~shell

[root@node01 ~]# java -help

用法: java [-options] class [args...]

(执行类)

或 java [-options] -jar jarfile [args...]

(执行 jar 文件)

其中选项包括:

-d32 使用 32 位数据模型 (如果可用)

-d64 使用 64 位数据模型 (如果可用)

-server 选择 "server" VM

默认 VM 是 server,

因为您是在服务器类计算机上运行。

-cp <目录和 zip/jar 文件的类搜索路径>

-classpath <目录和 zip/jar 文件的类搜索路径>

用 : 分隔的目录, JAR 档案

和 ZIP 档案列表, 用于搜索类文件。

-D<名称>=<值>

设置系统属性

-verbose:[class|gc|jni]

启用详细输出

-version 输出产品版本并退出

-version:<值>

警告: 此功能已过时, 将在

未来发行版中删除。

需要指定的版本才能运行

-showversion 输出产品版本并继续

-jre-restrict-search | -no-jre-restrict-search

警告: 此功能已过时, 将在

未来发行版中删除。

在版本搜索中包括/排除用户专用 JRE

-? -help 输出此帮助消息

-X 输出非标准选项的帮助

-ea[:<packagename>...|:<classname>]

-enableassertions[:<packagename>...|:<classname>]

按指定的粒度启用断言

-da[:<packagename>...|:<classname>]

-disableassertions[:<packagename>...|:<classname>]

禁用具有指定粒度的断言

-esa | -enablesystemassertions

启用系统断言

-dsa | -disablesystemassertions

禁用系统断言

-agentlib:<libname>[=<选项>]

加载本机代理库 <libname>, 例如 -agentlib:hprof

另请参阅 -agentlib:jdwp=help 和 -agentlib:hprof=help

-agentpath:<pathname>[=<选项>]

按完整路径名加载本机代理库

-javaagent:<jarpath>[=<选项>]

加载 Java 编程语言代理, 请参阅 java.lang.instrument

-splash:<imagepath>

使用指定的图像显示启动屏幕

~~~

#### 2.2.1、实战

> **实战1：查看jvm版本**

~~~shell

[root@node01 ~]# java -version

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

# -showversion参数是表示，先打印版本信息，再执行后面的命令，在调试时非常有用，后面会使用到。

~~~

> **实战2：通过-D设置系统属性参数**

~~~java

public class TestJVM {

public static void main(String[] args) {

String str = System.getProperty("str");

if (str == null) {

System.out.println("itcast");

} else {

System.out.println(str);

}

~~~

进行编译、测试：

~~~shell

#编译

[root@node01 test]# javac TestJVM.java

#测试

[root@node01 test]# java TestJVM

itcast

[root@node01 test]# java -Dstr=123 TestJVM

123

~~~

#### 2.2.2、-server与-client参数

可以通过-server或-client设置jvm的运行参数。

- 它们的区别是Server VM的初始堆空间会大一些，默认使用的是并行垃圾回收器，启动慢运行快。

- Client VM相对来讲会保守一些，初始堆空间会小一些，使用串行的垃圾回收器，它的目标是为了让JVM的启动速度更快，但运行速度会比Serverm模式慢些。

- JVM在启动的时候会根据硬件和操作系统自动选择使用Server还是Client类型的JVM。

- 32位操作系统

- 如果是Windows系统，不论硬件配置如何，都默认使用Client类型的JVM。

- 如果是其他操作系统上，机器配置有2GB以上的内存同时有2个以上CPU的话默认使用server模式，否则使用client模式。

- 64位操作系统

- 只有server类型，不支持client类型。

测试：

~~~shell

[root@node01 test]# java -client -showversion TestJVM

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

itcast

[root@node01 test]# java -server -showversion TestJVM

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

itcast

#由于机器是64位系统，所以不支持client模式

~~~

### 2.3、-X参数

jvm的-X参数是非标准参数，在不同版本的jvm中，参数可能会有所不同，可以通过java -X查看非标准参数。

~~~shell

[root@node01 test]# java -X

-Xmixed 混合模式执行 (默认)

-Xint 仅解释模式执行

-Xbootclasspath:<用 : 分隔的目录和 zip/jar 文件>

设置搜索路径以引导类和资源

-Xbootclasspath/a:<用 : 分隔的目录和 zip/jar 文件>

附加在引导类路径末尾

-Xbootclasspath/p:<用 : 分隔的目录和 zip/jar 文件>

置于引导类路径之前

-Xdiag 显示附加诊断消息

-Xnoclassgc 禁用类垃圾收集

-Xincgc 启用增量垃圾收集

-Xloggc:<file> 将 GC 状态记录在文件中 (带时间戳)

-Xbatch 禁用后台编译

-Xms<size> 设置初始 Java 堆大小

-Xmx<size> 设置最大 Java 堆大小

-Xss<size> 设置 Java 线程堆栈大小

-Xprof 输出 cpu 配置文件数据

-Xfuture 启用最严格的检查, 预期将来的默认值

-Xrs 减少 Java/VM 对操作系统信号的使用 (请参阅文档)

-Xcheck:jni 对 JNI 函数执行其他检查

-Xshare:off 不尝试使用共享类数据

-Xshare:auto 在可能的情况下使用共享类数据 (默认)

-Xshare:on 要求使用共享类数据, 否则将失败。

-XshowSettings 显示所有设置并继续

-XshowSettings:all

显示所有设置并继续

-XshowSettings:vm 显示所有与 vm 相关的设置并继续

-XshowSettings:properties

显示所有属性设置并继续

-XshowSettings:locale

显示所有与区域设置相关的设置并继续

-X 选项是非标准选项, 如有更改, 恕不另行通知。

~~~

#### 2.3.1、-Xint、-Xcomp、-Xmixed

- 在解释模式(interpreted mode)下，-Xint标记会强制JVM执行所有的字节码，当然这会降低运行速度，通常低10倍或更多。

- -Xcomp参数与它（-Xint）正好相反，JVM在第一次使用时会把所有的字节码编译成本地代码，从而带来最大程度的优化。

- 然而，很多应用在使用-Xcomp也会有一些性能损失，当然这比使用-Xint损失的少，原因是-xcomp没有让JVM启用JIT编译器的全部功能。JIT编译器可以对是否需要编译做判断，如果所有代码都进行编译的话，对于一些只执行一次的代码就没有意义了。

- -Xmixed是混合模式，将解释模式与编译模式进行混合使用，由jvm自己决定，这是jvm默认的模式，也是推荐使用的模式。

示例：强制设置运行模式

~~~shell

#强制设置为解释模式

[root@node01 test]# java -showversion -Xint TestJVM

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, interpreted mode)

itcast

#强制设置为编译模式

[root@node01 test]# java -showversion -Xcomp TestJVM

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, compiled mode)

itcast

#注意：编译模式下，第一次执行会比解释模式下执行慢一些，注意观察。

#默认的混合模式

[root@node01 test]# java -showversion TestJVM

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

itcast

~~~

### 2.4、-XX参数

-XX参数也是非标准参数，主要用于jvm的调优和debug操作。

-XX参数的使用有2种方式，一种是boolean类型，一种是非boolean类型：

- boolean类型

- 格式：-XX:[+-]\<name> 表示启用或禁用\<name>属性

- 如：-XX:+DisableExplicitGC 表示禁用手动调用gc操作，也就是说调用System.gc()无效

- 非boolean类型

- 格式：-XX:\<name>=\<value> 表示\<name>属性的值为\<value>

- 如：-XX:NewRatio=1 表示新生代和老年代的比值

用法：

~~~shell

[root@node01 test]# java -showversion -XX:+DisableExplicitGC TestJVM

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

itcast

~~~

### 2.5、-Xms与-Xmx参数

-Xms与-Xmx分别是设置jvm的堆内存的初始大小和最大大小。

-Xmx2048m：等价于-XX:MaxHeapSize，设置JVM最大堆内存为2048M。

-Xms512m：等价于-XX:InitialHeapSize，设置JVM初始堆内存为512M。

适当的调整jvm的内存大小，可以充分利用服务器资源，让程序跑的更快。

示例：

~~~shell

[root@node01 test]# java -Xms512m -Xmx2048m TestJVM

itcast

~~~

### 2.6、查看jvm的运行参数

有些时候我们需要查看jvm的运行参数，这个需求可能会存在2种情况：

第一，运行java命令时打印出运行参数；

第二，查看正在运行的java进程的参数；

#### 2.6.1、运行java命令时打印参数

运行java命令时打印参数，需要添加-XX:+PrintFlagsFinal参数即可。

~~~shell

[root@node01 test]# java -XX:+PrintFlagsFinal -version

[Global flags]

uintx AdaptiveSizeDecrementScaleFactor = 4 {product}

uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product}

uintx AdaptiveSizePausePolicy = 0 {product}

uintx AdaptiveSizePolicyCollectionCostMargin = 50 {product}

uintx AdaptiveSizePolicyInitializingSteps = 20 {product}

uintx AdaptiveSizePolicyOutputInterval = 0 {product}

uintx AdaptiveSizePolicyWeight = 10 {product}

uintx AdaptiveSizeThroughPutPolicy = 0 {product}

uintx AdaptiveTimeWeight = 25 {product}

bool AdjustConcurrency = false {product}

bool AggressiveOpts = false {product}

intx AliasLevel = 3 {C2 product}

bool AlignVector = true {C2 product}

intx AllocateInstancePrefetchLines = 1 {product}

intx AllocatePrefetchDistance = 256 {product}

intx AllocatePrefetchInstr = 0 {product}

…………………………略…………………………………………

bool UseXmmI2D = false {ARCH product}

bool UseXmmI2F = false {ARCH product}

bool UseXmmLoadAndClearUpper = true {ARCH product}

bool UseXmmRegToRegMoveAll = true {ARCH product}

bool VMThreadHintNoPreempt = false {product}

intx VMThreadPriority = -1 {product}

intx VMThreadStackSize = 1024 {pd product}

intx ValueMapInitialSize = 11 {C1 product}

intx ValueMapMaxLoopSize = 8 {C1 product}

intx ValueSearchLimit = 1000 {C2 product}

bool VerifyMergedCPBytecodes = true {product}

bool VerifySharedSpaces = false {product}

intx WorkAroundNPTLTimedWaitHang = 1 {product}

uintx YoungGenerationSizeIncrement = 20 {product}

uintx YoungGenerationSizeSupplement = 80 {product}

uintx YoungGenerationSizeSupplementDecay = 8 {product}

uintx YoungPLABSize = 4096 {product}

bool ZeroTLAB = false {product}

intx hashCode = 5 {product}

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

~~~

由上述的信息可以看出，参数有boolean类型和数字类型，值的操作符是=或:=，分别代表默认值和被修改的值。

示例：

~~~shell

java -XX:+PrintFlagsFinal -XX:+VerifySharedSpaces -version

intx ValueMapInitialSize = 11 {C1 product}

intx ValueMapMaxLoopSize = 8 {C1 product}

intx ValueSearchLimit = 1000 {C2 product}

bool VerifyMergedCPBytecodes = true {product}

bool VerifySharedSpaces := true {product}

intx WorkAroundNPTLTimedWaitHang = 1 {product}

uintx YoungGenerationSizeIncrement = 20 {product}

uintx YoungGenerationSizeSupplement = 80 {product}

uintx YoungGenerationSizeSupplementDecay = 8 {product}

uintx YoungPLABSize = 4096 {product}

bool ZeroTLAB = false {product}

intx hashCode = 5 {product}

java version "1.8.0_141"

Java(TM) SE Runtime Environment (build 1.8.0_141-b15)

Java HotSpot(TM) 64-Bit Server VM (build 25.141-b15, mixed mode)

#可以看到VerifySharedSpaces这个参数已经被修改了。

~~~

#### 2.6.2、查看正在运行的jvm参数

如果想要查看正在运行的jvm就需要借助于jinfo命令查看。

首先，启动一个tomcat用于测试，来观察下运行的jvm参数。

~~~shell

cd /tmp/

rz 上传

tar -xvf apache-tomcat-7.0.57.tar.gz

cd apache-tomcat-7.0.57

cd bin/

./startup.sh

#http://192.168.40.133:8080/ 进行访问

~~~

访问成功： ![1536488631901](assets/1536488631901.png)

~~~shell

#查看所有的参数，用法：jinfo -flags <进程id>

#通过jps 或者 jps -l 查看java进程

[root@node01 bin]# jps

6346 Jps

6219 Bootstrap

[root@node01 bin]# jps -l

6358 sun.tools.jps.Jps

6219 org.apache.catalina.startup.Bootstrap

[root@node01 bin]#

[root@node01 bin]# jinfo -flags 6219

Attaching to process ID 6219, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.141-b15

Non-default VM flags: -XX:CICompilerCount=2 -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=488636416 -XX:MaxNewSize=162529280 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=10485760 -XX:OldSize=20971520 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC

Command line: -Djava.util.logging.config.file=/tmp/apache-tomcat-7.0.57/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/tmp/apache-tomcat-7.0.57/endorsed -Dcatalina.base=/tmp/apache-tomcat-7.0.57 -Dcatalina.home=/tmp/apache-tomcat-7.0.57 -Djava.io.tmpdir=/tmp/apache-tomcat-7.0.57/temp

#查看某一参数的值，用法：jinfo -flag <参数名> <进程id>

[root@node01 bin]# jinfo -flag MaxHeapSize 6219

-XX:MaxHeapSize=488636416

~~~

## 3、jvm的内存模型

jvm的内存模型在1.7和1.8有较大的区别，虽然本套课程是以1.8为例进行讲解，但是我们也是需要对1.7的内存模型有所了解，所以接下里，我们将先学习1.7再学习1.8的内存模型。

### 3.1、jdk1.7的堆内存模型

![1536501289198](assets/1536501289198.png)

- Young 年轻区（代）

Young区被划分为三部分，Eden区和两个大小严格相同的Survivor区，其中，Survivor区间中，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用，在Eden区间变满的时候， GC就会将存活的对象移到空闲的Survivor区间中，根据JVM的策略，在经过几次垃圾收集后，任然存活于Survivor的对象将被移动到Tenured区间。

- Tenured 年老区

Tenured区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移一定的次数以后，对象就会被转移到Tenured区，一般如果系统中用了application级别的缓存，缓存中的对象往往会被转移到这一区间。

- Perm 永久区

Perm代主要保存class,method,filed对象，这部份的空间一般不会溢出，除非一次性加载了很多的类，不过在涉及到热部署的应用服务器的时候，有时候会遇到java.lang.OutOfMemoryError : PermGen space 的错误，造成这个错误的很大原因就有可能是每次都重新部署，但是重新部署后，类的class没有被卸载掉，这样就造成了大量的class对象保存在了perm中，这种情况下，一般重新启动应用服务器可以解决问题。

- Virtual区：

- 最大内存和初始内存的差值，就是Virtual区。

### 3.2、jdk1.8的堆内存模型

![1536501652150](assets/1536501652150.png)

由上图可以看出，jdk1.8的内存模型是由2部分组成，年轻代 + 年老代。

年轻代：Eden + 2*Survivor

年老代：OldGen

在jdk1.8中变化最大的Perm区，用Metaspace（元数据空间）进行了替换。

需要特别说明的是：Metaspace所占用的内存空间不是在虚拟机内部，而是在本地内存空间中，这也是与1.7的永久代最大的区别所在。

![1536507420882](assets/1536507420882.png)

### 3.3、为什么要废弃1.7中的永久区？

官网给出了解释：http://openjdk.java.net/jeps/122

~~~

This is part of the JRockit and Hotspot convergence effort. JRockit customers do not need to configure the permanent generation (since JRockit does not have a permanent generation) and are accustomed to not configuring the permanent generation.

移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代。

~~~

现实使用中，由于永久代内存经常不够用或发生内存泄露，爆出异常java.lang.OutOfMemoryError: PermGen。

基于此，将永久区废弃，而改用元空间，改为了使用本地内存空间。

### 3.4、通过jstat命令进行查看堆内存使用情况

jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下：

jstat \[-命令选项] \[vmid] \[间隔时间/毫秒] \[查询次数]

#### 3.4.1、查看class加载统计

~~~shell

[root@node01 ~]# jps

7080 Jps

6219 Bootstrap

[root@node01 ~]# jstat -class 6219

Loaded Bytes Unloaded Bytes Time

3273 7122.3 0 0.0 3.98

~~~

说明：

- Loaded：加载class的数量

- Bytes：所占用空间大小

- Unloaded：未加载数量

- Bytes：未加载占用空间

- Time：时间

#### 3.4.2、查看编译统计

~~~shell

[root@node01 ~]# jstat -compiler 6219

Compiled Failed Invalid Time FailedType FailedMethod

2376 1 0 8.04 1 org/apache/tomcat/util/IntrospectionUtils setProperty

~~~

说明：

- Compiled：编译数量。

- Failed：失败数量

- Invalid：不可用数量

- Time：时间

- FailedType：失败类型

- FailedMethod：失败的方法

#### 3.4.3、垃圾回收统计

~~~shell

[root@node01 ~]# jstat -gc 6219

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT

9216.0 8704.0 0.0 6127.3 62976.0 3560.4 33792.0 20434.9 23808.0 23196.1 2560.0 2361.6 7 1.078 1 0.244 1.323

#也可以指定打印的间隔和次数，每1秒中打印一次，共打印5次

[root@node01 ~]# jstat -gc 6219 1000 5

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT

9216.0 8704.0 0.0 6127.3 62976.0 3917.3 33792.0 20434.9 23808.0 23196.1 2560.0 2361.6 7 1.078 1 0.244 1.323

~~~

说明：

- S0C：第一个Survivor区的大小（KB）

- S1C：第二个Survivor区的大小（KB）

- S0U：第一个Survivor区的使用大小（KB）

- S1U：第二个Survivor区的使用大小（KB）

- EC：Eden区的大小（KB）

- EU：Eden区的使用大小（KB）

- OC：Old区大小（KB）

- OU：Old使用大小（KB）

- MC：方法区大小（KB）

- MU：方法区使用大小（KB）

- CCSC：压缩类空间大小（KB）

- CCSU：压缩类空间使用大小（KB）

- YGC：年轻代垃圾回收次数

- YGCT：年轻代垃圾回收消耗时间

- FGC：老年代垃圾回收次数

- FGCT：老年代垃圾回收消耗时间

- GCT：垃圾回收消耗总时间

## 4、jmap的使用以及内存溢出分析

前面通过jstat可以对jvm堆的内存进行统计分析，而jmap可以获取到更加详细的内容，如：内存使用情况的汇总、对内存溢出的定位与分析。

### 4.1、查看内存使用情况

~~~shell

[root@node01 ~]# jmap -heap 6219

Attaching to process ID 6219, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.141-b15

using thread-local object allocation.

Parallel GC with 2 thread(s)

Heap Configuration: #堆内存配置信息

MinHeapFreeRatio = 0

MaxHeapFreeRatio = 100

MaxHeapSize = 488636416 (466.0MB)

NewSize = 10485760 (10.0MB)

MaxNewSize = 162529280 (155.0MB)

OldSize = 20971520 (20.0MB)

NewRatio = 2

SurvivorRatio = 8

MetaspaceSize = 21807104 (20.796875MB)

CompressedClassSpaceSize = 1073741824 (1024.0MB)

MaxMetaspaceSize = 17592186044415 MB

G1HeapRegionSize = 0 (0.0MB)

Heap Usage: # 堆内存的使用情况

PS Young Generation #年轻代

Eden Space:

capacity = 123731968 (118.0MB)

used = 1384736 (1.320587158203125MB)

free = 122347232 (116.67941284179688MB)

1.1191416594941737% used

From Space:

capacity = 9437184 (9.0MB)

used = 0 (0.0MB)

free = 9437184 (9.0MB)

0.0% used

To Space:

capacity = 9437184 (9.0MB)

used = 0 (0.0MB)

free = 9437184 (9.0MB)

0.0% used

PS Old Generation #年老代

capacity = 28311552 (27.0MB)

used = 13698672 (13.064071655273438MB)

free = 14612880 (13.935928344726562MB)

48.38545057508681% used

13648 interned Strings occupying 1866368 bytes.

~~~

### 4.2、查看内存中对象数量及大小

~~~shell

#查看所有对象，包括活跃以及非活跃的

jmap -histo <pid> | more

#查看活跃对象

jmap -histo:live <pid> | more

[root@node01 ~]# jmap -histo:live 6219 | more

num #instances #bytes class name

----------------------------------------------

1: 37437 7914608 [C

2: 34916 837984 java.lang.String

3: 884 654848 [B

4: 17188 550016 java.util.HashMap$Node

5: 3674 424968 java.lang.Class

6: 6322 395512 [Ljava.lang.Object;

7: 3738 328944 java.lang.reflect.Method

8: 1028 208048 [Ljava.util.HashMap$Node;

9: 2247 144264 [I

10: 4305 137760 java.util.concurrent.ConcurrentHashMap$Node

11: 1270 109080 [Ljava.lang.String;

12: 64 84128 [Ljava.util.concurrent.ConcurrentHashMap$Node;

13: 1714 82272 java.util.HashMap

14: 3285 70072 [Ljava.lang.Class;

15: 2888 69312 java.util.ArrayList

16: 3983 63728 java.lang.Object

17: 1271 61008 org.apache.tomcat.util.digester.CallMethodRule

18: 1518 60720 java.util.LinkedHashMap$Entry

19: 1671 53472 com.sun.org.apache.xerces.internal.xni.QName

20: 88 50880 [Ljava.util.WeakHashMap$Entry;

21: 618 49440 java.lang.reflect.Constructor

22: 1545 49440 java.util.Hashtable$Entry

23: 1027 41080 java.util.TreeMap$Entry

24: 846 40608 org.apache.tomcat.util.modeler.AttributeInfo

25: 142 38032 [S

26: 946 37840 java.lang.ref.SoftReference

27: 226 36816 [[C

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

#对象说明

B byte

C char

D double

F float

I int

J long

Z boolean

[ 数组，如[I表示int[]

[L+类名其他对象

~~~

### 4.3、将内存使用情况dump到文件中

有些时候我们需要将jvm当前内存中的情况dump到文件中，然后对它进行分析，jmap也是支持dump到文件中的。

~~~shell

#用法：

jmap -dump:format=b,file=dumpFileName <pid>

#示例

jmap -dump:format=b,file=/tmp/dump.dat 6219

~~~

![1536512769514](assets/1536512769514.png)

可以看到已经在/tmp下生成了dump.dat的文件。

### 4.4、通过jhat对dump文件进行分析

在上一小节中，我们将jvm的内存dump到文件中，这个文件是一个二进制的文件，不方便查看，这时我们可以借助于jhat工具进行查看。

~~~shell

#用法：

jhat -port <port> <file>

#示例：

[root@node01 tmp]# jhat -port 9999 /tmp/dump.dat

Reading from /tmp/dump.dat...

Dump file created Mon Sep 10 01:04:21 CST 2018

Snapshot read, resolving...

Resolving 204094 objects...

Chasing references, expect 40 dots........................................

Eliminating duplicate references........................................

Snapshot resolved.

Started HTTP server on port 9999

Server is ready.

~~~

打开浏览器进行访问：http://192.168.40.133:9999/

![1536513416186](assets/1536513416186.png)

在最后面有OQL查询功能。

![1536513474958](assets/1536513474958.png)

![1536513591638](assets/1536513591638.png)

### 4.5、通过MAT工具对dump文件进行分析

#### 4.5.1、MAT工具介绍

MAT(Memory Analyzer Tool)，一个基于Eclipse的内存分析工具，是一个快速、功能丰富的JAVA heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗。使用内存分析工具从众多的对象中进行分析，快速的计算出在内存中对象的占用大小，看看是谁阻止了垃圾收集器的回收工作，并可以通过报表直观的查看到可能造成这种结果的对象。

官网地址：https://www.eclipse.org/mat/

![1536515331814](assets/1536515331814.png)

#### 4.5.2、下载安装

下载地址：https://www.eclipse.org/mat/downloads.php

![1536515395914](assets/1536515395914.png)

将下载得到的MemoryAnalyzer-1.8.0.20180604-win32.win32.x86_64.zip进行解压：

![1536515524838](assets/1536515524838.png)

#### 4.5.3、使用

![1536515700264](assets/1536515700264.png)

![1536515764096](assets/1536515764096.png)

![1536515922938](assets/1536515922938.png)

![1536516001249](assets/1536516001249.png)

查看对象以及它的依赖：

![1536516171924](assets/1536516171924.png)

查看可能存在内存泄露的分析： ![1536516259369](assets/1536516259369.png)

## 5、实战：内存溢出的定位与分析

内存溢出在实际的生产环境中经常会遇到，比如，不断的将数据写入到一个集合中，出现了死循环，读取超大的文件等等，都可能会造成内存溢出。

如果出现了内存溢出，首先我们需要定位到发生内存溢出的环节，并且进行分析，是正常还是非正常情况，如果是正常的需求，就应该考虑加大内存的设置，如果是非正常需求，那么就要对代码进行修改，修复这个bug。

首先，我们得先学会如何定位问题，然后再进行分析。如何定位问题呢，我们需要借助于jmap与MAT工具进行定位分析。

接下来，我们模拟内存溢出的场景。

### 5.1、模拟内存溢出

编写代码，向List集合中添加100万个字符串，每个字符串由1000个UUID组成。如果程序能够正常执行，最后打印ok。

~~~java

package cn.itcast.jvm;

import java.util.ArrayList;

import java.util.List;

import java.util.UUID;

public class TestJvmOutOfMemory {

public static void main(String[] args) {

List<Object> list = new ArrayList<>();

for (int i = 0; i < 10000000; i++) {

String str = "";

for (int j = 0; j < 1000; j++) {

str += UUID.randomUUID().toString();

}

list.add(str);

}

System.out.println("ok");

}

~~~

为了演示效果，我们将设置执行的参数，这里使用的是Idea编辑器。

![1536591244437](assets/1536591244437.png)

~~~shell

#参数如下：

-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

~~~

### 5.2、运行测试

测试结果如下：

~~~java

java.lang.OutOfMemoryError: Java heap space

Dumping heap to java_pid5348.hprof ...

Heap dump file created [8137186 bytes in 0.032 secs]

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Arrays.java:3332)

at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)

at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)

at java.lang.StringBuilder.append(StringBuilder.java:136)

at cn.itcast.jvm.TestJvmOutOfMemory.main(TestJvmOutOfMemory.java:14)

Process finished with exit code 1

~~~

可以看到，当发生内存溢出时，会dump文件到java_pid5348.hprof。 ![1536591747657](assets/1536591747657.png)

### 5.3、导入到MAT工具中进行分析

![1536592135948](assets/1536592135948.png)

可以看到，有91.03%的内存由Object[]数组占有，所以比较可疑。

分析：这个可疑是正确的，因为已经有超过90%的内存都被它占有，这是非常有可能出现内存溢出的。

查看详情：

![1536594010544](assets/1536594010544.png)

可以看到集合中存储了大量的uuid字符串。

## 6、jstack的使用

有些时候我们需要查看下jvm中的线程执行情况，比如，发现服务器的CPU的负载突然增高了、出现了死锁、死循环等，我们该如何分析呢？

由于程序是正常运行的，没有任何的输出，从日志方面也看不出什么问题，所以就需要看下jvm的内部线程的执行情况，然后再进行分析查找出原因。

这个时候，就需要借助于jstack命令了，jstack的作用是将正在运行的jvm的线程情况进行快照，并且打印出来：

~~~shell

#用法：jstack <pid>

[root@node01 bin]# jstack 2203

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.141-b15 mixed mode):

"Attach Listener" #24 daemon prio=9 os_prio=0 tid=0x00007fabb4001000 nid=0x906 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"http-bio-8080-exec-5" #23 daemon prio=5 os_prio=0 tid=0x00007fabb057c000 nid=0x8e1 waiting on condition [0x00007fabd05b8000]

java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for <0x00000000f8508360> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)

at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)

at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)

at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:748)

"http-bio-8080-exec-4" #22 daemon prio=5 os_prio=0 tid=0x00007fab9c113800 nid=0x8e0 waiting on condition [0x00007fabd06b9000]