命令行 jvm调优工具

java -XX:+PrintFlagsInitial :查看所有JVM参数启动的初始值

java -XX:+PrintFlagsFinal :查看所有JVM参数的最终值

java -参数名称:+PrintCommandLineFlags :查看那些已经被用户或者JVM设置过的详细的XX参数的名称和值



jps:java process Status 


1)jps:查看当前运行中java的线程

2)jps -q :仅显示进程ID

3)jps -l :输出进程ID和程序的全类名,如果是jar包输出jar完整路径

4)jps -m:输出进程启动时传递给main()的参数

5)jps -v:列出进程启动时的JVM参数,比如 -Xms20m

如果某java进程关闭了默认开启的UsePerfData参数(-XX:-UsePerfData),那jps将无法知道该进程




jstat:JVM Statistics Monitoring Tool 



查看JVM统计信息,类装载、内存、垃圾收集、JIT编译等运行数据。

jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]

interval 单位是毫秒,每过多久打印一次

count 打印多少次,默认一个参数是interval

-t 程序从开始执行到现在过了多少时间 ms

-h 每个多少多少条打印一次表头

-class举例:jstat -class -t -h3 13152 1000 10

其中h3中的3代表每隔3个分隔一次,13152代表类的进程id,1000代表每隔1000毫秒打印一次,10代表一共打印10次,如下所示:其中Timestamp代表程序至今的运行时间,单位为秒;Loaded代表加载的类的数目;Bytes代表加载的类的总字节数;Unloaded代表卸载的类的数目;Bytes代表卸载的类的总字节数;Time代表类装载所消耗的时间;

<option>

常用的option

1)-gc :查看jvm在GC时的信息,显示指定线程的内存使用情况

S0C代表幸存者0区的总容量,S1C代表幸存者1区的总容量,S0U代表幸存者0区使用的容量,S1U代表幸存者1区使用的容量,EC代表伊甸园区的总容量,EU代表伊甸园区使用的总容量,OC代表老年代的总容量,OU代表老年代已经使用的容量

MC代表方法区的总容量,MU代表方法区的总容量,CCSC代表压缩类的总容量,CCSU代表压缩类使用的容量

YGC代表年轻代垃圾回收的次数,YGCT年轻代进行垃圾回收需要的时间,FGC代表代表Full GC的次数,FGCT代表Full GC的时间,GCT代表从应用程序启动到采样时gc的总时间


常用的使用方式

1. 计算垃圾回收占运行时间的比例

我们执行jstat -gc -t 13152 1000 10,这代表1秒打印出1行,一共10行,-t代表打印出Timestamp总运行时间

通过Timestamp得到程序运行时间差,通过GCT得到垃圾回收时间差,单位都是秒,相除即为GC时间占运行时间的比例。如果高于20%说明堆压力较大,超过90%说明当前堆随时有可能溢出报OOM。在项目部署之后就需要使用命令行去看了,就没有可视化界面了,所以这种方式也要会。

2. 判断有可能存在的内存泄漏问题

通过在每一段固定的时间内抽取最小值的OU(老年代使用的空间),如果这个值一直呈上升趋势的话,意味着无法回收的对象在不断增加,可能存在内存泄漏。



jinfo:Configuration Info for Java


实时查看和修改JVM配置参数 :jinfo <option> <pid>

常用的option

1)jinfo -flag 属性 进程id:查看某个参数情况


jmap:JVM Memory Map


导出内存映像dump文件 & 获取内存使用情况

jmap [option] <pid>

jmap [option] <executable <core>>

jmap [option] [server_id@]<remote server IP or hostname>


常用命令


1.  导出内存映像文件

jmap -dump:live,format=b,file=usr/desktop/test.hprof 1130

1. 一般使用的是第二种方式,也就是生成堆中存活对象的快照,毕竟这种方式生成的dump文件更小,我们传输处理都更方便。

2. file=后面的是生成的dump文件地址,filename是文件路径+文件名称,后缀名必须是.hprof。format=b表示生成的是标准的dump文件,用来进行格式限定。

3. 自动方式在生成的dump文件之前通常会触发一次Full GC,所以里面都是Full GC后留下的对象信息。如果希望在程序发生OOM退出系统的时候能自动导出dump文件,那么就需要使用自动方式。


2.  显示堆内存的相关信息

2.1)jmap -heap pid (jdk8之后失效)

jdk8之后使用:jhsdb jmap --heap --pid pid

导出这一刻堆空间的使用情况,使用jstat和visualVM更好。

2.2)jmap -histo pid

查看这一时刻内存对象实例数量,包括它所在的class name、所占容量、按照所占容量大小进行排序。

注意

由于jmap将访问堆中的所有对象,为了保证在此过程中不被应用线程干扰,jmap需要借助安全点机制,让所有线程停留在不改变堆中数据的状态,也就是说,由jmap导出的堆快照必定是安全点位置的,这可能导致基于该堆快照的分析结果存在偏差。也就是说,假设在编译生成的机器码中,某些对象的生命周期在两个安全点之间,那么:live选项将无法探知到这些对象。另外,如果某个线程长时间无法跑到安全点,jmap将一直等下去,与前面讲的jstat则不同,垃圾回收器会主动将jstat所需要的摘要数据保存至固定位置之中,而jstat只需直接读取即可。


jhat:JVM Heap Analysis Tool


JDK自带堆分析工具,与jmap命令搭配使用,用于分析jmap生成的heap dump文件,jhat内置了一个微型的HTTP/HTML服务器(端口是7000),生成dump文件的分析结果后,用户可以在浏览器中查看分析结果(可以通过OQL语句进行过滤查询)。

jhat命令在jdk9及其之后就被移除了,官方建议使用jvisualvm代替jhat,所以该指令只需简单了解一下即可。

jhat [option] [dumpfile],其中dumpfile代表dump文件的地址以及名称


jstak:JVM Stack Trace


打印JVM中线程快照(JVM内指定进程的每一条线程正在执行的方法堆栈的集合)。可用于定位线程出现长时间停顿的原因,如线程间的死锁、死循环、请求外部资源导致的长时间等待等问题,这些都是导致线程长时间停顿的常见原因,当线程出现长时间停顿的时候,就可以使用jstack显示各个线程调用的堆栈情况。也可以通过java层面:Thread.getAllStackTrances() 得到一个Map<Thread, StackTranceElement[] >来实现。

jstack [option] pid

在thread dump中,要留意下面几种状态:

1)死锁 Deadlock    

2)等待资源 Waiting on condition    

3)等待获取监视器 Waiting on monitor entry

4)阻塞 Blocked

5)执行中 Runnable

6)暂停 Suspended

7)对象等待中,Object.wait() 或 TIMED_WAITING

8)停止 Parked

显示进程下面所有的线程状态


jcmd


jdk1.7后新增,可以用来实现除了jstat之外所有命令。

首先通过 jcmd 进程号 help 得出命令列表:根据以下命令来替换之前的那些操作:

Thread.print 可以替换 jstack指令

GC.class_histogram 可以替换 jmap中的-histo操作

GC.heap_dump 可以替换 jmap中的-dump操作

GC.run 可以查看GC的执行情况

VM.uptime 可以查看程序的总执行时间,可以替换jstat指令中的-t操作

VM.system_properties 可以替换 jinfo -sysprops 进程id

VM.flags 可以获取JVM的配置参数信息 


jstatd:远程主机信息收集



最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。