JVM性能调优工具——大全

最新推荐文章于 2024-09-03 22:43:21 发布
最新推荐文章于 2024-09-03 22:43:21 发布
阅读量479 收藏 1
点赞数 1
分类专栏： jvm 文章标签： jvm java 堆栈
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/shixiaoling123/article/details/106877342
版权

JVM常用工具


本博客内容参考：《大型分布式网站架构设计与实现》
JDK自身提供了一系列的Java故障排查工具，虽然简单，但是进行在线故障排查时却十分有用；

1. jps

jps命令用来输出JVM虚拟机进程的一些信息，有点类似于Linux的ps命令，可以列出虚拟机当前正在执行的进程，并显示其主类和进程的ID

1.1 jps的用法

在这里插入图片描述

1.2 jps命令的一些选项
  • -q：只输出进程ID的名称，而省略主类的名称；
  • -m：输出进程启动时传递给main函数的参数；
  • -l：输出主类的全名，如果执行的是jar文件，则输出jar文件的路径；
  • -v：输出虚拟机进程启动时所带的JVM参数；

2. jstat

jstat是一个可以用来对虚拟机各种运行状态进行监控的工具，通过它可以查看到虚拟机的类加载与卸载情况，管理内存使用和垃圾收集等信息，监视JIT即时编译器的运行情况等，几乎包括了JVM运行的方方面面；

2.1 jstat命令的一些选项
  • -class：用来查看类加载的统计信息；
  • -compiler：用来查看即时编译器编译相关信息的统计；
  • -gc：用来查看JVM中垃圾收集情况的统计信息，包括Eden区，2个Survivor区域，老年代永久代的容量和已用空间，GC时间；
  • -gccapacity：用来查看新生代、老年代和永久代的存储容量；
  • -gcutil：用来查看新生代、老年代和持久化的垃圾收集情况；
  • -gccause：用来查看垃圾收集的统计情况，并且显示最后一次及当前正在发生的垃圾收集的原因；
  • -gcnew：用来查看新生代垃圾收集情况；
  • -gcnewcapacity：用来查看新生代存储容量的情况；
  • -gcold：用来查看老年代和持久代发生的GC情况；
  • -gcoldcapacity：用来查看老年代的容量；
  • -gcmetacapacity :用来查看永生代的容量；
  • -printcompilation：用来查看通过JIT编译过的方法；
2.2 常用的方法

这些命令都有一些非常好用的功能：
比如：jstat -gc 1234 1000 10
1000：表示1秒输出一次；
10：表示总共输出10次；
也可以这样用：jstat -gc 1234 1000 10 >> test.log

-class：用来查看类加载的统计信息
通过jps -l 查出需要查看的pid
在这里插入图片描述

  • Loaded : 加载class的数量
  • Bytes : class字节大小
  • Unloaded : 未加载class的数量
  • Bytes : 未加载class的字节大小
  • Time : 加载时间

-compiler：用来查看即时编译器编译相关信息的统计
在这里插入图片描述

  • Compiled : 编译数量
  • Failed : 编译失败数量
  • Invalid : 无效数量
  • Time : 编译耗时
  • FailedType : 失败类型
  • FailedMethod : 失败方法的全限定名

-gc：用来查看JVM中垃圾收集情况的统计信息，包括Eden区，2个Survivor区域，老年代永久代的容量和已用空间，GC时间
在这里插入图片描述

C即Capacity 总容量，U即Used 已使用的容量

  • S0C : survivor0区的总容量
  • S1C : survivor1区的总容量
  • S0U : survivor0区已使用的容量
  • S1U : survivor1区已使用的容量
  • EC : Eden区的总容量
  • EU : Eden区已使用的容量
  • OC : Old区的总容量
  • OU : Old区已使用的容量
  • PC 当前perm的容量 (KB)
  • PU perm的使用 (KB)
  • YGC : 新生代垃圾回收次数
  • YGCT : 新生代垃圾回收时间
  • FGC : 老年代垃圾回收次数
  • FGCT : 老年代垃圾回收时间
  • GCT : 垃圾回收总消耗时间

-gccapacity：用来查看新生代、老年代和永久代的存储容量
在这里插入图片描述

  • NGCMN : 新生代占用的最小空间
  • NGCMX : 新生代占用的最大空间
  • OGCMN : 老年代占用的最小空间
  • OGCMX : 老年代占用的最大空间
  • OGC：当前年老代的容量 (KB)
  • OC：当前年老代的空间 (KB)
  • PGCMN : perm占用的最小空间
  • PGCMX : perm占用的最大空间

-gcutil：用来查看新生代、老年代和持久化的垃圾收集情况
在这里插入图片描述

  • S0：幸存1区当前使用比例
  • S1：幸存2区当前使用比例
  • E：伊甸园区使用比例
  • O：老年代使用比例
  • M：元数据区使用比例
  • CCS：压缩使用比例
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

-gccause：用来查看垃圾收集的统计情况，并且显示最后一次及当前正在发生的垃圾收集的原因
在这里插入图片描述

  • LGCC：最近垃圾回收的原因
  • GCC：当前垃圾回收的原因

-gcnew：用来查看新生代垃圾收集情况
在这里插入图片描述

  • S0C：第一个幸存区大小
  • S1C：第二个幸存区的大小
  • S0U：第一个幸存区的使用大小
  • S1U：第二个幸存区的使用大小
  • TT:对象在新生代存活的次数
  • MTT:对象在新生代存活的最大次数
  • DSS:期望的幸存区大小
  • EC：伊甸园区的大小
  • EU：伊甸园区的使用大小
  • YGC：年轻代垃圾回收次数
  • YGCT：年轻代垃圾回收消耗时间

-gcnewcapacity：用来查看新生代存储容量的情况
在这里插入图片描述

  • NGCMN：新生代最小容量
  • NGCMX：新生代最大容量
  • NGC：当前新生代容量
  • S0CMX：最大幸存1区大小
  • S0C：当前幸存1区大小
  • S1CMX：最大幸存2区大小
  • S1C：当前幸存2区大小
  • ECMX：最大伊甸园区大小
  • EC：当前伊甸园区大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代回收次数

-gcold：用来查看老年代和持久代发生的GC情况
在这里插入图片描述

  • MC：方法区大小
  • MU：方法区使用大小
  • CCSC:压缩类空间大小
  • CCSU:压缩类空间使用大小
  • OC：老年代大小
  • OU：老年代使用大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

-gcoldcapacity：用来查看老年代的容量
在这里插入图片描述

  • OGCMN：老年代最小容量
  • OGCMX：老年代最大容量
  • OGC：当前老年代大小
  • OC：老年代大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

-gcmetacapacity：用来查看持久代的容量
在这里插入图片描述

  • MCMN:最小元数据容量
  • MCMX：最大元数据容量
  • MC：当前元数据空间大小
  • CCSMN：最小压缩类空间大小
  • CCSMX：最大压缩类空间大小
  • CCSC：当前压缩类空间大小
  • YGC：年轻代垃圾回收次数
  • FGC：老年代垃圾回收次数
  • FGCT：老年代垃圾回收消耗时间
  • GCT：垃圾回收消耗总时间

-printcompilation：用来查看通过JIT编译过的方法
hotspot编译方法统计

  • Compiled：被执行的编译任务的数量
  • Size：方法字节码的字节数
  • Type：编译类型
  • Method：编译方法的类名和方法名。

3. jinfo

jinfo命令主要用于查看应用程序的配置参数，以及打印运行JVM时所指定的JVM参数；
-flag : 输出指定args参数的值
-flags : 不需要args参数，输出所有JVM参数的值
-sysprops : 输出系统属性，等同于System.getProperties()

3.1 常用参数

-sysprops：显示System.getProperties()相关参数，还可以显示未被指定的JVM参数的默认值；

4. jstack

jstack命令用来生成虚拟机当前的线程快照信息，线程快照就是当前虚拟机每一个线程正在执行的方法堆栈的集合；

4.1 常用参数

-F : 当正常输出请求不被响应时，强制输出线程堆栈
-l : 除堆栈外，显示关于锁的附加信息
-m : 如果调用到本地方法的话，可以显示C/C++的堆栈

4.2 案例

jstack -l 13352

2020-06-20 22:14:16
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000002c1c800 nid=0x4b08 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"线程B：" #12 prio=5 os_prio=0 tid=0x0000000019567000 nid=0x1354 waiting for monitor entry [0x000000001a3ef000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.example.demo.jvm.Lock2.run(JconsoleTest.java:44)
        - waiting to lock <0x00000000d60b7028> (a java.lang.String)
        - locked <0x00000000d60b7060> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - None

"线程A：" #11 prio=5 os_prio=0 tid=0x0000000019566000 nid=0x52fc waiting for monitor entry [0x000000001a2ef000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.example.demo.jvm.Lock1.run(JconsoleTest.java:26)
        - waiting to lock <0x00000000d60b7060> (a java.lang.String)
        - locked <0x00000000d60b7028> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - None

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000000019497000 nid=0x4f0c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C1 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x0000000019403000 nid=0x29ac waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x0000000019401000 nid=0x4bb8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x0000000019400800 nid=0x6f4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x00000000191e5000 nid=0x1a3c runnable [0x0000000019cef000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:150)
        at java.net.SocketInputStream.read(SocketInputStream.java:121)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x00000000d5fa79f8> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x00000000d5fa79f8> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

   Locked ownable synchronizers:
        - None

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000018e33000 nid=0x2a40 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

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

   Locked ownable synchronizers:
        - None

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000002f03800 nid=0x1544 in Object.wait() [0x0000000018def000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d5b86280> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
        - locked <0x00000000d5b86280> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

   Locked ownable synchronizers:
        - None

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000002efe000 nid=0x2fcc in Object.wait() [0x0000000018cef000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000d5b85cf0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
        - locked <0x00000000d5b85cf0> (a java.lang.ref.Reference$Lock)

   Locked ownable synchronizers:
        - None

"VM Thread" os_prio=2 tid=0x0000000017a55000 nid=0x860 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000002e2b800 nid=0x1a8 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000002e2d000 nid=0x5260 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000002e2e800 nid=0x16b0 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002e30000 nid=0x3e4c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001949a800 nid=0x4eb0 waiting on condition

JNI global references: 34


Found one Java-level deadlock:
=============================
"线程B：":
  waiting to lock monitor 0x0000000017a5bd18 (object 0x00000000d60b7028, a java.lang.String),
  which is held by "线程A："
"线程A：":
  waiting to lock monitor 0x0000000017a5e708 (object 0x00000000d60b7060, a java.lang.String),
  which is held by "线程B："

Java stack information for the threads listed above:
===================================================
"线程B：":
        at com.example.demo.jvm.Lock2.run(JconsoleTest.java:44)
        - waiting to lock <0x00000000d60b7028> (a java.lang.String)
        - locked <0x00000000d60b7060> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:745)
"线程A：":
        at com.example.demo.jvm.Lock1.run(JconsoleTest.java:26)
        - waiting to lock <0x00000000d60b7060> (a java.lang.String)
        - locked <0x00000000d60b7028> (a java.lang.String)
        at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

可以看出，上面的案例，有死锁发生；

5. jmap

jmap可以用来查看等待回收对象的队列，查看堆的概要信息，包括采用的是哪种GC收集器，堆空间的使用情况，以及通过JVM参数指定的各个内存空间的大小等；

jmap执行堆dump操作时，由于生成的转储文件较大，将耗费大量的系统资源，可能会造成短时间内系统无法响应的情况出现；

5.1 常用参数
  • dump:[live,]format=b,file= : 生成堆转储快照
  • finalizerinfo : 显示在F-Queue队列等待Finalizer线程执行finalizer方法的对象
  • heap : 用来打印堆的概要信息，包括使用回收器的类型，堆的配置信息，各内存分代的空间使用情况；
  • histo[:live] : 显示堆中对象的统计信息
  • permstat : 用来打印出每个ClassLoader和该ClassLoader所加载的class数量；
  • F : 当-dump没有响应时，强制生成dump快照
5.2 案例

-heap：用来打印堆的概要信息

jmap -heap 13352
using thread-local object allocation.
Parallel GC with 4 thread(s)	// GC方式

Heap Configuration:					//堆内存初始化配置
   MinHeapFreeRatio         = 0                     //-XX:MinHeapFreeRatio设置JVM堆最小空闲比率
   MaxHeapFreeRatio         = 100                   //-XX:MaxHeapFreeRatio设置JVM堆最大空闲比率
   MaxHeapSize              = 2132803584 (2034.0MB) //-XX:MaxHeapSize=设置JVM堆的最大大小
   NewSize                  = 44564480 (42.5MB)     //-XX:NewSize=设置JVM堆的'新生代'的默认(起始)大小
   MaxNewSize               = 710934528 (678.0MB)   //-XX:MaxNewSize=设置JVM堆的'新生代'的最大大小
   OldSize                  = 89653248 (85.5MB)     //-XX:OldSize=设置JVM堆的'老年代'的大小
   NewRatio                 = 2                     //-XX:NewRatio=:'新生代'和'老年代'的大小比率1:2
   SurvivorRatio            = 8                     //-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值8:1:1
   MetaspaceSize            = 21807104 (20.796875MB)//-XX:MaxPermSize=256m 设置元空间大小
   CompressedClassSpaceSize = 1073741824 (1024.0MB) 
   MaxMetaspaceSize         = 17592186044415 MB	    // -XX:MaxMetaspaceSize= :设置JVM堆的‘元空间’的最大大小
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:                                    //堆内存使用情况
PS Young Generation                            //新生代
Eden Space:                                    //Eden区分布 
   capacity = 176160768 (168.0MB)              //总空间
   used     = 6222416 (5.9341583251953125MB)   //已用空间
   free     = 169938352 (162.0658416748047MB)  //空闲空间
   3.532237098330543% used                     //使用比率        
From Space:                                    //survivor From区分布
   capacity = 16777216 (16.0MB)                
   used     = 0 (0.0MB)                        
   free     = 16777216 (16.0MB)                
   0.0% used                                   
To Space:                                      //survivor To区分布
   capacity = 17301504 (16.5MB)
   used     = 0 (0.0MB)
   free     = 17301504 (16.5MB)
   0.0% used
PS Old Generation                              //老年代分布
   capacity = 164626432 (157.0MB)
   used     = 17516744 (16.70526885986328MB)
   free     = 147109688 (140.29473114013672MB)
   10.640298636855594% used

-dump：生成堆快照
jmap -dump:live,format=b,file=dump.hprof 13352

Louis.No1
关注
专栏目录
JVM性能调优实战——UseParallelGC
augsm的专栏
10-25 1万+
前言 在生产环境中，你是否遇到过这样的问题？ 1）系统运行一段时间后old区空间正逐渐减少？ 2）遇到秒杀促销活动等场景old区存储突然暴增，导致JVM Full GC。fgc time持续过长导致cpu 100%？ 3）jvm eden区分配的内存实际并没有按照配置的指定？survivor区对象晋升到old区并没有达到默认的15次？ 4）如何避免Full GC，JVM产生FGC后如何解决？ …… 接下来的内容，我将从实际场景出发，分别使用三种垃圾收集器：ParallelGC,Concurrent Mar.
JVM性能调优（4）——性能调优工具
javalingyu的博客
05-26 1477
目录 一、JDK工具1、JDK工具2、利用 jps 找出进程3、利用 jstat 查看VM统计信息4、利用 jmap 查看对象分布情况5、利用 jstack 分析线程栈 二、Linux 命令行工具1、top 命令2、vmstat 命令3、pidstat 命令 三、可视化工具1、jvisualvm — JVM监控3、GCViewer — 离线分析GC日志4、GCeasy — 在线分析GC日志5、FastThread — 分析线程栈6、MAT — 分析堆转储文件7、性能调优工具8、JVM监控平台 四、利
JVM调优工具分享
12-10
JVM调优工具分享
JVM性能调优监控工具专题一：JVM自带性能调优工具（jps,jstack,jmap,jhat,jstat,hprof)...
Josh_Persistence
11-29 2086
前提概要：         JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。   现实企业级Jav...
5款强大的JVM 性能调优监控工具 ！
最新发布
2401_85154718的博客
09-03 909
l long listings，会打印出额外的锁信息，在发生死锁时可以用jstack -l pid来观察锁持有情况-m mixed mode，不仅会输出Java堆栈信息，还会输出C/C++堆栈信息（比如Native方法）interval是采样时间间隔。下面我们来一个实例找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用。
jvm系列(七):jvm调优-工具篇
weixin_33722405的博客
01-02 2488
16年的时候花了一些时间整理了一些关于jvm的介绍文章,到现在回顾起来还是一些还没有补充全面，其中就包括如何利用工具来监控调优前后的性能变化。工具做为图形化界面来展示更能直观的发现问题，另一方面一些耗费性能的分析（dump文件分析）一般也不会在生产直接分析，往往dump下来的文件达1G左右，人工分析效率较低，因此利用工具来分析jvm相关问题，长长可以到...
JVM调优工具
xmh_sxh_1314的博客
03-28 625
常用的JVM调优工具：Jconsole，jProfile，VisualVMJconsole : jdk自带，功能简单，但是可以在系统有一定负荷的情况下使用。对垃圾回收算法有很详细的跟踪。详细说明参考这里JProfiler：商业软件，需要付费。功能强大。详细说明参考这里VisualVM：JDK自带，功能强大，与JProfiler类似。推荐。 调优的方法观察内存释放情况、集合类检查、对象树上面这些调...
jvm 调优工具
qq_43012298的博客
03-14 804
JVM调优是一个专业且复杂的任务，它通常涉及到监控、分析和调整JVM的运行时参数以优化应用程序的性能。虽然JVM调优工具本身的“源码”不是公开的内容，但这些工具基于JVM提供的公开接口和监控数据工作。
JVM常用调优参数 ——JVM篇
egekm_sefg的博客
10-25 301
通过这些参数可以对JVM的内存分配做调整Xms堆区初始值-Xms2g或Xmx堆区最大值-Xmx2g或Xmn新生代最大值-Xmn512m或PermSize(JDK1.8以后已废弃)永久代初始大小(JDK1.8以后已废弃)永久代最大值(JDK1.8以后用于替换PermSize)元数据区初始大小(JDK1.8以后用于替换MaxPermSize)元数据区最大值Xss线程栈最大值-Xss256k或最大直接内存（堆外）大小。
JAVA JVM性能调优监控工具详解
04-18
本文将详细介绍几种常见的JVM性能调优工具，并通过实际案例帮助读者更好地理解和应用这些工具。 #### 一、jps (Java Virtual Machine Process Status Tool) `jps`是JDK自带的一个简单实用的工具，用于列出当前正在...
Java性能调优实战——覆盖80%以上的Java应用调优场景
04-10
开篇词讲怎样才能做好性能调优02讲如何制定性能调优策略04讲慎重使用正则表达式05讲ArrayList还是LinkedList使用不当性能差千倍07讲深入浅出HashMap的设计与优化08讲网络通信优化之IO模型：如何解决高并发下IO瓶颈09...
JVM调优-工具
IT蜗牛的专栏
03-12 4164
一、JDK内置工具 1.监控工具 jps jstat 2.故障排除工具 jinfo jmap jstack jcmd jhat jhsdb 3.可视化工具 jhsdb jconsole visualvm java mission control 二、第三方工具 memo...
jvm调优工具
大梦的专栏
05-31 835
jps是JVM的一个常用命令，类似linux中的ps命令。jps是查看java进程信息的命令；ps是查看linux系统中进程的命令 格式 jps [ options ] [ hostid ] 参数说明 options -q 只输出java进程的进程id -l 输出java进程的进程id和main方法的类全名 ...
JVM调优之JVM自带性能调优工具
qq_39093474的博客
09-01 1733
前言 JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat、hprof等小巧的工具，每一种工具都有其自身的特点，用户可以根据你需要检测的应用或者程序片段的状况，适当的选择相应的工具进行检测。接下来的两个专题分别会讲VisualVM的具体应用。 现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention）
jvm 性能监控 调优工具
卖克的专栏
02-08 2757
1.jps 查看java的进程 栗子， 2.jstack id，查看进程的栈信息 栗子， 3.taskkill -f -t -im  id，关闭线程 栗子：
38_JVM 调优的工具有哪些？
aofengchuang的博客
08-22 235
JDK自带了很多监控工具，都位于JDK的bin目录下， 其中最常用的是jconsole和jvisualvm 这两款视图监控工具。 1.jconsole：用于对 JVM 中的内存、线程和类等进行监控； 2.jvisualvm：JDK 自带的全能分析工具， 可以分析：内存快照、线程 快照、程序死锁、监控内存的变化、gc 变化等 JDK自带了很多监控工具，都位于JDK的bin目录下， 其中最常用的是jconsole和jvisualvm 这两款视图监控工具 1.jconsole：用于对 JVM 中的
JProfiler 11：详解性能调优与内存分析实战指南
第3章——JVM性能监控： 从数据记录开始，这部分阐述了如何启动和配置JProfiler来捕获关键性能指标，如CPU使用率、方法调用、内存消耗等。 第4章——内存分析： JProfiler的内存剖析功能深入浅出，包括内存快照功能...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值