虚拟机stack全分析
通过jps -lv 获取到本地的一个JVM实例进程。再通过jstack pid > thread.txt ,把stack trace输出到thread.txt文件中。
2012-08-28 23:16:39
- 2012-08-28 23:16:39
- Full thread dump OpenJDK Client VM (19.0-b09 mixed mode, sharing):
- "Attach Listener" daemon prio=10 tid=0xb3da5400 nid=0x13ea waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- "Worker-15" prio=10 tid=0x09b7b400 nid=0x12f2 in Object.wait() [0xb30f9000]
- java.lang.Thread.State: TIMED_WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188)
- - locked <0x6e5f87c0> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)
- "Worker-12" prio=10 tid=0x09910c00 nid=0x12a0 in Object.wait() [0xb4026000]
- java.lang.Thread.State: TIMED_WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188)
- - locked <0x6e5f87c0> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)
- .......省略
- "Low Memory Detector" daemon prio=10 tid=0x097eb000 nid=0xa9f runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- "CompilerThread0" daemon prio=10 tid=0x097e9000 nid=0xa9e waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- "Signal Dispatcher" daemon prio=10 tid=0x097e7400 nid=0xa9d runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- "Finalizer" daemon prio=10 tid=0x097e4000 nid=0xa9c in Object.wait() [0xb4dd1000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
- - locked <0x6e2e02f8> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
- at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
- "Reference Handler" daemon prio=10 tid=0x097df400 nid=0xa9b in Object.wait() [0xb4e22000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- at java.lang.Object.wait(Object.java:502)
- at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- - locked <0x6e2e0098> (a java.lang.ref.Reference$Lock)
- "main" prio=10 tid=0x097b0400 nid=0xa99 runnable [0xbf8b9000]
- java.lang.Thread.State: RUNNABLE
- at org.eclipse.swt.internal.gtk.OS.Call(Native Method)
- at org.eclipse.swt.widgets.Display.sleep(Display.java:4069)
- at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:364)
- at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.eventLoopIdle(IDEWorkbenchAdvisor.java:917)
- at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2697)
- at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
- at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
- at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
- at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
- at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
- at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
- at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
- at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
- at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
- at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
- at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
- at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
- at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
- at java.lang.reflect.Method.invoke(Method.java:616)
- at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
- at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
- at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
- "VM Thread" prio=10 tid=0x097dd800 nid=0xa9a runnable
- "GC task thread#0 (ParallelGC)" prio=10 tid=0x08726800 nid=0x1e30 runnable
- "GC task thread#1 (ParallelGC)" prio=10 tid=0x08727c00 nid=0x1e31 runnable
- "VM Periodic Task Thread" prio=10 tid=0x097ed400 nid=0xaa0 waiting on condition
- JNI global references: 2131
上面的stack trace一共可以拆解成5个部分。
第一部分: Full thread dump identifier
- 2012-08-28 23:16:39
- Full thread dump OpenJDK Client VM (19.0-b09 mixed mode, sharing):
可以看到dump时间,虚拟机的信息。
第二部分: Java EE middleware, third party & custom application Threads
- "Worker-15" prio=10 tid=0x09b7b400 nid=0x12f2 in Object.wait() [0xb30f9000]
- java.lang.Thread.State: TIMED_WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188)
- - locked <0x6e5f87c0> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)
此处是我们最为关心的地方,也是通过stack trace查找问题的地方,每个item的具体含义是
-Thread name: "Worker-15"
-线程优先级: prio=10
-java线程的identifier:tid=0x09b7b400
-native线程的identifier: nid=0x12f2
-线程的状态: in Object.wait() java.lang.Thread.State: TIMED_WAITING (on object monitor)
-线程栈起始地址:[0xb30f9000]
Java线程和Native线程,也就是tid和nid的区别?
VM是加载并执行字节码的机器,这个处理不对应具体硬件,它完全由软件来实现。虚拟机并不是直接跑在宿主的cpu上,中间还隔着宿主的操作系统。
虚拟机的职责是:翻译字节码,把它翻译成一系列的动作(内存操作)和系统调用(比如输入输出)。举个例子:当在java里请求与某台远程机器建立socket连接时,java虚拟机本身是不能完成这一工作的(协议栈是在操作系统内实现的),所以它需要系统调用。要明白这个,还需要知道JRE和JVM的关系。JRE是JVM的环境,一个应用程序就是一个JVM实例。一个机器上一般同时只有一个JRE环境,但是可以同时有多个JVM实例。不同的操作系统和CPU架构有不同的JRE。JRE包含了最基本的类库,当然包括和操作系统打交道的Native库,比如windows下的dll文件,linux下的so文件。JVM实例解析字节码的成JVM中的指令集,再通过Native方法进行操作系统层面的系统调用。下面的图能比较清楚的说明问题。
JVM线程如何创建
当然是通过Native库的 native方法。JVM的线程最终是通过操作系统的线程来完成系统调用的。针对Java开发者来说,发号施令的是JVM 线程,具体干藏活累活的却是操作系统线程。不同操作系统上,JVM创建本地线程依赖的native库也不同。具体可参考下面的的文章。http://jackyhongvip.iteye.com/blog/1338610
JVM线程状态
状态有Runnable、Wait on condition、Waiting for monitor entry 和 in Object.wait()。
Runnable:不解释
Wait on condition:该状态出现在线程等待某个条件的发生。具体是什么原因,可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写。如果网络数据没准备好,线程就等待在那里。另外一种出现 Wait on condition的常见情况是该线程在 sleep,等待 sleep的时间到了时候,将被唤醒。
Waiting for monitor entry 和 in Object.wait():这两种情况在多线程的情况下经常出现。Java是通过Monitor来实现线程互斥和协作(有些把Monitor直译成锁,我认为不妥,不是还有Lock嘛)。具体Monitor的深入理解见 http://www.cnblogs.com/tomsheep/archive/2010/06/09/1754419.html
但是可以理解成Monitor是一个对象或者class所拥有的锁,每个对象和class有且仅有一个。见下图.
每个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程都是 “Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。
在 “ Entry Set”里面的线程都等待拿到Monitor,拿到了线程就成为了Runnable线程,否则就会一直处于处于 “waiting for monitor entry”。一段代码作为例子
- public class MyThread implements Runnable{
- public void run() {
- synchronized(this) {
- for (int i = 0; i < 1; i--) {
- System.out.println(Thread.currentThread().getName() + " synchronized loop " + i);
- }
- }
- }
- public static void main(String[] args) {
- MyThread t1 = new MyThread();
- Thread ta = new Thread(t1, "A");
- Thread tb = new Thread(t1, "B");
- ta.start();
- tb.start();
- }
- }
大家一看就知道,B线程肯定是“千年老二“,永远拿不到Monitor了。
对应的stack:
- "B" prio=10 tid=0x0969a000 nid=0x11d6 waiting for monitor entry [0x8bb22000]
- java.lang.Thread.State: BLOCKED (on object monitor)
- at org.marshal.MyThread.run(MyThread.java:7)
- - waiting to lock <0x94757078> (a org.marshal.MyThread)
- at java.lang.Thread.run(Thread.java:636)
- "A" prio=10 tid=0x09698800 nid=0x11d5 runnable [0x8bb73000]
- java.lang.Thread.State: RUNNABLE
- at java.io.FileOutputStream.writeBytes(Native Method)
- at java.io.FileOutputStream.write(FileOutputStream.java:297)
- at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
- at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
- - locked <0x947571b0> (a java.io.BufferedOutputStream)
- at java.io.PrintStream.write(PrintStream.java:449)
- - locked <0x94757190> (a java.io.PrintStream)
- at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:220)
- at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:290)
- at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:103)
- - locked <0x947572a0> (a java.io.OutputStreamWriter)
- at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
- at java.io.PrintStream.write(PrintStream.java:494)
- - locked <0x94757190> (a java.io.PrintStream)
- at java.io.PrintStream.print(PrintStream.java:636)
- at java.io.PrintStream.println(PrintStream.java:773)
- - locked <0x94757190> (a java.io.PrintStream)
- at org.marshal.MyThread.run(MyThread.java:8)
- - locked <0x94757078> (a org.marshal.MyThread)
- at java.lang.Thread.run(Thread.java:636)
<0x94757078> 就是两个线程争夺的Monitor。
在 “Wait Set”里面的线程都如饥似渴地等待拿到Monitor。他们是怎么进入到“Wait Set”的呢?当一个线程拿到了Monitor,但是在其他资源没有到位的情况下,调用同步锁对象(一般是synchronized()内的对象)的 wait() 方法,放弃了 Monitor,它就进入到了 “Wait Set”队列。只有当其他线程通过notify() 或者 notifyAll(),释放了同步锁后,这个线程才会有机会重新去竞争Monitor。在stack中,它表现的状态是in Object.wait()。修改上面的代码public class WaitThread implements Runnable{
- public void run() {
- synchronized(this) {
- try {
- this.wait();
- } catch (InterruptedException e) {
- // TODO Auto-generated catch block
- e.printStackTrace();
- }
- }
- }
- public static void main(String[] args) {
- WaitThread t1 = new WaitThread();
- Thread ta = new Thread(t1, "A");
- Thread tb = new Thread(t1, "B");
- ta.start();
- tb.start();
- }
对应的stack:
- "B" prio=10 tid=0x08173000 nid=0x1304 in Object.wait() [0x8baf2000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0xa9cb50e0> (a org.marshal.WaitThread)
- at java.lang.Object.wait(Object.java:502)
- at org.marshal.WaitThread.run(WaitThread.java:8)
- - locked <0xa9cb50e0> (a org.marshal.WaitThread)
- at java.lang.Thread.run(Thread.java:636)
- "A" prio=10 tid=0x08171c00 nid=0x1303 in Object.wait() [0x8bb43000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0xa9cb50e0> (a org.marshal.WaitThread)
- at java.lang.Object.wait(Object.java:502)
- at org.marshal.WaitThread.run(WaitThread.java:8)
- - locked <0xa9cb50e0> (a org.marshal.WaitThread)
- at java.lang.Thread.run(Thread.java:636)
A和B线程都进入了”wait set“。B线程也拿到过这个Monitor,因为A线程释放过了,这也验证上面的话,他们都在等待得而复失的<0xa9cb50e0>。
基于我们经常讨论到的死锁问题,构造一段代码如下
- public class DeadThread implements Runnable{
- private Object monitor_A = new Object();
- private Object monitor_B = new Object();
- public void method_A(){
- synchronized(monitor_A) {
- synchronized(monitor_B) {
- System.out.println(Thread.currentThread().getName()+" invoke method A");
- }
- }
- }
- public void method_B(){
- synchronized(monitor_B) {
- synchronized(monitor_A) {
- System.out.println(Thread.currentThread().getName()+" invoke method B");
- }
- }
- }
- public void run() {
- for(int i=0;i<1;i--){
- method_A();
- method_B();
- }
- }
- public static void main(String[] args) {
- DeadThread t1 = new DeadThread();
- Thread ta = new Thread(t1, "A");
- Thread tb = new Thread(t1, "B");
- ta.start();
- tb.start();
- }
- }
对应的stack:
- "B" prio=10 tid=0x0898d000 nid=0x269a waiting for monitor entry [0x8baa2000]
- java.lang.Thread.State: BLOCKED (on object monitor)
- at org.marshal.DeadThread.method_A(DeadThread.java:11)
- - waiting to lock <0xaa4d6f88> (a java.lang.Object)
- - locked <0xaa4d6f80> (a java.lang.Object)
- at org.marshal.DeadThread.run(DeadThread.java:28)
- at java.lang.Thread.run(Thread.java:636)
- "A" prio=10 tid=0x0898b800 nid=0x2699 waiting for monitor entry [0x8baf3000]
- java.lang.Thread.State: BLOCKED (on object monitor)
- at org.marshal.DeadThread.method_B(DeadThread.java:19)
- - waiting to lock <0xaa4d6f80> (a java.lang.Object)
- - locked <0xaa4d6f88> (a java.lang.Object)
- at org.marshal.DeadThread.run(DeadThread.java:29)
- at java.lang.Thread.run(Thread.java:636)
同时注意到,在stack trace尾部信息
- Found one Java-level deadlock:
- =============================
- "B":
- waiting to lock monitor 0x089615d8 (object 0xaa4d6f88, a java.lang.Object),
- which is held by "A"
- "A":
- waiting to lock monitor 0x08962258 (object 0xaa4d6f80, a java.lang.Object),
- which is held by "B"
- Java stack information for the threads listed above:
- ===================================================
- "B":
- at org.marshal.DeadThread.method_A(DeadThread.java:11)
- - waiting to lock <0xaa4d6f88> (a java.lang.Object)
- - locked <0xaa4d6f80> (a java.lang.Object)
- at org.marshal.DeadThread.run(DeadThread.java:28)
- at java.lang.Thread.run(Thread.java:636)
- "A":
- at org.marshal.DeadThread.method_B(DeadThread.java:19)
- - waiting to lock <0xaa4d6f80> (a java.lang.Object)
- - locked <0xaa4d6f88> (a java.lang.Object)
- at org.marshal.DeadThread.run(DeadThread.java:29)
- at java.lang.Thread.run(Thread.java:636)
- Found 1 deadlock.
stack中直接报告了Java级别的死锁,够智能吧。
第三部分:HotSpot VM Thread
- "Low Memory Detector" daemon prio=10 tid=0x097eb000 nid=0xa9f runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- "CompilerThread0" daemon prio=10 tid=0x097e9000 nid=0xa9e waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
JVM管理的内部线程,这些内部线程都是来执行native操作的,可以不必太关注。
第四部分: HotSpot GC Thread
- "GC task thread#0 (ParallelGC)" prio=10 tid=0x08726800 nid=0x1e30 runnable
- "GC task thread#1 (ParallelGC)" prio=10 tid=0x08727c00 nid=0x1e31 runnable
当虚拟机打开了parallel GC,这些线程就会定期地GC清理。
第五部分:JNI global references count
- JNI global references: 2131
JNI (Java Native Interface)全局引用也是受垃圾回收器管理。它的作用是防止回收到那些在native代码上还是被引用的,但是在java代码中却没有存活必要的引用。对于防止因为应用代码中直接使用native库或者第三方的一些监控工具的内存泄漏有非常大的帮助。
虚拟机stack全分析的更多相关文章
- jstack Dump
jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注) 执行中,Runnable 等待资源,Waiting on conditio ...
- top命令查看进程下线程信息以及jstack的使用
转自:https://www.cnblogs.com/shengulong/p/8513652.html top -Hp pid可以查看某个进程的线程信息 -H 显示线程信息,-p指定pid jsta ...
- 三个实例演示 Java Thread Dump 日志分析
原文地址: http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html jstack Dump 日志文件中的线程 ...
- 三个实例演示 Java Thread Dump 日志分析(转)
原文链接:http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html 转来当笔记^_^ jstack Dump ...
- jstack 结果查看
首先可以用jstack -l pid >sample.dump把java进程的运行栈dump出来. 还可以用grep java.lang.Thread.State sample.dump | a ...
- top命令查看线程信息和jstack使用介绍
top -Hp pid可以查看某个进程的线程信息 -H 显示线程信息,-p指定pid jstack 线程ID 可以查看某个线程的堆栈情况,特别对于hung挂死的线程,可以使用选项-F强制打印dump信 ...
- Java Thread dump 日志分析
jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注) 执行中,Runnable 等待资源,Waiting on conditio ...
- 面试之JVM
目录 Java虚拟机 类的加载方式 Java内存模型 程序计数器(PC) Java虚拟机栈(Stack) 本地方法栈 元空间(MetaSpace) Java堆(Heap) 内存分配策略 垃圾回收(GC ...
- register based 和 stack based虚拟机的区别
其实其核心的差异,就是Dalvik 虚拟机架构是 register-based,与 Sun JDK 的 stack-based 不同,也就是架构上的差异.我先摘录几段网上可以找到的资料,重新整理和排版 ...
随机推荐
- Git_搭建Git服务器
在远程仓库一节中,我们讲了远程仓库实际上和本地仓库没啥不同,纯粹为了7x24小时开机并交换大家的修改. GitHub就是一个免费托管开源代码的远程仓库.但是对于某些视源代码如生命的商业公司来说,既不想 ...
- sql prompt5安装好了,也破解完成了,然后到SQL里面还是没有提示是为什么?
勾上这个,祝你成功!
- springMVC 前台向后台传数组
前台: $(function() {//点击播放按钮执行的事件 $("#button").click(function(e) { alert("kaishi chuanz ...
- 《C预处理》Linux内核中可变参数宏的用法
http://blog.csdn.net/tankai19880619/article/details/12015305
- Spring Boot整合RabbitMQ详细教程
原文:https://blog.csdn.net/qq_38455201/article/details/80308771 1.首先我们简单了解一下消息中间件的应用场景 异步处理 场景说明:用户注册后 ...
- C#编程(十)----------C#预处理器
原文链接:http://blog.csdn.net/shanyongxu/article/details/46491757 C#中的预处理器指令 #IF 如果 C# 编译器遇到最后面跟有 #endif ...
- 使用 SVWebViewController 推出浏览器控制器
SVWebViewController 简单翻译 https://github.com/samvermette/SVWebViewController SVWebViewController is a ...
- maven项目如何生成war文件
配置 你的pom.xml文件,在你的overview视窗里 配置 packaging为 war 然后然后点击 pom.xml右键,run as 选择 install 或是 package如果项目没问题 ...
- nginx配置location总结
location匹配顺序 "="前缀指令匹配,如果匹配成功,则停止其他匹配 普通字符串指令匹配,顺序是从长到短,匹配成功的location如果使用^~,则停止其他匹配(正则匹配) ...
- @Java类加载器及双亲委派模型
类与类加载器 虚拟机设计团队把类加载阶段的"通过一个类的全限定名来获取此类的二进制字节流"这个动作放到Java虚拟机外部去实现,以便让应用程序自己决定如何去获取所需要的类.实现这个 ...