java dump

注意,请不要被我误导,我没有看其他资料,这是我自己分析的,有些可能是不对的

 


"DestroyJavaVM" prio=6 tid=0x00316800 nid=0x448 waiting on condition [0x00000000

..0x00a0fd4c]

   java.lang.Thread.State: RUNNABLE

 

"Thread-1" prio=6 tid=0x02f85000 nid=0xd18 waiting for monitor entry [0x0319f000

..0x0319fd14]

   java.lang.Thread.State: BLOCKED (on object monitor)

        at xunlei.kkk.f2(TestLock.java:20)

        - waiting to lock <0x22ad0160> (a java.lang.Object)//在“入口区”等待获取<0x22ad0160>

        - locked <0x22ad0158> (a java.lang.Object)//获得了监视器<0x22ad0158>

        at xunlei.TestLock$2.run(TestLock.java:42)

 

"Thread-0" prio=6 tid=0x02bff400 nid=0xd40 waiting for monitor entry [0x02f4f000

..0x02f4fd94]

   java.lang.Thread.State: BLOCKED (on object monitor)

        at xunlei.kkk.f1(TestLock.java:9)

        - waiting to lock <0x22ad0158> (a java.lang.Object) 在“入口区”等待获取<0x22ad0158>

        - locked <0x22ad0160> (a java.lang.Object) //获得了监视器<0x22ad0160>

        at xunlei.TestLock$1.run(TestLock.java:35)

 


"A2" prio=6 tid=0x02c01400 nid=0xb0c in Object.wait() [0x02fef000..0x02fefa94]

   java.lang.Thread.State: WAITING (on object monitor)

        at java.lang.Object.wait(Native Method)

        - waiting on <0x22a15d48> (a java.lang.Object)//在“等待区”等待获取<0x22a15d48>

        at java.lang.Object.wait(Object.java:485)

        at xunlei.OutputName.run(Test.java:58)

        - locked <0x22a15d48> (a java.lang.Object)

 

"A1" prio=6 tid=0x02c00000 nid=0xf8 in Object.wait() [0x02f9f000..0x02f9fb14]

   java.lang.Thread.State: WAITING (on object monitor)

        at java.lang.Object.wait(Native Method)

        - waiting on <0x22a15d48> (a java.lang.Object)

        at java.lang.Object.wait(Object.java:485)

        at xunlei.OutputName.run(Test.java:58)

        - locked <0x22a15d48> (a java.lang.Object)

 

"A0" prio=6 tid=0x02c17800 nid=0xe68 in Object.wait() [0x02f4f000..0x02f4fb94]

   java.lang.Thread.State: WAITING (on object monitor)

        at java.lang.Object.wait(Native Method)

        - waiting on <0x22a15d48> (a java.lang.Object)

        at java.lang.Object.wait(Object.java:485)

        at xunlei.OutputName.run(Test.java:58)

        - locked <0x22a15d48> (a java.lang.Object)

 

 

在windows的cmd.exe中运行的java程序,按下ctrl+break,则会弹出此时程序的堆栈,上面显示了线程的几种状态

 

一、- locked <0x22ad0158> (a java.lang.Object)

线程获得了监视器<0x22ad0158>

 

二、- waiting to lock <0x22ad0160> (a java.lang.Object)

此线程不持有监视器<0x22ad0160>,但是它期待着获得监视器<0x22ad0160>

 

此线程是在“入口区”等待获取监视器<0x22ad0160>,即此线程不必等待其他线程执行<0x22ad0160>.notify()或<0x22ad0160>.notifyAll(),而是一旦<0x22ad0160>被其他线程释放掉(通过其他线程<0x22ad0160>.notify()或<0x22ad0160>.notifyAll(),或者其他线程<0x22ad0160>.wait()),此线程总是会去争抢<0x22ad0160>

 

三、- waiting on <0x22a15d48> (a java.lang.Object)

此线程刚刚执行了<0x22a15d48>.wait()后释放了监视器<0x22a15d48>,并期望再次获得<0x22a15d48>

此线程是在“等待区”等待获取监视器<0x22a15d48>,当然,再次获得时,需要其他线程调用<0x22a15d48>.notify()或<0x22a15d48>.notifyAll(),如果其他线程不调用<0x22a15d48>.notify()或<0x22a15d48>.notifyAll(),则此线程永远不会复活

 

在下面的语句中

       synchronized (obj) {// waiting to lock <0x22a15d48>

           while (!condition) {

              obj.wait();//waiting on <0x22a15d48>(不再持有监视器了,在“等待区”期待着再次获得监视器)

           }

           // do when condition is OK

       }

 

四、obj.wait()包含了两层含义:

1、  此线程释放了obj的监视器,即此线程现在已经不再持有obj的监视器啦

2、  在“等待区”等待着再次获取obj的监视器(其他线程必须调用obj.notify()或obj.notifyAll(),如果仅仅执行完成synchronized语句或synchronized块而没有调用obj.notify()或obj.notifyAll(),则“等待区”中的线程就永远不会苏醒)

 

五、线程的状态

1、  java.lang.Thread.State: RUNNABLE,此线程正在运行

2、  java.lang.Thread.State: WAITING,此线程位于“等待区”,等待其他线程调用<0x22a15d48>.notifyAll(),否则,这个线程永远不可能苏醒

3、  java.lang.Thread.State: BLOCKED,此线程位于“入口区”,且被阻塞了,在上面的例子中,死锁了,永远不会有解除block的机会(当然,在Java中,有些I/O方法也会阻塞的,不过,等到I/O完成后,就会自动解除block啦)

http://blog.csdn.net/iceman1952/article/details/5526430

 

http://blog.csdn.net/kobejayandy/article/details/9132927

http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0903_suipf_javadump/

 

时间: 2024-09-19 09:23:40

java dump的相关文章

从服务器上下载的java dump如何在本机查看。

问题描述 从服务器上下载的java dump如何在本机查看. 如题,从服务器上下载的java dump如何在本机查看. 如题,从服务器上下载的java dump如何在本机查看. 解决方案 http://www.cnblogs.com/0616--ataozhijia/p/4136312.html 解决方案二: 使用mat分析,如果dump文件太大,可以在Linux下分析得到结果文件,在Windows上查看结果

java-日志文件中多次出现JVMDUMP032I JVMms.......,求解答

问题描述 日志文件中多次出现JVMDUMP032I JVMms.......,求解答 Jan 4 15:19:40 localhost IBM Java[2433]: JVMDUMP032I JVM requested Snap dump using '/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/Snap.20150104.151940.2433.0007.trc' in response to an event Jan 4 15:19:40 l

Memory Leak(内存泄漏)问题总结(转)

最近听了一些关于Memory Leak(内存泄漏)的seminar,感觉有些收获,所以留个记录,并share给朋友. 1 什么是Memory Leak. Memory Leak是指由于错误或不完备的代码造成一些声明的对象实例长期占有内存空间,不能回收.Memory Leak会造成系统性能下降,或造成系统错误. 2 Memory存储模式 我们通常写的C++或Java Code在内存里边的存储状况概如下图. 简单的说,一般局部变量存储于Stack中,以提高运行问速度.而New出来的变量则将引用信息或

jps,jstat,jinfo,jmap,jhat,jstack工具的使用/查看Linux磁盘信息

1.查看磁盘还剩多少空间,使用df命令(查看Linux版本:lsb_release -a,uname -a) 2.当前文件夹下的磁盘使用情况:(du --max-depth=1 -h后面没有显示跟路径,它默认是当前的路径.) 3.查看其中某一文件(文件夹)的大小:这里的大小是该文件夹下的大小的总和 4.查看指定目录下的文件大小 -------------------------------------------------------------------------------------

利用Memory Dump Diagnostic for Java (MDD4J)分析内存管理问题

简介 这一部分是 Java 内存转储诊断 (MDD4J) 故障排除工具的简介,这种工具可帮助您分析 Java 堆,从而诊断内存占用问题.MDD4J 的分析结果在报告中提供,此报告汇总了应用程序使用 Java 堆的情况. 共有三种适合使用 MDD4J 提供帮助的场景: 内存泄漏:如果应用程序出现 java.lang.OutOfMemoryError 异常,或者详细的垃圾收集数据显示内存消耗逐渐增加,那么 MDD4J 可以指出造成此类增加的数据结构以及这些数据结构内的组件. 过度的内存消耗:如果一个

急求。。。。。看下java的dump文件,会这样

问题描述 急求.....看下java的dump文件,会这样 2015-03-18 22:38:54 Full thread dump Java HotSpot(TM) Client VM (20.1-b02 mixed mode, sharing): "Attach Listener" daemon prio=10 tid=0x089f1c00 nid=0x1df1 waiting on condition [0x00000000] java.lang.Thread.State: RU

java jstack dump 线程 介绍 解释

    最近抽时间把JVM运行过程中产生的一些线程进行了整理,主要是围绕着我们系统jstack生成的文件为参照依据.  前段时间因为系统代码问题,造成性能到了天花板,于是就dump了一份stack出来进行分析.  看stack其实也需要一定的经验,毕竟它里面很多线程不可能都是有问题,所以,需要对他们有一定认识.  现在市面上很少有人对这一块做整理,所以,导致很多新人在拿到一个stack文件之后,也是一头雾水. 下面我把这次整理的一些个人认为比较重要的线程列出来,供大家参考. 如果发现有什么写得不

Java线程Dump分析工具--jstack(转)

jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式:     jstack [-l][F] pid     如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题.另外,jstack工具还可以附

Thread Dump 和Java应用诊断(转)

  Thread Dump 和Java应用诊断 Thread Dump是非常有用的诊断Java应用问题的工具,每一个Java虚拟机都有及时生成显示所有线程在某一点状态的thread-dump的能力.虽然各个Java虚拟机thread dump打印输出格式上略微有一些不同,但是Thread dumps出来的信息包含线程:线程的运行状态.标识和调用的堆栈:调用的堆栈包含完整的类名,所执行的方法,如果可能的话还有源代码的行数. Thread Dump特点: ?能在各种操作系统下使用 ?能在各种Java