JDK内置工具使用

更新时间:2023-11-30 02:23:01 阅读量: 教育文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

JDK内置工具使用

最近遇到一件非常头疼的事情。去年11月份上线的项目一直遗留的一个问题,性能问题,用户不多,但是cpu和内存的负荷居高不下。手头也没有解决方法。最近无意中从同事的操作得到一点启发。

其他根据java程序的性能,使用java自身携带的工具还是比较方便的。要么在一开始你就写好你的程序。写出优秀的代码,考虑内存垃圾回收机制。否则实施人员会天天给你提性能方面的bug。

下面我介绍整理jdk内置的几个工具。写这个博文的同时我也参考广大网友的帖子。谢谢同志们的总结啊。

?

jps的用法

用来查看JVM里面所有进程的具体状态, 包括进程ID,进程启动的路径等等。与unix上的ps类似,用来显示本地的java进程,可以查看本地运行着几个java程序,并显示他们的进程号。

[root@localhost ~]# jps 25517 Jps 25444 Bootstrap

?

jstack的用法

如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外,jstack工具还可以附属到正在运行的java程序中,看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现

hung的状态,jstack是非常有用的。目前只有在Solaris和Linux的JDK版本里面才有。

[root@localhost bin]# jstack 25444

Attaching to process ID 25917, please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.5.0_08-b03 Thread 25964: (state = BLOCKED) Error occurred during stack walking:

sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:134) at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437)

at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48) at

sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:75)

at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252) at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:50) at sun.jvm.hotspot.tools.JStack.run(JStack.java:41) at sun.jvm.hotspot.tools.Tool.start(Tool.java:204) at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)

Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method) at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34) at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:431)

at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:109)

Thread 25963: (state = IN_NATIVE) Error occurred during stack walking:

sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:134) at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437)

at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48) at

sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:75)

at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252) at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211) at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:50) at sun.jvm.hotspot.tools.JStack.run(JStack.java:41) at sun.jvm.hotspot.tools.Tool.start(Tool.java:204) at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)

Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method) at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34) at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:431) at

sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:109)

?

jstat的用法

用以判断JVM是否存在内存问题呢?如何判断JVM垃圾回收是否正常?一般的top指令基本上满足不了这样的需求,因为它主要监控的是总体的系统资源,很难定位到java应用程序。

Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”,它位于java的bin目录下,主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控,包括了对Heap size和垃圾回收状况的监控。可见,Jstat是轻量级的、专门针对JVM的工具,非常适用。由于JVM内存设置较大,图中百分比变化不太明显

一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。

jstat工具特别强大,有众多的可选项,详细查看堆内各个部分的使用量,以及加载类的数量。使用时,需加上查看进程的进程id,和所选参数。

语法结构:

Usage: jstat -help|-options

jstat -

参数解释:

Options — 选项,我们一般使用 -gcutil 查看gc情况 vmid — VM的进程号,即当前运行的java进程号 interval– 间隔时间,单位为秒或者毫秒 count — 打印次数,如果缺省则打印无数次

S0 — Heap上的 Survivor space 0 区已使用空间的百分比 S1 — Heap上的 Survivor space 1 区已使用空间的百分比 E — Heap上的 Eden space 区已使用空间的百分比 O — Heap上的 Old space 区已使用空间的百分比 P — Perm space 区已使用空间的百分比

YGC — 从应用程序启动到采样时发生 Young GC 的次数

YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒) FGC — 从应用程序启动到采样时发生 Full GC 的次数

FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒) GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

实例使用1:

[root@localhost bin]# jstat -gcutil 25444

S0 S1 E O P YGC YGCT FGC FGCT GCT

11.63 0.00 56.46 66.92 98.49 162 0.248 6 0.331 0.579

实例使用2:

[root@localhost bin]# jstat -gcutil 25444 1000 5

S0 S1 E O P YGC YGCT FGC FGCT GCT

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

73.54 0.00 99.04 67.52 98.49 166 0.252 6 0.331 0.583

我们可以看到,5次young gc之后,垃圾内存被从Eden space区(E)放入了Old space区(O),并引起了百分比的变化,导致Survivor space使用的百分比从73.54%(S0)降到0%(S1)。有效释放了内存空间。绿框中,我们可以看到,一次full gc之后,Old space区(O)的内存被回收,从99.05%降到67.52%。 图中同时打印了young gc和full gc的总次数、总耗时。而,每次young gc消耗的时间,可以用相间隔的两行YGCT相减得到。每次full gc消耗的时间,可以用相隔的两行FGCT相减得到。例如红框中表示的第一行、第二行之间发生了1次young gc,消耗的时间为0.252-0.252=0.0秒。

本文来源:https://www.bwwdw.com/article/h6it.html

Top