JVM优化（一）

最新推荐文章于 2024-06-16 00:07:02 发布

zdwhong

最新推荐文章于 2024-06-16 00:07:02 发布

阅读量570

点赞数 2

分类专栏： JVM 文章标签： JVM java jdk

JVM 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1、背景概述

在本地开发环境我们一般都不需要进行JVM的调优，所以这块接触的肯定不多。但是在生产环境，可能就会遇见下面的情况：

a、运行的应用“卡住了”，日志不输出，程序没有反应
b、服务器的CPU负载突然升高
c、在多线程应用下，如何分配线程的数量？
……
这个时候我们就需要对JVM进行优化，从而解决这些问题。

环境准备：本次我们使用的是JDK1.8，以为JDK1.8和JDK1.7在内存模型上有了很大的区别，这点后面会讲到。

Linux系统，在虚拟机上面安装CentOS6.5进行测试，在Linux系统上安装我们的JDK1.8，安装目录是/usr/loca/src/java

2、JVM的运行参数

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

2.1、三种参数类型

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

标准参数：-help -version

-X参数，非标准参数：-Xint -Xcomp

-XX参数（使用率较高）：-XX:newSize -XX:+UseSerialGC

2.2、标准参数

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

执行命令：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>
                  使用指定的图像显示启动屏幕
有关详细信息, 请参阅 http://www.oracle.com/technetwork/java/javase/documentation/index.html。

2.2.1 实战

实战1：执行命令：java -version 查看JVM的版本

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, 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("default");
            } else {
                System.out.println(str);
            }
    }
}

在目录/usr/local/src/java下面，执行命令：vim TestJVM.java，把上面的代码拷贝进去，保存退出（esc——》冒号——》wq)。然后执行javac TestJVM.java就会得到一个TestJVM.class文件。

然后我们执行命令：java -Dstr=zhouyu TestJVM

我们发现打出的是：zhouyu，如果不加-Dstr=TestJVM，那么输出的就是default

[root@image-server java]# java -Dstr=zhouyu TestJVM
zhouyu
[root@image-server java]# java TestJVM
default

2.2.2 -server与-client参数

可以通过-server或-client设置jvm的运行参数。
它们的区别是Server VM的初始堆空间会大一些，默认使用的是并行垃圾回收器，启动慢运行快。
Client VM相对来讲会保守一些，初始堆空间会小一些，使用串行的垃圾回收器，它的目标是为了让JVM的启动速度更快，但运行速度会比Server VM模式慢些。
JVM在启动的时候会根据硬件和操作系统自动选择使用Server还是Client类型的JVM。

32位操作系统
    如果是Windows系统，不论硬件配置如何，都默认使用Client类型的JVM。
    如果是其他操作系统上，机器配置有2GB以上的内存同时有2个以上CPU的话默认使用server模式，否则使用client模式。
64位操作系统
    只有server类型，不支持client类型。

测试：

[root@image-server java]# java -client -showversion TestJVM
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

default
[root@image-server java]# java -server -showversion TestJVM
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

default

可以看到我这里全部是Server VM，因为我的是64系统，所以模拟不出来client的，请自行测试。

2.3、-X参数

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

[root@image-server java]# 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

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

-Xcomp参数和-Xint正好相反，JVM在第一次使用时会把所有的字节码编译成本地代码，从而带来最大程度的优化。然而，很多应用在使用-Xcomp也会有一些性能损失，当然这比使用-Xint损失的少，原因是-Xcomp没有让JVM启用JIT编译器的全部功能。JIT编译器可以对是否需要编译做判断，如果所有代码都进行编译的话，对于一些只执行一次的代码就没有意义了。

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

测试：强制设置运行模式

#强制设置为解释模式
[root@image-server java]# java -showversion -Xint TestJVM
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, interpreted mode)

default

#强制设置为编译模式
[root@image-server java]# java -showversion -Xcomp TestJVM
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, compiled mode)

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

#默认的混合模式
[root@image-server java]# java -showversion TestJVM
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

default

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 表示新生代和老年代的比值
测试：

[root@image-server java]# java -showversion -XX:+DisableExplicitGC TestJVM
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

default

2.5、-Xms与-Xmx参数

-Xms与-Xmx分别是设置JVM的堆内存的初始大小和最大大小。
-Xmx2048m：等价于-XX:MaxHeapSize，设置JVM最大堆内存为2048M。
-Xms512m：等价于-XX:InitialHeapSize，设置JVM初始堆内存为512M。
适当的调整JVM的内存大小，可以充分利用服务器资源，让程序跑的更快。
测试：

[root@image-server java]# java -Xms256m -Xmx2048m TestJVM
default

2.6、查看jvm的运行参数

有些时候我们需要查看JVM的运行参数，这个需求可能会存在2种情况：
第一，运行java命令时打印出运行参数；
第二，查看正在运行的java进程的参数；

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

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

[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
{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类型和数字类型，值的操作符是=或:=，分别代表默认值和被修改的值。
示例：

[root@image-server java]# java -XX:+PrintFlagsFinal -XX:+ZeroTLAB -version
......
bool ZeroTLAB                                 := true                                {product}
     intx hashCode                                  = 5                                   {product}
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

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

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

如果想要查看正在运行的jvm就需要借助于jinfo命令查看。
首先，启动一个tomcat（在目录/usr/local/src/tomcat下面）用于测试，来观察下运行的jvm参数。

我的虚拟机端口是：192.168.137.136

启动tomcat：进入/usr/local/src/tomcat目录的tomcat7的bin目录下，执行命令：./startup.sh

执行命令查看tomcat启动状态：ps -ef | grep tomcat

[root@image-server bin]# ps -ef | grep tomcat
root       3771      1 12 19:16 pts/0    00:00:06 /usr/local/src/java/jdk1.8.0_201/bin/java -Djava.util.logging.config.file=/usr/local/src/tomcat/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/src/tomcat/tomcat7/endorsed -classpath /usr/local/src/tomcat/tomcat7/bin/bootstrap.jar:/usr/local/src/tomcat/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/usr/local/src/tomcat/tomcat7 -Dcatalina.home=/usr/local/src/tomcat/tomcat7 -Djava.io.tmpdir=/usr/local/src/tomcat/tomcat7/temp org.apache.catalina.startup.Bootstrap start
root       3790   1500  0 19:16 pts/0    00:00:00 grep tomcat

所以我们可以看到，tomcat的进程是3771，tomcat启动成功，可以在浏览器上访问：http://192.168.137.136:8080/

就能访问到tomcat的首页了。

注意：如果访问不了，一般是虚拟机的端口没有开放，可以自行百度怎么开放某个端口，也可以直接关闭linux的防火墙；

本次关闭：service iptables stop 本次开启：service iptables start

永久关闭：chkconfig iptables on 永久开启：chkconfig iptables off

测试查看正在运行的JVM参数：查看所有的参数，用法：jinfo -flags <进程id>

[root@image-server tomcat]# jinfo -flags 3771
Attaching to process ID 3771, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.201-b09
Non-default VM flags: -XX:CICompilerCount=2 -XX:InitialHeapSize=16777216 -XX:MaxHeapSize=257949696 -XX:MaxNewSize=85983232 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=5570560 -XX:OldSize=11206656 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps 
Command line:  -Djava.util.logging.config.file=/usr/local/src/tomcat/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/src/tomcat/tomcat7/endorsed -Dcatalina.base=/usr/local/src/tomcat/tomcat7 -Dcatalina.home=/usr/local/src/tomcat/tomcat7 -Djava.io.tmpdir=/usr/local/src/tomcat/tomcat7/temp

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

[root@image-server tomcat]# jinfo -flag MaxHeapSize 3771
-XX:MaxHeapSize=257949696

3、JVM的内存模型

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

3.1、jdk1.7的堆内存模型

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的堆内存模型

由上图可以看出，jdk1.8的内存模型是由2部分组成，年轻代 + 年老代。
年轻代：Eden + 2*Survivor
年老代：OldGen
在jdk1.8中变化最大的Perm区，用Metaspace（元数据空间）进行了替换。
需要特别说明的是：Metaspace所占用的内存空间不是在虚拟机内部，而是在本地内存空间中，这也是与1.7的永
久代最大的区别所在。

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加载统计

[root@image-server tomcat]# jstat -class 3771
Loaded  Bytes  Unloaded  Bytes     Time   
  2779  5500.8        0     0.0       3.91

说明：
Loaded：加载class的数量
Bytes：所占用空间大小
Unloaded：未加载数量
Bytes：未加载占用空间
Time：时间

3.4.2、查看编译统计

[root@image-server tomcat]# jstat -compiler 3771
Compiled Failed Invalid   Time   FailedType FailedMethod
    1922      1       0     7.68          1 org/apache/tomcat/util/IntrospectionUtils setProperty

说明：
Compiled：编译数量。
Failed：失败数量
Invalid：不可用数量
Time：时间
FailedType：失败类型
FailedMethod：失败的方法

3.4.3、垃圾回收统计

[root@image-server tomcat]# jstat -gc 3771
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
896.0  896.0   15.0   0.0    7360.0   5800.9   18260.0    17279.0   17664.0 17107.1 2048.0 1876.8     26    0.303   1      0.039    0.343

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

[root@image-server tomcat]# jstat -gc 3771 1000 5
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
896.0  896.0   15.0   0.0    7360.0   6054.9   18260.0    17279.0   17664.0 17107.1 2048.0 1876.8     26    0.303   1      0.039    0.343
896.0  896.0   15.0   0.0    7360.0   6054.9   18260.0    17279.0   17664.0 17107.1 2048.0 1876.8     26    0.303   1      0.039    0.343
896.0  896.0   15.0   0.0    7360.0   6054.9   18260.0    17279.0   17664.0 17107.1 2048.0 1876.8     26    0.303   1      0.039    0.343
896.0  896.0   15.0   0.0    7360.0   6054.9   18260.0    17279.0   17664.0 17107.1 2048.0 1876.8     26    0.303   1      0.039    0.343
896.0  896.0   15.0   0.0    7360.0   6054.9   18260.0    17279.0   17664.0 17107.1 2048.0 1876.8     26    0.303   1      0.039    0.343

说明：
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、查看内存使用情况

jmap -heap 3771

[root@image-server tomcat]# jmap -heap 3771
Attaching to process ID 3771, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.201-b09

using thread-local object allocation.
Mark Sweep Compact GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 257949696 (246.0MB)
   NewSize                  = 5570560 (5.3125MB)
   MaxNewSize               = 85983232 (82.0MB)
   OldSize                  = 11206656 (10.6875MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 8454144 (8.0625MB)
   used     = 6988984 (6.665214538574219MB)
   free     = 1465160 (1.3972854614257812MB)
   82.66932761022287% used
Eden Space:
   capacity = 7536640 (7.1875MB)
   used     = 6973608 (6.650550842285156MB)
   free     = 563032 (0.5369491577148438MB)
   92.52940302309783% used
From Space:
   capacity = 917504 (0.875MB)
   used     = 15376 (0.0146636962890625MB)
   free     = 902128 (0.8603363037109375MB)
   1.6758510044642858% used
To Space:
   capacity = 917504 (0.875MB)
   used     = 0 (0.0MB)
   free     = 917504 (0.875MB)
   0.0% used
tenured generation:
   capacity = 18698240 (17.83203125MB)
   used     = 17693672 (16.874000549316406MB)
   free     = 1004568 (0.9580307006835938MB)
   94.6274729600219% used

13039 interned Strings occupying 1805840 bytes.

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

查看所有对象，包括活跃以及非活跃的
jmap -histo <pid> | more

[root@image-server tomcat]# jmap -histo 3771 | more

 num     #instances         #bytes  class name
----------------------------------------------
   1:         34727        8409696  [B
   2:         48452        8105560  [C
   3:         10832        1197248  [I
   4:         45404        1089696  java.lang.String
   5:         19070         610240  java.util.HashMap$Node
   6:          4640         408320  java.lang.reflect.Method
   7:          9196         367840  java.util.HashMap$ValueIterator
   8:          5782         356776  [Ljava.lang.Object;
   9:          3094         351944  java.lang.Class
  10:          9030         288960  java.io.File
  11:          6770         264464  [Ljava.lang.String;
  12:          1289         232112  [Ljava.util.HashMap$Node;
  13:          9197         220728  org.apache.catalina.LifecycleEvent
  14:          9201         184936  [Lorg.apache.catalina.Container;
  15:          2019         145368  java.util.regex.Pattern
  16:          4494         143808  java.util.concurrent.ConcurrentLinkedQueue$Itr

上面只是截取了一部分，我们可以按空格键分页查看。

查看活跃对象

jmap -histo:live <pid> | more

[root@image-server tomcat]# jmap -histo:live 3771 | more

 num     #instances         #bytes  class name
----------------------------------------------
   1:         33768        7335016  [C
   2:          3089        1233008  [I
   3:         31914         765936  java.lang.String
   4:         17180         549760  java.util.HashMap$Node
   5:           830         437664  [B
   6:          3093         351840  java.lang.Class
   7:          5486         335992  [Ljava.lang.Object;
   8:          3738         328944  java.lang.reflect.Method
   9:          1022         207056  [Ljava.util.HashMap$Node;
  10:          3330         106560  java.util.concurrent.ConcurrentHashMap$Node
  11:          1135          97296  [Ljava.lang.String;
  12:          1678          80544  java.util.HashMap
  13:          3284          70048  [Ljava.lang.Class;
  14:            64          66464  [Ljava.util.concurrent.ConcurrentHashMap$Node;
  15:          2744          65856  java.util.ArrayList

#对象说明
B byte
C char
D double
F float
I int
J long
Z boolean
[ 数组，如[I：表示int[]
[L+类名：其他对象

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

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

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

-dump:format=b：表示生成的是二进制文件

[root@image-server tomcat]# jmap -dump:format=b,file=/tmp/dump.dat 3771
Dumping heap to /tmp/dump.dat ...
Heap dump file created

可以进入目录/tmp查看，发现已经生成了dump.dat文件。

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

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

jhat -port <port> <file>

[root@image-server tmp]# jhat -port 9999 /tmp/dump.dat
Reading from /tmp/dump.dat...
Dump file created Wed Jun 26 22:35:02 CST 2019
Snapshot read, resolving...
Resolving 168579 objects...
Chasing references, expect 33 dots.................................
Eliminating duplicate references.................................
Snapshot resolved.
Started HTTP server on port 9999
Server is ready.

这个时候我们可以在浏览器上访问：http://192.168.137.136:9999/

在最后面有OQL查询功能。

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

4.5.1、MAT工具介绍

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

4.5.2、下载安装

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

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

4.5.3、使用

首先我们要把在linux服务器上生成的dump.dat文件下载到windows上面。执行alt+p命令，然后执行get /tmp/dump.dat ，这个时候，默认会把dump.dat文件下载到 C:\Users\用户名\Documents目录下面。

然后我们就可以使用MAT软件打开这个文件了：

查看对象以及它的依赖：

查看可能存在内存泄露的分析：

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

内存溢出在实际的生产环境中经常会遇到，比如，不断的将数据写入到一个集合中，出现了死循环，读取超大的文件等等，都可能会造成内存溢出。
如果出现了内存溢出，首先我们需要定位到发生内存溢出的环节，并且进行分析，是正常还是非正常情况，如果是正常的需求，就应该考虑加大内存的设置，如果是非正常需求，那么就要对代码进行修改，修复这个bug。
首先，我们得先学会如何定位问题，然后再进行分析。如何定位问题呢，我们需要借助于jmap与MAT工具进行定位分析。
接下来，我们模拟内存溢出的场景。

5.1、模拟内存溢出

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

package com.zdw.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编辑器，

设置运行参数：-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

-XX:+HeapDumpOnOutOfMemoryError：设置这个参数就会在类路径下生成一个文件；

执行程序，我们看到控制台如下：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid34108.hprof ...
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 com.zdw.jvm.TestJVMOutOfMemory.main(TestJVMOutOfMemory.java:16)
Heap dump file created [8256217 bytes in 0.066 secs]

可以看到，当发生内存溢出时，会dump文件到java_pid34108.hprof。

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

这里显示：在线程中有个本地变量的总大小超过了内存的83.34%，这个肯定是很不合理的，这是非常有可能出现内存溢出的。然后下面的java.lang.Object[]也说明了是我们些的List<String>太大了，List的底层就是数据实现的。

点击Details查看详情：

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

6、jstack的使用

有些时候我们需要查看下JVM中的线程执行情况，比如，发现服务器的CPU的负载突然增高了、出现了死锁、死循环等，我们该如何分析呢？
由于程序是正常运行的，没有任何的输出，从日志方面也看不出什么问题，所以就需要看下jvm的内部线程的执行情况，然后再进行分析查找出原因。
这个时候，就需要借助于jstack命令了，jstack的作用是将正在运行的jvm的线程情况进行快照，并且打印出来：

用法：jstack <pid>

[root@image-server tmp]# jstack 3771
2019-06-26 23:54:24
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):

"http-bio-8080-exec-5" #24 daemon prio=5 os_prio=0 tid=0x00007fd178005000 nid=0x11d8 waiting on condition [0x00007fd180afb000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f66a94a8> (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)

"Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x00007fd168004000 nid=0xf8c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"http-bio-8080-exec-4" #22 daemon prio=5 os_prio=0 tid=0x00007fd1644d2000 nid=0xf49 waiting on condition [0x00007fd180cfd000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f66a94a8> (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-3" #21 daemon prio=5 os_prio=0 tid=0x00000000023f7000 nid=0xf48 waiting on condition [0x00007fd180dfe000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f66a94a8> (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-2" #20 daemon prio=5 os_prio=0 tid=0x00007fd178004000 nid=0xf47 waiting on condition [0x00007fd19493d000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f66a94a8> (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-1" #19 daemon prio=5 os_prio=0 tid=0x00007fd178003000 nid=0xf46 waiting on condition [0x00007fd19483c000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f66a94a8> (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)

"ajp-bio-8009-AsyncTimeout" #17 daemon prio=5 os_prio=0 tid=0x00007fd190422800 nid=0xecc waiting on condition [0x00007fd194124000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at org.apache.tomcat.util.net.JIoEndpoint$AsyncTimeout.run(JIoEndpoint.java:152)
        at java.lang.Thread.run(Thread.java:748)

"ajp-bio-8009-Acceptor-0" #16 daemon prio=5 os_prio=0 tid=0x00007fd190421800 nid=0xecb runnable [0x00007fd194225000]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
        at java.net.ServerSocket.implAccept(ServerSocket.java:545)
        at java.net.ServerSocket.accept(ServerSocket.java:513)
        at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
        at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:220)
        at java.lang.Thread.run(Thread.java:748)

"http-bio-8080-AsyncTimeout" #15 daemon prio=5 os_prio=0 tid=0x00007fd19041f800 nid=0xeca waiting on condition [0x00007fd194326000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at org.apache.tomcat.util.net.JIoEndpoint$AsyncTimeout.run(JIoEndpoint.java:152)
        at java.lang.Thread.run(Thread.java:748)

"http-bio-8080-Acceptor-0" #14 daemon prio=5 os_prio=0 tid=0x00007fd19041e000 nid=0xec9 runnable [0x00007fd194427000]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
        at java.net.ServerSocket.implAccept(ServerSocket.java:545)
        at java.net.ServerSocket.accept(ServerSocket.java:513)
        at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:60)
        at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:220)
        at java.lang.Thread.run(Thread.java:748)

"ContainerBackgroundProcessor[StandardEngine[Catalina]]" #13 daemon prio=5 os_prio=0 tid=0x00007fd19041c800 nid=0xec8 waiting on condition [0x00007fd194528000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1513)
        at java.lang.Thread.run(Thread.java:748)

"GC Daemon" #10 daemon prio=2 os_prio=0 tid=0x00007fd1903f9000 nid=0xec5 in Object.wait() [0x00007fd194eaa000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f5f83c00> (a sun.misc.GC$LatencyLock)
        at sun.misc.GC$Daemon.run(GC.java:117)
        - locked <0x00000000f5f83c00> (a sun.misc.GC$LatencyLock)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fd1900b4800 nid=0xec3 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fd1900b1800 nid=0xec2 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fd1900af000 nid=0xec1 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fd1900ad800 nid=0xec0 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fd19007a800 nid=0xebf in Object.wait() [0x00007fd195d63000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f5d2d250> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x00000000f5d2d250> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fd190078000 nid=0xebe in Object.wait() [0x00007fd195e64000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f5d2d408> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000f5d2d408> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007fd190009800 nid=0xebc runnable [0x00007fd197888000]
   java.lang.Thread.State: RUNNABLE
        at java.net.PlainSocketImpl.socketAccept(Native Method)
        at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
        at java.net.ServerSocket.implAccept(ServerSocket.java:545)
        at java.net.ServerSocket.accept(ServerSocket.java:513)
        at org.apache.catalina.core.StandardServer.await(StandardServer.java:453)
        at org.apache.catalina.startup.Catalina.await(Catalina.java:777)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:723)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:321)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455)

"VM Thread" os_prio=0 tid=0x00007fd19006e000 nid=0xebd runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007fd1900b7800 nid=0xec4 waiting on condition 

JNI global references: 23

6.1、线程的状态

在Java中线程的状态一共被分成6种：
1、初始态（NEW）
创建一个Thread对象，但还未调用start()启动线程时，线程处于初始态。

2、运行态（RUNNABLE）

在Java中，运行态包括 就绪态和运行态。
2.1 就绪态
该状态下的线程已经获得执行所需的所有资源，只要CPU分配执行权就能运行。
所有就绪态的线程存放在就绪队列中。
2.2 运行态
获得CPU执行权，正在执行的线程。
由于一个CPU同一时刻只能执行一条线程，因此每个CPU每个时刻只有一条运行态的线程。
3、阻塞态（BLOCKED）
当一条正在执行的线程请求某一资源失败时，就会进入阻塞态。
而在Java中，阻塞态专指请求锁失败时进入的状态。
由一个阻塞队列存放所有阻塞态的线程。
处于阻塞态的线程会不断请求资源，一旦请求成功，就会进入就绪队列，等待执行。
4、等待态（WAITING）
当前线程中调用wait、join、park函数时，当前线程就会进入等待态。
也有一个等待队列存放所有等待态的线程。
线程处于等待态表示它需要等待其他线程的指示才能继续运行。
进入等待态的线程会释放CPU执行权，并释放资源（如：锁）
5、超时等待态（TIMED_WAITING）
当运行中的线程调用sleep(time)、wait、join、parkNanos、parkUntil时，就会进入该状态；
它和等待态不一样，并不是因为请求不到资源，而是主动进入，并且进入后不需要其他线程唤醒；
进入该状态后释放CPU执行权和占有的资源。
与等待态的区别：到了超时时间后自动进入阻塞队列，开始竞争锁。
6、终止态（TERMINATED）
线程执行结束后的状态。

6.2、实战：死锁问题

如果在生产环境发生了死锁，我们将看到的是部署的程序没有任何反应了，这个时候我们可以借助jstack进行分析，下面我们实战下查找死锁的原因。

6.2.1、构造死锁

编写代码，启动2个线程，Thread1拿到了obj1锁，准备去拿obj2锁时，obj2已经被Thread2锁定，所以发生了死锁。

public class TestDeadLock {

    private static Object object1 = new Object();
    private static Object object2 = new Object();

    private static class Thread1 implements Runnable{
        @Override
        public void run() {
            synchronized (object1){
                System.out.println("Thread1 拿到了 object1 锁");
                try {
                    Thread.sleep(2000);//这里睡眠两秒是为了让另一个Thread2线程获取到object2锁
                }catch (Exception e){
                    e.printStackTrace();
                }
                synchronized (object2){
                    System.out.println("Thread1 拿到了 object2 锁");
                }
            }
        }
    }

    private static class Thread2 implements Runnable{
        @Override
        public void run() {
            synchronized (object2){
                System.out.println("Thread2 拿到了 object2 锁");
                try {
                    Thread.sleep(2000);//这里睡眠两秒是为了让另一个Thread1线程获取到object1锁
                }catch (Exception e){
                    e.printStackTrace();
                }
                synchronized (object1){
                    System.out.println("Thread2 拿到了 object1 锁");
                }
            }
        }
    }

    public static void main(String[] args) {
        new Thread(new Thread1()).start();
        new Thread(new Thread2()).start();
    }

}

然后我们在linux系统的/usr/local/src/java/下面创建一个文件：vim TestDeadLock.java，贴进去上面的代码；

执行javac TestDeadLock.java，编译，然后执行：java TestDeadLock运行，效果如下：

[root@image-server java]# java TestDeadLock
Thread1 拿到了 object1 锁
Thread2 拿到了 object2 锁

#这里发生了死锁，程序一直将等待下去

6.2.3、使用jstack进行分析

我们在linux连接上，另开一个窗口，执行命令：ps -ef | grep java 查看pid是：5063

然后我们执行：jstack 5063，结果如下：

2019-06-27 01:59:26
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):

"Attach Listener" #11 daemon prio=9 os_prio=0 tid=0x00007fe8d8001000 nid=0x1412 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" #10 prio=5 os_prio=0 tid=0x00007fe900009000 nid=0x13c8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #9 prio=5 os_prio=0 tid=0x00007fe9000e4000 nid=0x13d2 waiting for monitor entry [0x00007fe8f0efd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at TestDeadLock$Thread2.run(TestDeadLock.java:34)
        - waiting to lock <0x00000000f0a5cfb8> (a java.lang.Object)
        - locked <0x00000000f0a5cfc8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

"Thread-0" #8 prio=5 os_prio=0 tid=0x00007fe9000e2000 nid=0x13d1 waiting for monitor entry [0x00007fe8f0ffe000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at TestDeadLock$Thread1.run(TestDeadLock.java:17)
        - waiting to lock <0x00000000f0a5cfc8> (a java.lang.Object)
        - locked <0x00000000f0a5cfb8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007fe9000ce000 nid=0x13cf runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fe9000b1000 nid=0x13ce waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fe9000ae800 nid=0x13cd waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fe9000ad000 nid=0x13cc runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fe90007a000 nid=0x13cb in Object.wait() [0x00007fe904639000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f0a08ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x00000000f0a08ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fe900077800 nid=0x13ca in Object.wait() [0x00007fe90473a000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f0a06bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000f0a06bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=0 tid=0x00007fe90006d800 nid=0x13c9 runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007fe9000d1000 nid=0x13d0 waiting on condition 

JNI global references: 5


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00007fe8e40062c8 (object 0x00000000f0a5cfb8, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00007fe8e4004e28 (object 0x00000000f0a5cfc8, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at TestDeadLock$Thread2.run(TestDeadLock.java:34)
        - waiting to lock <0x00000000f0a5cfb8> (a java.lang.Object)
        - locked <0x00000000f0a5cfc8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at TestDeadLock$Thread1.run(TestDeadLock.java:17)
        - waiting to lock <0x00000000f0a5cfc8> (a java.lang.Object)
        - locked <0x00000000f0a5cfb8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

在输出的信息中，已经看到，发现了1个死锁，关键看这个：

"Thread-1":
        at TestDeadLock$Thread2.run(TestDeadLock.java:34)
        - waiting to lock <0x00000000f0a5cfb8> (a java.lang.Object)
        - locked <0x00000000f0a5cfc8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at TestDeadLock$Thread1.run(TestDeadLock.java:17)
        - waiting to lock <0x00000000f0a5cfc8> (a java.lang.Object)
        - locked <0x00000000f0a5cfb8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

可以清晰的看到：
Thread2获取了 <0x00000000f0a5cfb8> 的锁，等待获取 <0x00000000f0a5cfc8> 这个锁
Thread1获取了 <0x00000000f0a5cfc8> 的锁，等待获取 <0x00000000f0a5cfb8> 这个锁
由此可见，发生了死锁。

7、VisualVM工具的使用

VisualVM，能够监控线程，内存情况，查看方法的CPU时间和内存中的对象，已被GC的对象，反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。
VisualVM使用简单，几乎0配置，功能还是比较丰富的，几乎囊括了其它JDK自带命令的所有功能。主要功能如下：
内存信息
线程信息
Dump堆（本地进程）
Dump线程（本地进程）
打开堆Dump。堆Dump可以用jmap来生成。
打开线程Dump
生成应用快照（包含内存信息、线程信息等等）
性能分析。CPU分析（各个方法调用时间，检查哪些方法耗时多），内存分析（各类对象占用的内存，检查哪些类占用内存多）
……

7.1、启动

在jdk的安装目录的bin目录下，找到jvisualvm.exe，双击打开即可。

7.2、查看本地进程

7.3、查看CPU、内存、类、线程运行信息

7.4、查看线程详情

也可以点击右上角Dump按钮，将线程的信息导出，其实就是执行的jstack命令。

发现，显示的内容是一样的。

7.5、抽样器

抽样器可以对CPU、内存在一段时间内进行抽样，以供分析。

7.6、监控远程的jvm

VisualJVM不仅是可以监控本地jvm进程，还可以监控远程的jvm进程，需要借助于JMX技术实现。

7.6.1、什么是JMX？

JMX（Java Management Extensions，即Java管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。JMX可以跨越一系列异构操作系统平台、系统体系结构和网络传输协议，灵活的开发无缝集成的系统、网络和服务管理应用。

7.6.2、监控远程的tomcat

想要监控远程的tomcat，就需要在远程的tomcat进行对JMX配置，方法如下：

在tomcat的bin目录下，修改catalina.sh，添加如下的参数

JAVA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

#这几个参数的意思是：
#-Dcom.sun.management.jmxremote ：允许使用JMX远程管理
#-Dcom.sun.management.jmxremote.port=9999 ：JMX远程连接端口
#-Dcom.sun.management.jmxremote.authenticate=false ：不进行身份认证，任何用户都可以连接
#-Dcom.sun.management.jmxremote.ssl=false ：不使用ssl

保存退出，重启tomcat。重启之后tomcat的pid是5305

7.6.3、使用VisualJVM连接远程tomcat

添加远程主机：右键单击如下：

在一个主机下可能会有很多的jvm需要监控，所以接下来要在该主机上添加需要监控的jvm：

连接成功。使用方法和前面就一样了，就可以和监控本地jvm进程一样，监控远程的tomcat进程。

注意：我这一点还没实验成功，不知道是不是虚拟机的环境装错了。

以上内容都是来自传智播客的教程，自己做的笔记。

zdwhong

关注

2
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
JVM优化（一）

1、背景概述在本地开发环境我们一般都不需要进行JVM的调优，所以这块接触的肯定不多。但是在生产环境，可能就会遇见下面的情况：a、运行的应用“卡住了”，日志不输出，程序没有反应b、服务器的CPU负载突然升高c、在多线程应用下，如何分配线程的数量？……这个时候我们就需要对JVM进行优化，从而解决这些问题。环境准备：本次我们使用的是JDK1.8，以为JDK1.8和JDK1.7在内存模...
复制链接

扫一扫

专栏目录