jstack

JVM性能调优监控工具jps、jstack、jstat、jmap、jinfo使用详解 https://www.cnblogs.com/baihuitestsoftware/articles/6382733.html jps 查看所有的jvm进程，包括进程ID，进程启动的路径等等。 我自己也用PS，即：ps -ef | grep java jstack 观察jvm中当前所有线程的运行情况和线程当前状态。 系统崩溃了？如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。 系统hung住了？jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。 jstat jstat利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对进程的classloader，compiler，gc情况； 特别的，一个极强的监视内存的工具，可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量，以及加载类的数量。 jmap 监视进程运行中的jvm物理内存的占用情况，该进程内存内

（1）cpu使用率高 1.通过top命令查看机器状况** 可以看出cpu使用率非常高，并且java进程的cpu使用率超过了90% 2.查看是java进程中的哪个线程使用率最高 因为java进程的pid为3461，使用如下命令 top -H -p 3461 结果为： 可以看出3462这个线程的cpu使用率最高 使用printf可以将3462转化为16进制，方便在dump文件中查看 printf "%x\n" 3462 3.dump线程堆栈信息 因为java进程的pid为3461，所以执行如下命令 jstack -l 3461 > thread.log 多dump几次，打开thread.log，查找nid为3462，即0xd86的线程，结果为 发现都是停留在Hello.java第六行的地方，检查代码，发现确实是有死循环 （2）cpu使用率不高 1.通过top命令查看cpu使用率 结果为： 发现cpu使用率非常低 2.dump堆栈信息 首先查看java进程pid，可以使用jps或者ps jps 或 ps -aux | grep java 结果为： 可以看出java进程pid为3579 接着使用jstack打印堆栈信息，拉到最下面，可以看出有死锁信息 其实这在上面的日志中就可以看到： 线程1在等待250这个锁而它拥有260，而250这个锁查找后发现被线程0locked了

JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat等小巧的工具，本博客希望能起抛砖引玉之用，让大家能开始对JVM性能调优的常用工具有所了解。 现实企业级Java开发中，有时候我们会碰到下面这些问题： OutOfMemoryError，内存不足 内存泄露 线程死锁 锁争用（Lock Contention） Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。 A、 jps(Java Virtual Machine Process Status Tool) jps主要用来输出JVM中运行的进程状态信息。语法格式如下： 1 jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： 1 2 3 4 -q 不输出类名、Jar名和传入main方法的参数 -m 输出传入main方法的参数 -l

本文转载自： JVM-GC调优，一文详解JDK监控和故障处理命令及常见故障分析 JVM 的定位系统问题时，知识和经验是关键基础，数据是依据、工具是运用知识处理数据的手段 数据包括：运行日志、异常堆栈、GC日志、线程快照（thread dump、javacore文件）、堆转储快照（headdump / hprof 文件） 一、调优命令 JDK监控和故障处理命令，在bin目录下有： jps、 jstat、jmap、jhat、jstack、jinfo jps：显示虚拟机进程，常用如： jps -l -v jstat：收集虚拟机各方面的运行数据，常用如： jps-gcutil 2764 、 jstat -gc 2764 250 20 jinfo：显示虚拟机配置信息 jmap：生成虚拟机内存转储快照（headdump 文件），常用如： jmap -dump:live,format=b,file=dump.hprof 28920 jhat：用于分析headdump 文件，他会建立一个http/html 的服务器，让客户可以在浏览器上查看分析结果，常用如： jhat dump.hprof jstack： 显示虚拟机线程快照，常用如： jstack -l 11494 下面做一 一介绍 二、Jps 显示指定系统内所有的HotSpot虚拟机进程， 格式 ： jps - [hostid] options

目录 0.查看系统位数 1.查看java进程ID 2.查看进程中的线程ID 3.将线程ID转换成16进制 4.jstack生成当前时刻线程快照 0.查看系统位数 Linux：getconf LONG_BIT HP-UX：getconf KERNEL_BITS 1.查看java进程ID 使用jps、ps -ef | grep java查看当前java进程的pid，严重情况下可以使用top命令查看当前系统cpu/内存使用率最高的进程pid。 2.查看进程中的线程ID 使用命令查看进程里面占用最多的资源的线程： Linux：top -Hp ${pid}、pstree -p ${pid} HP-UX：tusc 3.将线程ID转换成16进制 使用命令把线程tid转换成16进制数。 printf "%x\n" ${tid} 4.jstack生成当前时刻线程快照 （threaddump，即当前进程中所有线程的信息） 使用命令查询该线程阻塞的地方： 【32位机器】jstack -l ${pid} >>jstack.log 【64位机器】jstack -J-d64 -l ${pid} >>jstack.log jstack更多详细用法可以查看官方说明： http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstack.html HP

6、jstack的使用 有些时候我们需要查看下jvm中的线程执行情况，比如，发现服务器的CPU的负载突然增高了、出现了死锁、死循环等，我们该如何分析呢？ 由于程序是正常运行的，没有任何的输出，从日志方面也看不出什么问题，所以就需要 看下jvm的内部线程的执行情况，然后再进行分析查找出原因。 这个时候，就需要借助于jstack命令了，jstack的作用是将正在运行的jvm的线程情况进 行快照，并且打印出来： #用法：jstack <pid> [root@node01 bin]# jstack 2203 Full thread dump Java HotSpot(TM) 64‐Bit Server VM (25.141‐b15 mixed mode): "Attach Listener" #24 daemon prio=9 os_prio=0 tid=0x00007fabb4001000 nid=0x906 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "http‐bio‐8080‐exec‐5" #23 daemon prio=5 os_prio=0 tid=0x00007fabb057c000 nid=0x8e1 waiting on condition

[转]jstack Dump 日志文件中的线程状态 dump 文件里，值得关注的线程状态有： 死锁， Deadlock（重点关注） 执行中， Runnable 等待资源， Waiting on condition（重点关注） 等待获取监视器， Waiting on monitor entry（重点关注） 暂停， Suspended 对象等待中， Object.wait() 或 TIMED_WAITING 阻塞， Blocked（重点关注） 停止， Parked 下面我们先从第一个例子开始分析，然后再列出不同线程状态的含义以及注意事项，最后再补充两个实例。 综合示范一： Waiting to lock 和 Blocked 实例如下： "RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000] java.lang.Thread.State: BLOCKED (on object monitor) at org.apache.log4j.Category.callAppenders(Category.java:201) - waiting to lock