jamp jstack工具
-
java命令及其他实用工具
- jps:查看本机的Java中进程信息。
- jstack:打印线程的栈信息,制作线程Dump。
- jmap:打印内存映射,制作堆Dump。
- jstat:性能监控工具。
- jhat:内存分析工具。
- jconsole:简易的可视化控制台。
- jvisualvm:功能强大的控制台。
- 查看指定进程的线程信息:top -Hp 17071
- JVM系列五:JVM监测&工具[整理中]:http://www.cnblogs.com/redcreen/archive/2011/05/09/2040977.html
-
jstack
- jstack 17071 > /tmp/jstack_dump.txt
- Java命令学习系列(二)——Jstack:http://www.hollischuang.com/archives/110
- jstack dump日志文件详解:http://gudaoqing.blog.51cto.com/7729345/1332829
-
Java并发:隐藏的线程死锁:http://www.importnew.com/10661.html
线程状态: NEW,未启动的。不会出现在Dump中。 RUNNABLE,在虚拟机内执行的。 BLOCKED,受阻塞并等待监视器锁。 WATING,无限期等待另一个线程执行特定操作。 TIMED_WATING,有时限的等待另一个线程的特定操作。 TERMINATED,已退出的。 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注) 执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象等待中,Object.wait() 或 TIMED_WAITING 阻塞,Blocked(重点关注) 停止,Parked
-
jmap
- jmap -heap 12341
- jmap -histo pid >a.log
- jmap -dump:format=b,file=heap.hprof <pid>
- http://www.hollischuang.com/archives/303
- jinfo
-
jstat
- jstat -printcompilation -h10 <pid> 250 600
- vishualvm:jvisualvm - Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool
jmap、jstack、jps无法连接jvm解决办法
2012-10-19 10:14:35
转自:http://klausme.info/archives/225.html
背景
在对线上服务器的java应用dump操作时发现,以下报错,不能dump。jps也获取不到java进程的pid。
jmap -dump:file=/data/dump/jvm_en.hprof 20176 20176: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding
重启后,jps可以获得该java进程的pid,jstack也可以dump线程。
而tomcat:
jdk1.6.24版本下的,jps、jstack都无法操作
jdk1.6.18版本可以执行jps、jstack。
原因分析
jvm运行时会生成一个目录hsperfdata_\(USER(\)USER是启动java进程的用户),在linux中默认是/tmp。目录下会有些pid文件,存放jvm进程信息。
jps、jstack等工具读取/tmp/hsperfdata_$USER下的pid文件获取连接信息。
XStar:$USER
是指当前用户,如果在root下用jstack一个admin用户权限的进程,也会提成这个错误,切换到admin用户下就可以正常工作。
jstack报错原因
jstack报错:Unable to open socket file。是因为这个java进程的pid文件删除了。
为什么会被删除呢?这是因为linux操作系统为了防止/tmp目录文件过多,有个删除管理机制:tmpwatch。
查看关键配置/etc/cron.daily/tmpwatch:
flags=-umc /usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix -x /tmp/.ICE-unix \ -x /tmp/.Test-unix 240 /tmp /usr/sbin/tmpwatch "$flags" 720 /var/tmp for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do if [ -d "$d" ];then /usr/sbin/tmpwatch "$flags" -f 720 "$d" fi done
系统每天会用tmpwatch命令检查并删除 /tmp 下超过240小时未访问过的文件和目录。
高版本jps、jstack不能工作原因
这是一个从Java 6 update 21 引入的bug: sunbug 7009828,在Java 6 update 25修复。具体原因是:
jdk16_21/24开始,jvm启动时产生进程号的临时文件目录优先使用-Djava.io.tmpdir指定的目录,没有指定-Djava.io.tmpdir参数才使用/tmp/hsperfdata_$USER。
正好tomcat指定了-Djava.io.tmpdir=\({tomcat_home}/tmp/
。而jps、jstack从/tmp/hsperfdata_\)USER
目录读取不到pid信息,所以才报错。
解决办法
修改tmpwatch设置
排查对应的/tmp/hsperfdata_*的目录,让jvm自己来管理,保证jps,jstat等命令可用。
修改/etc/cron.daily/tmpwatch
/usr/sbin/tmpwatch "$flags" -x /tmp/hsperfdata_* -x /tmp/.X11-unix -x /tmp/.XIM-unix \ -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix 240 /tmp
修改tomcat配置或者升级jdk
- 修改tomcat的Djava.io.tmpdir参数,统一使用/tmp目录。
修改catalina.sh添加:CATALINA_TMPDIR=/tmp
,重启tomcat。
- 升级jdk到Java 6 update 25.
- 其他java程序重启:重启java进程,重新生成pid文件。
参考URL
- http://pt.alibaba-inc.com/wp/experience_382/java-long-running-jps-tools-such-as-a-solution-can-not-connect-jvm-2.html
- http://underlap.blogspot.com/2011/03/java-update-breaks-jps-jconsole-etc.html
另外说明
- 在JDK 64bit 1.7.0_01版本也出现了这个问题。
-
在CentOS6以后,/etc/cron.daily/tmpwatch有所改变
#! /bin/sh flags=-umc /usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \ -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \ -X '/tmp/hsperfdata_*' 10d /tmp # 上面`-X '/tmp/hsperfdata_*' 10d /tmp `是新加入的 /usr/sbin/tmpwatch "$flags" 30d /var/tmp for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do if [ -d "$d" ]; then /usr/sbin/tmpwatch "$flags" -f 30d "$d" fi done
- CentOS6.5中,tmpwatch包缺省并未安装。
目录/etc/cron.daily/,这个目录是每天执行一次计划任务的目录,所以说,如果设置了比一天更短的清理时间,它是不起作用的。