********************************************
关于jstack命令执行失败问题
[root@localhost ~]# jstack 93875
93875: 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
********************************************
【分析】
从问题现象看,提示jstack命令执行失败,建议通过-F强制获取。
考虑以下方面:
1、执行jstack命令的jdk版本与目标进程的jdk版本是否一致?
2、是否在当前进程owner用户下执行?
>>>核对jdk版本是一致,一般os配置java_home并配置path的的话,jdk版本是一致的;
>>>核对进程owner用户和当前执行jstack用户是否一致,结果是:不一致。
【解决】
切换用户到当前进程owner用户下,执行jstack,命令成功。
/////////////begin///////////
[root@localhost ~]# su - jvmuser
Last login: Wed Nov 4 14:09:13 CST 2020 on pts/1
[jvmuser@localhost ~]$ jstack 93875
2020-12-08 11:17:00
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode):
"Attach Listener" #220147 daemon prio=9 os_prio=0 tid=0x00007f4f3c001000 nid=0x10cf4 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"XMemcached-HeartBeatPool[MemcachedClient-0]-216919" #220146 daemon prio=5 os_prio=0 tid=0x00007f4f0002b800 nid=0x10cc1 waiting on condition [0x00007f4f201d6000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000ba19ec00> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
/////////////end///////////////
【小结】
1、执行jstack命令需要在当前用户下执行;
注意:通过jinfo <pid> |grep user.name,查看进程是哪个用户启动的;
2、执行jstack的jdk版本建议与正在运行的JVM的jdk版本一致,至少前者高于后者;
【温馨提示】
如果您觉得满意,可以选择支持下,您的支持是我最大的动力:
分享到:
相关推荐
抓取jstack方法及解决system用户执行jstack命令权限问题, 打开cmd窗口,输入命令 jstack -l 49824>>C:/error01.txt 其中49824为tomcat8.0 的pid ; error01.txt 这个可以自己取名字 多输出几份jstack 文件,做比对...
主要介绍了如何通过jstack命令dump线程信息,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
使用jstack定位分析CPU消耗问题
MPP的jstack分析结果
jmap、jstack、jstat组合使用定位jvm问题
图形界面分析threadump_jstack分析工具_包含jdk。IBM出品,用来分析jstack pid 打印的信息。用着挺方便的。
windows系统jstack自动抓取脚本
主要介绍了Java线程Dump分析工具jstack解析及使用场景,具有一定借鉴价值,需要的朋友可以参考下
本文档从实战角度出发,介绍jps、jmap、jstack和jstat这四个命令的常用方式。 jps 作用:获取java进程号,是后续命令的基础。 当一台服务器运行多个java进程时,该命令默认只输出进程号和应用名,可能无法区分哪个...
JStack和Java Thread Dumps分析
自动抓取jstack
Kubernetes应用java程序无法使用jmap,jstack的解决方案.docx
Broken pipe产生的原因通常是当管道读端没有在读,而管道的写端继续有线程在写,就会造成管道中断。(由于管道是单向通信的) SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址,没有物理内存对应该地址。
用jstack分析CPU占用率高的原因 1 top -H -p pid 2 linux printf命令将10进制转换为16进制 3在jstack中找到相应的堆栈信息jstack pid grep 'nid' -C5 –color
JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jstat.doc
通过ps到java进程号将进程的jstack信息输出。jstack信息是java进程的线程堆栈信息,通过该信息可以分析java的线程阻塞等问题。
需要本地安装JDK并配置JAVA环境变量。 之后使用java -jar jca469.jar即可打开工具。 直接将dump出来的堆栈信息,打开,便可分析。
这是一个 jstack 保存的死锁现场,由于 log4j consoleAppender 和 System.out 竞争资源导致的锁冲突,目前还不知道根本原因,需要分析。
主要介绍了通过jstack分析解决进程死锁问题实例代码,具有一定借鉴价值,需要的朋友可以参考下
jstack生成的Thread Dump日志.docx 系统线程状态 (Native Thread Status) 系统线程有如下状态: deadlock 死锁线程,一般指多个线程调用期间进入了相互资源占用,导致一直等待无法释放的情况。 ...