• JVM性能调控检测相关指令


    jps

    作用:查看所有的jvm进程,包括进程ID,进程启动的路径等等

    原理:java程序在启动以后,会在java.io.tmpdir指定的目录下,就是临时文件夹里,生成一个类似于hsperfdata_User的文件夹,这个文件夹里(在Linux中为/tmp/hsperfdata_{userName}/),有几个文件,名字就是java进程的pid,因此列出当前运行的java进程,只是把这个目录里的文件名列一下而已。 至于系统的参数什么,就可以解析这几个文件获得。

    常用命令:

    jps 
    # 只显示pid,不显示class名称,jar文件名和传递给main 方法的参数
    jps -q
    # 输出传递给main 方法的参数
    jps -m
    # 输出应用程序main class的完整package名 或者 应用程序的jar文件完整路径名
    jps -l
    # 输出传递给JVM的参数 
    jps -v

    jstat

    作用:jstat利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控,包括了对进程的classloader,compiler,gc情况;一个极强的监视内存的工具,可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量,以及加载类的数量。

    常用命令:

    #命令格式
    jstat -<option> [-t] [-h<lines>] <pid> [<interval> [<count>]]
    #Option — 选项,我们一般使用 -gcutil 查看gc情况 选项option代表这用户希望查询的虚拟机信息,主要分为3类:类装载、垃圾收集和运行期编译状况;–class 监视类装载、卸载数量、总空间及类装载所耗费的时间 –gc 监视Java堆状况,包括Eden区、2个Survivor区、老年代、永久代等的容量 –gccapacity 监视内容与-gc基本相同,但输出主要关注Java堆各个区域使用到的最大和最小空间 –gcutil 监视内容与-gc基本相同,但输出主要关注已使用空间占总空间的百分比 –gccause 与-gcutil功能一样,但是会额外输出导致上一次GC产生的原因 –gcnew 监视新生代GC的状况 –gcnewcapacity 监视内容与-gcnew基本相同,输出主要关注使用到的最大和最小空间 –gcold 监视老年代GC的状况 –gcoldcapacity 监视内容与——gcold基本相同,输出主要关注使用到的最大和最小空间 –gcpermcapacity 输出永久代使用到的最大和最小空间 –compiler 输出JIT编译器编译过的方法、耗时等信息 –printcompilation 输出已经被JIT编译的方法
    #vmid — VM的进程号,即当前运行的java进程号
    #interval– 间隔时间,单位为秒或者毫秒
    #count — 打印次数,如果缺省则打印无数次
    
    #可以显示gc的信息,查看gc的次数,及时间。S0C 年轻代中第一个survivor(幸存区)的容量 (字节) S1C 年轻代中第二个survivor(幸存区)的容量 (字节) S0U 年轻代中第一个survivor(幸存区)目前已使用空间 (字节) S1U 年轻代中第二个survivor(幸存区)目前已使用空间 (字节) EC 年轻代中Eden(伊甸园)的容量 (字节) EU 年轻代中Eden(伊甸园)目前已使用空间 (字节) OC Old代的容量 (字节) OU Old代目前已使用空间 (字节) PC Perm(持久代)的容量 (字节) PU Perm(持久代)目前已使用空间 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 YGCT 从应用程序启动到采样时年轻代中gc所用时间(s) FGC 从应用程序启动到采样时old代(全gc)gc次数 FGCT 从应用程序启动到采样时old代(全gc)gc所用时间(s) GCT 从应用程序启动到采样时gc用的总时间(s)
    jstat -gc  pid
    #显示加载class的数量,及所占空间等信息。 Loaded 装载的类的数量 Bytes 装载类所占用的字节数 Unloaded 卸载类的数量 Bytes 卸载类的字节数 Time 装载和卸载类所花费的时间
    jstat –class pid
    #显示VM实时编译的数量等信息。Compiled 编译任务执行数量 Failed 编译任务执行失败数量 Invalid 编译任务执行失效数量 Time 编译任务消耗时间 FailedType 最后一个编译失败任务的类型 FailedMethod 最后一个编译失败任务所在的类及方法
    jstat -comilper pid
    #可以显示,VM内存中三代(young,old,perm)对象的使用和占用大小NGCMN 年轻代(young)中初始化(最小)的大小(字节) NGCMX 年轻代(young)的最大容量 (字节) NGC 年轻代(young)中当前的容量 (字节) S0C 年轻代中第一个survivor(幸存区)的容量 (字节) S1C 年轻代中第二个survivor(幸存区)的容量 (字节) EC 年轻代中Eden(伊甸园)的容量 (字节) OGCMN old代中初始化(最小)的大小 (字节) OGCMX old代的最大容量(字节) OGC old代当前新生成的容量 (字节) OC Old代的容量 (字节) PGCMN perm代中初始化(最小)的大小 (字节) PGCMX perm代的最大容量 (字节)PGC perm代当前新生成的容量 (字节) PC Perm(持久代)的容量 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 FGC 从应用程序启动到采样时old代(全gc)gc次数
    jstat -gccapacity pid
    # 统计gc信息 S0 年轻代中第一个survivor(幸存区)已使用的占当前容量百分比 S1 年轻代中第二个survivor(幸存区)已使用的占当前容量百分比 E 年轻代中Eden(伊甸园)已使用的占当前容量百分比 O old代已使用的占当前容量百分比 P perm代已使用的占当前容量百分比 YGC 从应用程序启动到采样时年轻代中gc次数 YGCT 从应用程序启动到采样时年轻代中gc所用时间(s) FGC 从应用程序启动到采样时old代(全gc)gc次数 FGCT 从应用程序启动到采样时old代(全gc)gc所用时间(s) GCT 从应用程序启动到采样时gc用的总时间(s)
    jstat -gcutil pid
    # 年轻代对象的信息 S0C 年轻代中第一个survivor(幸存区)的容量 (字节) S1C 年轻代中第二个survivor(幸存区)的容量 (字节) S0U 年轻代中第一个survivor(幸存区)目前已使用空间 (字节) S1U 年轻代中第二个survivor(幸存区)目前已使用空间 (字节) TT 持有次数限制 MTT 最大持有次数限制 EC 年轻代中Eden(伊甸园)的容量 (字节) EU 年轻代中Eden(伊甸园)目前已使用空间 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 YGCT 从应用程序启动到采样时年轻代中gc所用时间(s)
    jstat -gcnew pid
    # 年轻代对象的信息及其占用量 NGCMN 年轻代(young)中初始化(最小)的大小(字节) NGCMX 年轻代(young)的最大容量 (字节) NGC 年轻代(young)中当前的容量 (字节) S0CMX 年轻代中第一个survivor(幸存区)的最大容量 (字节) S0C 年轻代中第一个survivor(幸存区)的容量 (字节) S1CMX 年轻代中第二个survivor(幸存区)的最大容量 (字节) S1C 年轻代中第二个survivor(幸存区)的容量 (字节) ECMX 年轻代中Eden(伊甸园)的最大容量 (字节) EC 年轻代中Eden(伊甸园)的容量 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 FGC 从应用程序启动到采样时old代(全gc)gc次数
    jstat -gcnewcapacity pid 
    #old代对象的信息。  PC Perm(持久代)的容量 (字节) PU Perm(持久代)目前已使用空间 (字节) OC Old代的容量 (字节) OU Old代目前已使用空间 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 FGC 从应用程序启动到采样时old代(全gc)gc次数 FGCT 从应用程序启动到采样时old代(全gc)gc所用时间(s) GCT 从应用程序启动到采样时gc用的总时间(s)
    jstat -gcold pid
    #old代对象的信息及其占用量  OGCMN old代中初始化(最小)的大小 (字节) OGCMX old代的最大容量(字节) OGC old代当前新生成的容量 (字节) OC Old代的容量 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 FGC 从应用程序启动到采样时old代(全gc)gc次数 FGCT 从应用程序启动到采样时old代(全gc)gc所用时间(s) GCT 从应用程序启动到采样时gc用的总时间(s)
    jstat -gcoldcapacity pid
    #perm对象的信息及其占用量  PGCMN perm代中初始化(最小)的大小 (字节) PGCMX perm代的最大容量 (字节) PGC perm代当前新生成的容量 (字节) PC Perm(持久代)的容量 (字节) YGC 从应用程序启动到采样时年轻代中gc次数 FGC 从应用程序启动到采样时old代(全gc)gc次数 FGCT 从应用程序启动到采样时old代(全gc)gc所用时间(s) GCT 从应用程序启动到采样时gc用的总时间(s)
    jstat -gcpermcapacity pid
    #当前VM执行的信息 ompiled 编译任务的数目 Size 方法生成的字节码的大小 Type 编译类型 Method 类名和方法名用来标识编译的方法。类名使用/做为一个命名空间分隔符。方法名是给定类中的方法。上述格式是由-XX:+PrintComplation选项进行设置的
    jstat -printcompilation pid

    jmap

    作用:主要用于打印指定Java进程(或核心文件、远程调试服务器)的共享对象内存映射或堆内存细节。可以使用jmap生成Heap Dump

    备注: 最好不要在生产环境下使用

    常用命令:

    #查看java 堆(heap)使用情况
    jmap -heap pid
    #查看堆内存(histogram)中的对象数量及大小 如果jmap -histo:live 这个命令执行,JVM会先触发gc(生产慎用),然后再统计信息。
    jmap -histo pid
    #这个命令执行,JVM会将整个heap的信息dump写入到一个文件,heap如果比较大的话,就会导致这个过程比较耗时,并且执行的过程中为了保证dump的信息是可靠的,所以会暂停应用。
    jmap -dump:format=b,file=heapDump pid

    Jhat

    传送门

    jstack

    作用:观察jvm中当前所有线程的运行情况和线程当前状态;系统崩溃了?如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。系统hang 住了?jstack工具还可以附属到正在运行的java程序中,看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hang的状态,jstack是非常有用的。

    线程状态:

    NEW,未启动的。不会出现在Dump中。

    RUNNABLE,在虚拟机内执行的。

    BLOCKED,受阻塞并等待监视器锁。

    WATING,无限期等待另一个线程执行特定操作。

    TIMED_WATING,有时限的等待另一个线程的特定操作。

    TERMINATED,已退出的。

    调用修饰:

    表示线程在方法调用时,额外的重要的操作。线程Dump分析的重要信息。修饰上方的方法调用。

    locked <地址> 目标:使用synchronized申请对象锁成功,监视器的拥有者。

    waiting to lock <地址> 目标:使用synchronized申请对象锁未成功,在迚入区等待。

    waiting on <地址> 目标:使用synchronized申请对象锁成功后,释放锁幵在等待区等待。

    parking to wait for <地址> 目标

    线程动作:

    线程状态产生的原因

    runnable:状态一般为RUNNABLE。

    in Object.wait():等待区等待,状态为WAITING或TIMED_WAITING。

    waiting for monitor entry:进入区等待,状态为BLOCKED。

    waiting on condition:等待区等待、被park。

    sleeping:休眠的线程,调用了Thread.sleep()。

     

    可能看的出来的异常:

    wait on monitor entry: 被阻塞的,肯定有问题 (BLOCKED(on object monitor )--- waiting to lock)

    runnable : 注意IO线程[常见的jdbc连接阻塞]

    in Object.wait(): 注意非线程池等待 [WAITING (on object monitor)]

    常用指令:

    #查看
    jstack [-l|-m|-F] pid

    如何分析线程dump:

    原则:

    结合代码阅读的推理。需要线程Dump和源码的相互推导和印证。

    造成Bug的根源往往会在调用栈上直接体现,一定格外注意线程当前调用之前的所有调用。

    作者:donleo123
    本文如对您有帮助,还请多推荐下此文,如有错误欢迎指正,相互学习,共同进步。
  • 相关阅读:
    解决GitHub下载速度太慢的问题
    java监测硬盘空间大小
    @SuppressWarnings注解用法详解
    No goals have been specified for this build.
    java新建excel文件导出(HSSFWorkbook)
    mysql日志文件路径
    获取select框下option所有值
    jquery获取select选中的值
    mysql查看查询缓存是否启用
    Kafka消息重新发送
  • 原文地址:https://www.cnblogs.com/donleo123/p/15621368.html
Copyright © 2020-2023  润新知