JVM优化00

JVM优化

0.目标

  • 了解下我们为什么要学习JVM优化
  • 掌握jvm的运行参数以及参数的设置
  • 掌握jvm的内存模型(堆内存)
  • 掌握jmap命令的使用以及通过MAT工具进行分析
  • 掌握定位分析内存溢出的方法
  • 掌握jstack命令的使用
  • 掌握VisualJVM工具的使用

1.为什么学习JVM优化

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

  • 运行的应用“卡住了”,日志不输出,程序没有反应
  • 服务器CPU突然负载很高
  • 在多线程应用下,如何分配线程的数量?

我们不仅要让程序能跑起来,而且是可以跑的更快!可以分析解决在生产环境中所遇到的各种“棘手”的问题

2.jvm的运行参数

2.1 jvm的参数分三类

  • 标准参数

    • -help
    • -version
  • -X参数(非标准参数)

    • -Xint
    • -Xcomp
  • -XX参数(使用率较高)

    • -XX:newSize
    • -XX:+UseSerialGC

2.2 标准参数

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

案例1:-help和-version参数

[root@localhost ~]# java -help
[root@localhost ~]# java -version    ###查看jvm的版本# -showversion参数是表示,先打印版本信息,再执行后面的命令,在调试时非常有用,后面会使用到。

案例2:通过-D设置系统属性参数

public class test{public static void main(String[] args) {String str = System.getProperty("str");if (str == null) {System.out.println("woniu");} else {System.out.println(str);}}
}

进行编译、测试

[root@node01 test]# javac test.java
[root@node01 test]# java test
[root@node01 test]# java -Dstr=zhangsanfeng test

案例3:-server和-client参数

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

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

测试:

[root@localhost ~]# java -client  -showversion test
结果:
java version "1.8.0_301"
Java(TM) SE Runtime Environment (build 1.8.0_301-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.301-b09, mixed mode)woniu
[root@localhost ~]# java -server  -showversion test  ###结果和上面的一样
#由于机器是64位系统,所以不支持client模式

2.3 -X参数

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

[root@localhost ~]# 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:system(仅限 Linux)显示系统或容器配置并继续-XshowSettings:all显示所有设置并继续-XshowSettings:vm 显示所有与 vm 相关的设置并继续-XshowSettings:properties显示所有属性设置并继续-XshowSettings:locale显示所有与区域设置相关的设置并继续-X 选项是非标准选项。如有更改,恕不另行通知。

案例1:-Xint、-Xcomp、-Xmixed

  • 在解释模式(interpreted mode)下,-Xint标记会强制JVM执行所有的字节码,当然这会降低运行速度,通常低10倍或更多
  • -Xcomp(compile)参数与它(-Xint)正好相反,JVM在第一次使用时会把所有的字节码编译成本地代码,从而带来最大程度的优化。然而,很多应用在使用-Xcomp也会有一些性能损失,当然这比使用-Xint损失的少,原因是-Xcomp没有让JVM启用JIT编译器的全部功能。JIT编译器可以对是否需要编译做判断,如果所有代码都进行编译的话,对于一些只执行一次的代码就没有意义了
  • -Xmixed是混合模式,将解释模式与编译模式进行混合使用,由jvm自己决定,这是jvm默认的模式,也是推荐使用的模式
#强制设置为解释模式 
[root@node01 test]# java -showversion -Xint test  #强制设置为编译模式 
[root@node01 test]# java -showversion -Xcomp test
#注意:编译模式下,第一次执行会比解释模式下执行慢一些,注意观察#默认的混合模式 
[root@node01 test]# java -showversion test

2.4 -XX参数

案例1:-XX参数也是非标准参数,主要用于jvm的调优和debug操作

XX参数的使用有2种方式,一种是boolean类型,一种是非boolean类型:

  • boolean类型
    • 格式: -XX:[±]表示启用或者禁用属性
    • 如:-XX:+DisableExplicitGC 表示禁用手动调用gc操作,也就是说调用System.gc()无效
  • 非boolean类型
    • 格式:-XX:=表示属性的值为
    • 如:-XX:NewRatio=1 表示新生代和老年代的比值
[root@node01 test]# java -showversion -XX:+DisableExplicitGC test

案例2:-Xms和-Xmx参数:-Xms与-Xmx分别是设置jvm的堆内存的初始大小和最大大小。

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

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

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

[root@node01 test]# java -Xms512m -Xmx2048m test ###运行一个jar包
[root@node01 test]#nohup java -jar -Xms512m -Xmx2048m -XX:PermSize=64m -XX:MaxPermSize=128m  xx.jar &

**案例3:**运行java命令时打印出运行参数 -XX:+PrintFlagsFinal

[root@node01 test]#java -XX:+PrintFlagsFinal -version
[Global flags]
intx ActiveProcessorCount                      = -1                                  {product}
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 
..............................bool PrintFlagsFinal                          := true                                {product}bool PrintFlagsInitial                         = false                               {product}bool PrintGC                                   = false                               {manageable}bool PrintGCApplicationConcurrentTime          = false                               {product}bool PrintGCApplicationStoppedTime             = false                               {product}bool PrintGCCause                              = true                                {product}bool PrintGCDateStamps                         = false                               {manageable}bool PrintGCDetails                            = false                               {manageable}bool PrintGCID                                 = false                               {manageable}bool PrintGCTaskTimeStamps                     = false                               {product}bool PrintGCTimeStamps                         = false                               {manageable}bool PrintHeapAtGC                             = false                               {product rw}bool PrintHeapAtGCExtended                     = false                               {product rw}bool PrintHeapAtSIGBREAK                       = true                                {product}bool PrintJNIGCStalls                          = false ..........................

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

[root@node01 test]#java -XX:+PrintFlagsFinal -XX:+VerifySharedSpaces -version
[root@localhost ~]# java -XX:+PrintFlagsFinal -XX:+VerifySharedSpaces -version | grep PrintFlagsFinal

**案例4:**查看正在运行的jvm参数

在linux上启动tomcat

[root@localhost root]#jps    #通过jps 或者 jps -l 查看java进程
[root@localhost root]#jps -l
[root@localhost root]#jinfo -flags 8392  ####查看所有的参数,用法:jinfo -flags <jar的进程id>

3.jvm的内存模型

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

3.1 JDK1.7的堆内存情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5uMGwVTF-1687316984595)(assets/image-20220321171747053.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的堆内存情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-45b4mxiW-1687316984597)(assets/image-20220321172319640.png)]

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

年轻代:Eden + 2*Survivor

年老代:OldGen

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MMHqVeFX-1687316984598)(assets/image-20220321172405394.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 [-命令选项] [进程id] [间隔时间/毫秒] [查询次数]

案例1:查看class类加载统计

[root@localhost ~]# jps
[root@localhost ~]# jstat -class 8392   ##8392为进程idLoaded  Bytes  Unloaded  Bytes     Time   2858  5691.3        0     0.0     265.38

案例2:查看编译统计

[root@localhost ~]# jstat -compiler 8392Compiled Failed Invalid   Time   FailedType FailedMethod1753      1       0     2.18          1 org/apache/tomcat/util/IntrospectionUtils setProperty

案例3:垃圾回收统计

[root@localhost ~]# jstat -gc 8392S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
2048.0 2048.0 2048.0  0.0   16384.0  14615.8   40960.0    10140.7   17408.0 16779.3 2048.0 1879.2      4    0.033   0      0.000    0.033#也可以指定打印的间隔和次数,每1秒中打印一次,共打印5次
[root@node01 ~]# jstat -gc 8392 1000 5

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

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

4.1 查看内存使用情况

[root@localhost ~]# jmap -heap 8392
Attaching to process ID 8392, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.301-b09using thread-local object allocation.
Mark Sweep Compact GCHeap Configuration:   #堆内存的配置信息MinHeapFreeRatio         = 40MaxHeapFreeRatio         = 70MaxHeapSize              = 994050048 (948.0MB)NewSize                  = 20971520 (20.0MB)MaxNewSize               = 331350016 (316.0MB)OldSize                  = 41943040 (40.0MB)NewRatio                 = 2SurvivorRatio            = 8MetaspaceSize            = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize         = 17592186044415 MBG1HeapRegionSize         = 0 (0.0MB)Heap Usage:    # 堆内存的使用情况
New Generation (Eden + 1 Survivor Space):  #年轻代capacity = 18874368 (18.0MB)used     = 4340856 (4.139762878417969MB)free     = 14533512 (13.860237121582031MB)22.998682657877605% used
Eden Space:capacity = 16777216 (16.0MB)used     = 3042816 (2.90185546875MB)free     = 13734400 (13.09814453125MB)18.1365966796875% used
From Space:capacity = 2097152 (2.0MB)used     = 1298040 (1.2379074096679688MB)free     = 799112 (0.7620925903320312MB)61.89537048339844% used
To Space:capacity = 2097152 (2.0MB)used     = 0 (0.0MB)free     = 2097152 (2.0MB)0.0% used
tenured generation:#年老代capacity = 41943040 (40.0MB)used     = 11353328 (10.827377319335938MB)free     = 30589712 (29.172622680664062MB)27.068443298339844% used15693 interned Strings occupying 1516912 bytes.

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

#查看所有对象,包括活跃以及非活跃的
[root@localhost ~]# jmap -histo pid | more
#查看活跃对象
[root@localhost ~]# jmap -histo:live 8392 |morenum     #instances         #bytes  class name
----------------------------------------------1:         30459        3098384  [C2:          2075        2814168  [B3:          4476        1957032  [I4:         29962         719088  java.lang.String5:         15304         489728  java.util.HashMap$Node6:          4497         395736  java.lang.reflect.Method7:          3151         357264  java.lang.Class8:          3939         217352  [Ljava.lang.Object;9:          6467         206944  java.util.concurrent.ConcurrentHashMap$Node10:           918         169536  [Ljava.util.HashMap$Node;11:          1486          71328  java.util.HashMap12:          4145          66320  java.lang.Object13:            89          60016  [Ljava.util.concurrent.ConcurrentHashMap$Node;14:          2497          52912  [Ljava.lang.Class;15:          1598          51136  java.util.Hashtable$Entry16:           823          49456  [Ljava.lang.String;17:          1202          48080  java.lang.ref.Finalizer18:           908          43584  org.apache.tomcat.util.modeler.AttributeInfo19:           926          37040  java.util.TreeMap$Entry20:           602          28896  java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync21:          1175          28200  java.util.ArrayList22:           375          27000  java.util.logging.Logger23:           645          25800  java.lang.ref.SoftReference24:           761          24352  java.util.concurrent.locks.ReentrantLock$NonfairSync25:          1001          24024  java.util.LinkedList$Node

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

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

#语法
jmap -dump:format=b,file=dumpFileName <pid>     #b 表示二进制文件
[root@localhost ~]# jmap -dump:format=b,file=/tmp/dump.bat 8392

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

4.4 jhat命令对dump文件进行分析

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

#语法
jhat -port <port> file
[root@localhost tmp]# jhat -port 9999 /tmp/dump.bat

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

显示的内容如下:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QRnfFLyc-1687316984602)(assets/image-20220321192944341.png)]

点击进入,执行查询语句

select s from java.lang.String s where s.value.length>=1000

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aErJB5RA-1687316984603)(assets/image-20220321193050972.png)]

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

1.MAT工具介绍

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-InIjz0qd-1687316984605)(assets/image-20220321193449603.png)]

2.下载安装

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ty9ZYFhh-1687316984605)(assets/image-20220321193600998.png)]

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dEy0EpQS-1687316984606)(assets/image-20220321194706698.png)]

3.使用

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bs1XYlvn-1687316984608)(assets/image-20220321194732713.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FzEqT60j-1687316984610)(assets/image-20220321194750650.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7lNhOZpp-1687316984610)(assets/image-20220321195018313.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-y3wPuPur-1687316984611)(assets/image-20220321195258758.png)]

如:直接输入char回车

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jWhAmNab-1687316984612)(assets/image-20220321195416409.png)]

查看对象以及它的依赖:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lrQT4mTB-1687316984613)(assets/image-20220321195504775.png)]

Shallow Heap:表示对象本身占用内存的大小,也就是对象头加成员变量(不是成员变量的值)的总和

retained heap:如果这个对象被删除了(GC回收掉),能节省出多少内存

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uQRxVLqV-1687316984613)(assets/image-20220321195812436.png)]

5.实战:内存溢出的定位与分析

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

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

5.1 内存溢出场景

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

import java.util.*;
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编辑器。添加add VM options参数

#参数如下: -Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

运行一段时间,结果如下:

可以看到,当发生内存溢出时,会自动dump文件到项目的根目录,自动生成一个文件java_pid10864.hprof。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9FFNoDkU-1687316984614)(assets/image-20220321201358463.png)]

5.2 导入到MAT工具中进行分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-82Iq6b4D-1687316984615)(assets/image-20220321201605434.png)]

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

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

查看详情:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UfbHluOi-1687316984616)(assets/image-20220321201958188.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-US3vblek-1687316984616)(assets/image-20220321202034427.png)]

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

6.jstack的使用

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

#用法:jstack <pid>
[root@localhost ~]# jstack 8392

6.1线程的状态

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QBjVDdHX-1687316984617)(assets/image-20220321202428535.png)]

在Java中线程的状态一共被分成6种:

  • 初始态(NEW):创建一个Thread对象,但还未调用start()启动线程时,线程处于初始态。

  • 运行态(RUNNABLE):在Java中,运行态包括 就绪态 和 运行态。

    • 就绪态:该状态下的线程已经获得执行所需的所有资源,只要CPU分配执行权就能运行,所有就绪态的线程存放在就绪队列中
    • 运行态:获得CPU执行权,正在执行的线程,由于一个CPU同一时刻只能执行一条线程,因此每个CPU每个时刻只有一条运行态的线程
  • 阻塞态(BLOCKED):

    • 当一条正在执行的线程请求某一资源失败时,就会进入阻塞态。
    • 而在Java中,阻塞态专指请求锁失败时进入的状态。
    • 由一个阻塞队列存放所有阻塞态的线程。
    • 处于阻塞态的线程会不断请求资源,一旦请求成功,就会进入就绪队列,等待执行。
  • 等待态(WAITING)

    • 当前线程中调用wait、join、park函数时,当前线程就会进入等待态。
    • 也有一个等待队列存放所有等待态的线程。
    • 线程处于等待态表示它需要等待其他线程的指示才能继续运行。
    • 进入等待态的线程会释放CPU执行权,并释放资源(如:锁)
  • 超时等待态(TIMED_WAITING)

    • 当运行中的线程调用sleep(time)、wait、join、parkNanos、parkUntil时,就会进入该状态;
    • 它和等待态一样,并不是因为请求不到资源,而是主动进入,并且进入后需要其他线程唤醒;
    • 进入该状态后释放CPU执行权 和 占有的资源。
    • 与等待态的区别:到了超时时间后自动进入阻塞队列,开始竞争锁。
  • 终止态(TERMINATED)

    • 线程执行结束后的状态

6.2 死锁的问题

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

1、代码

public class TestDeadLock {private static Object obj1 = new Object();private static Object obj2 = new Object();public static void main(String[] args) {new Thread(new Thread1()).start();new Thread(new Thread2()).start();}private static class Thread1 implements Runnable {@Overridepublic void run() {synchronized (obj1) {System.out.println("Thread1 拿到了 obj1 的锁!");try {// 停顿2秒的意义在于,让Thread2线程拿到obj2的锁Thread.sleep(2000);} catch (InterruptedException e) {e.printStackTrace();}synchronized (obj2) {System.out.println("Thread1 拿到了 obj2 的锁!");}}}}private static class Thread2 implements Runnable {@Overridepublic void run() {synchronized (obj2) {System.out.println("Thread2 拿到了 obj2 的锁!");try {// 停顿2秒的意义在于,让Thread1线程拿到obj1的锁Thread.sleep(2000);} catch (InterruptedException e) {e.printStackTrace();}synchronized (obj1) {System.out.println("Thread2 拿到了 obj1 的锁!");}}}}
}

2、在linux上运行

[root@localhost ~]# javac TestDeadLock.java
[root@localhost ~]# java TestDeadLock###结果
Thread1 拿到了 obj1 的锁!
Thread2 拿到了 obj2 的锁!

6.3 使用jstack进行分析

[root@localhost ~]# jstack 9516

从输出的日志信息中大家重点看后面的内容

可以清晰的看到:

Thread1获取了 <0x00000000c4c5b5f8> 的锁,等待获取 <0x00000000c4c5b608> 这个锁;Thread0获取了 <0x00000000c4c5b608> 的锁,等待获取 <0x00000000c4c5b5f8> 这个锁。由此可见,发生了死锁

7.VirtualVM工具使用

VisualVM,能够监控线程,内存情况,查看方法的CPU时间和内存中的对象,已被GC的对象,反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。VisualVM使用简单,几乎0配置,功能还是比较丰富的,几乎囊括了其它JDK自带命令的所有功能。

  • 内存信息
  • 线程信息
  • Dump堆(本地进程)
  • Dump线程(本地进程)
  • 打开堆Dump。堆Dump可以用jmap来生成。
  • 打开线程Dump
  • 生成应用快照(包含内存信息、线程信息等等)
  • 性能分析
  • CPU分析(各个方法调用时间,检查哪些方法耗时多)
  • 内存分析(各类对象占用的内存,检查哪些类占用内存多)
  • ……

7.1 启动VirtualVM

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8jvNzRJv-1687316984618)(assets/image-20220322114730513.png)]

7.2 查看本地jvm进程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xzuBjdt3-1687316984619)(assets/image-20220322115116829.png)]

查看用idea工具编写的死锁案例

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aL6erpWQ-1687316984619)(assets/image-20220322115313017.png)]

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

1、查看cpu、内存、类情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ik8YgeF6-1687316984620)(assets/image-20220322115543948.png)]

2、查看线程运行情况

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V71P33CH-1687316984621)(assets/image-20220322115708090.png)]

也可以点击右上角Dump按钮,将线程的信息导出,其实就是执行的jstack命令,截取部分图片

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WlD4DspD-1687316984622)(assets/image-20220322120019174.png)]

发现,显示的内容是一样的

7.4 抽样器

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OwDsqBil-1687316984622)(assets/image-20220322120136012.png)]

7.5 监控远程的JVM

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

1.jmx的概念

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

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

#在tomcat的bin目录下,修改catalina.sh(脚本catalina.sh用于启动和关闭tomcat服务器,是最关键的脚本,另外的脚本startup.sh和shutdown.sh都是使用不同的参数调用了该脚本),添加如下的参数:JAVA_OPTS="-Djava.rmi.server.hostname=192.172.0.5 -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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hh4VelqW-1687316984623)(assets/image-20220322145019974.png)]

保存退出,启动tomcat。

2.使用VirtualVM工具远程连接

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lARoGUTk-1687316984624)(assets/image-20220322121546378.png)]

在一个主机下可能会有很多的jvm需要监控,所以接下来要在该主机上添加需要监控的jvm:右键单击

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5PDPrhy9-1687316984625)(assets/image-20220322142818880.png)]

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

3.jmx监控springboot的jar

java -jar -Djava.rmi.server.hostname="192.172.0.5" -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port="9999" -Dcom.sun.management.jmxremote.authenticate="false" -Dcom.sun.management.jmxremote.ssl="false" aaa.jar

其它方式都一样,略

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gTBs5RBF-1687316984625)(C:\Users\ThinkPad\AppData\Roaming\Typora\typora-user-images\image-20230209133139871.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mknk16DY-1687316984627)(C:\Users\ThinkPad\AppData\Roaming\Typora\typora-user-images\image-20230209135825718.png)]

本文链接:https://my.lmcjl.com/post/2656.html

展开阅读全文

4 评论

留下您的评论.