精华内容
下载资源
问答
  • 抓取jstack方法及解决system用户执行jstack命令权限问题, 打开cmd窗口,输入命令 jstack -l 49824>>C:/error01.txt 其中49824为tomcat8.0 的pid ; error01.txt 这个可以自己取名字 多输出几份jstack 文件,做比对...
  • 需要本地安装JDK并配置JAVA环境变量。 之后使用java -jar jca469.jar即可打开工具。 直接将dump出来的堆栈信息,打开,便可分析。
  • jstack生成的Thread Dump日志.docx 系统线程状态 (Native Thread Status) 系统线程有如下状态: deadlock 死锁线程,一般指多个线程调用期间进入了相互资源占用,导致一直等待无法释放的情况。 ...
  • 主要介绍了Java线程Dump分析工具jstack解析及使用场景,具有一定借鉴价值,需要的朋友可以参考下
  • jstack

    2021-04-12 21:32:55
    jstack:查看当前所有线程的状态和运行情况 jstack [-option] pid Options: -F to force a thread dump. Use when jstack does not respond (process is hung) -m to print both java and native frames (mixed mode...

    jstack:查看当前所有线程的状态和运行情况
    jstack [-option] pid
    Options:
    -F to force a thread dump. Use when jstack does not respond (process is hung)
    -m to print both java and native frames (mixed mode)
    -l long listing. Prints additional information about locks

    注意事项:
    此处线程id为16进制,10进制转16进制 printf “%x” 十进制 16进制转10进制 printf “%d” 0x十进制数

    /nemo/jdk/bin/jstack 239637

    2021-04-12 21:37:29
    Full thread dump Java HotSpot™ 64-Bit Server VM (24.65-b04 mixed mode):

    “http-bio-8080-exec-320” daemon prio=10 tid=0x00007faa4809e000 nid=0x8eec waiting on condition [0x00007faa60f95000]
    java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for <0x000000074307fa08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer C o n d i t i o n O b j e c t ) a t j a v a . u t i l . c o n c u r r e n t . l o c k s . L o c k S u p p o r t . p a r k ( L o c k S u p p o r t . j a v a : 186 ) a t j a v a . u t i l . c o n c u r r e n t . l o c k s . A b s t r a c t Q u e u e d S y n c h r o n i z e r ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer ConditionObject)atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:186)atjava.util.concurrent.locks.AbstractQueuedSynchronizerConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor W o r k e r . r u n ( T h r e a d P o o l E x e c u t o r . j a v a : 615 ) a t o r g . a p a c h e . t o m c a t . u t i l . t h r e a d s . T a s k T h r e a d Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread Worker.run(ThreadPoolExecutor.java:615)atorg.apache.tomcat.util.threads.TaskThreadWrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)

    “http-bio-8080-exec-319” daemon prio=10 tid=0x00007faa4809c800 nid=0x8eeb waiting on condition [0x00007faa61ca2000]
    java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for <0x000000074307fa08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer C o n d i t i o n O b j e c t ) a t j a v a . u t i l . c o n c u r r e n t . l o c k s . L o c k S u p p o r t . p a r k ( L o c k S u p p o r t . j a v a : 186 ) a t j a v a . u t i l . c o n c u r r e n t . l o c k s . A b s t r a c t Q u e u e d S y n c h r o n i z e r ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer ConditionObject)atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:186)atjava.util.concurrent.locks.AbstractQueuedSynchronizerConditionObject.await(AbstractQueuedSynchronizer.java:2043)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
    at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
    at java.util.concurrent.ThreadPoolExecutor W o r k e r . r u n ( T h r e a d P o o l E x e c u t o r . j a v a : 615 ) a t o r g . a p a c h e . t o m c a t . u t i l . t h r e a d s . T a s k T h r e a d Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread Worker.run(ThreadPoolExecutor.java:615)atorg.apache.tomcat.util.threads.TaskThreadWrappingRunnable.run(TaskThread.java:61)

    /nemo/jdk/bin/jstack -m 239637

    Attaching to process ID 239637, please wait…
    Debugger attached successfully.
    Server compiler detected.
    JVM version is 24.65-b04
    Deadlock Detection:

    No deadlocks found.

    ----------------- 239638 -----------------
    0x00000039ef80b68c __pthread_cond_wait + 0xcc
    0x00007faa754beaaf _ZN7Monitor5IWaitEP6Threadl + 0xef
    0x00007faa754bf23e _ZN7Monitor4waitEblb + 0x22e
    0x00007faa752339e3 _ZN13GCTaskManager8get_taskEj + 0x43
    0x00007faa752350a8 _ZN12GCTaskThread3runEv + 0x188
    0x00007faa754fd988 _ZL10java_startP6Thread + 0x108
    ----------------- 239639 -----------------
    0x00000039ef80b68c __pthread_cond_wait + 0xcc
    0x00007faa754beaaf _ZN7Monitor5IWaitEP6Threadl + 0xef
    0x00007faa754bf23e _ZN7Monitor4waitEblb + 0x22e
    0x00007faa752339e3 _ZN13GCTaskManager8get_taskEj + 0x43
    0x00007faa752350a8 _ZN12GCTaskThread3runEv + 0x188
    0x00007faa754fd988 _ZL10java_startP6Thread + 0x108
    ----------------- 239640 -----------------
    0x00000039ef80b68c __pthread_cond_wait + 0xcc
    0x00007faa754beaaf _ZN7Monitor5IWaitEP6Threadl + 0xef
    0x00007faa754bf23e _ZN7Monitor4waitEblb + 0x22e
    0x00007faa752339e3 _ZN13GCTaskManager8get_taskEj + 0x43
    0x00007faa752350a8 _ZN12GCTaskThread3runEv + 0x188
    0x00007faa754fd988 _ZL10java_startP6Thread + 0x108
    ----------------- 239641 -----------------

    展开全文
  • 使用jstack定位分析CPU消耗问题
  • 通过ps到java进程号将进程的jstack信息输出。jstack信息是java进程的线程堆栈信息,通过该信息可以分析java的线程阻塞等问题。
  • jstack文件

    2016-07-10 23:09:57
    Broken pipe产生的原因通常是当管道读端没有在读,而管道的写端继续有线程在写,就会造成管道中断。(由于管道是单向通信的) SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址,没有物理内存对应该地址。
  • java性能分析 jmap jstack

    2018-08-06 19:58:11
    java程序性能分析thread dump和heap dump,dump文件:在故障定位(尤其是out of memory)和性能分析的时候,dump文件记录了JVM运行期间的内存占用、线程执行等情况。 heap dump:记录某一时刻JVM堆中对象使用情况,哪些...
  • 图形界面分析threadump_jstack分析工具_包含jdk。IBM出品,用来分析jstack pid 打印的信息。用着挺方便的。
  • Jstack

    2021-01-07 14:21:32
    Jstack jstack命令的语法格式: jstack 。可以用jps查看java进程id。这里要注意的是: \1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的,不同的 JVM版本, dump信息也有差别。 \2. 在实际运行中,...

    Jstack

    jstack命令的语法格式: jstack 。可以用jps查看java进程id。这里要注意的是:

    \1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的,不同的 JVM版本, dump信息也有差别。

    \2. 在实际运行中,往往一次 dump的信息,还不足以确认问题。建议产生三次 dump信息,如果每次 dump都指向同一个问题,我们才确定问题的典型性。

    jstack Dump 日志文件中的线程状态

    dump 线程状态

    死锁, Deadlock(重点关注)

    执行中,Runnable

    等待资源, Waiting on condition(重点关注)

    等待获取监视器, Waiting on monitor entry(重点关注)

    暂停,Suspended

    对象等待中,Object.wait() 或 TIMED_WAITING

    阻塞, Blocked(重点关注)

    停止,Parked

    线程状态含义

    Deadlock:死锁线程,一般指多个线程调用间,进入相互资源占用,导致一直等待无法释放的情况。

    Runnable:一般指该线程正在执行状态中,该线程占用了资源,正在处理某个请求,有可能正在传递SQL到数据库执行,有可能在对某个文件操作,有可能进行数据类型等转换。

    Waiting on condition:该状态出现在线程等待某个条件的发生。具体是什么原因,可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写,比如当网络数据没有准备好读时,线程处于这种等待状态,而一旦有数据准备好读之后,线程会重新激活,读取并处理数据。在 Java引入 NewIO之前,对于每个网络连接,都有一个对应的线程来处理网络的读写操作,即使没有可读写的数据,线程仍然阻塞在读写操作上,这样有可能造成资源浪费,而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制,编写的服务器程序的性能和可扩展性都得到提高。

    ​ 如果发现有大量的线程都在处在 Wait on condition,从线程 stack看, 正等待网络读写,这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙,几 乎消耗了所有的带宽,仍然有大量数据等待网络读 写;另一种情况也可能是网络空闲,但由于路由等问题,导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析,比如 netstat统计单位时间的发送包的数目,如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率,如果系统态的 CPU时间,相对于用户态的 CPU时间比例较高;如果程序运行在 Solaris 10平台上,可以用 dtrace工具看系统调用的情况,如果观察到 read/write的系统调用的次数或者运行时间遥遥领先;这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep,等待 sleep的时间到了时候,将被唤醒。

    locked:线程阻塞,是指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程。

    Waiting for monitor entry 和 in Object.wait():Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。

    C:\Users\srqnk>jstack 8064
    2020-07-30 11:25:22
    Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode):
    
    "DestroyJavaVM" #10 prio=5 os_prio=0 tid=0x00f5cc00 nid=0x1edc waiting on condition [0x00000000]
       java.lang.Thread.State: RUNNABLE
    
    "Thread-1" #9 prio=5 os_prio=0 tid=0x15360400 nid=0x280c waiting for monitor entry [0x159cf000]
       java.lang.Thread.State: BLOCKED (on object monitor)
            at com.agree.Exam.ThreadRunB.run(DiedsynchronizedTest.java:42)
            - waiting to lock <0x04ee2840> (a java.lang.Integer)
            - locked <0x04ef8920> (a java.lang.Integer)
    
    "Thread-0" #8 prio=5 os_prio=0 tid=0x1535fc00 nid=0x3968 waiting for monitor entry [0x1593f000]
       java.lang.Thread.State: BLOCKED (on object monitor)
            at com.agree.Exam.ThreadRunA.run(DiedsynchronizedTest.java:21)
            - waiting to lock <0x04ef8920> (a java.lang.Integer)
            - locked <0x04ee2840> (a java.lang.Integer)
    
    "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x152f2800 nid=0x524 runnable [0x00000000]
       java.lang.Thread.State: RUNNABLE
    
    "C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x152c4000 nid=0x960 waiting on condition [0x00000000]
       java.lang.Thread.State: RUNNABLE
    
    "Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x15298000 nid=0x2fe4 waiting on condition [0x00000000]
       java.lang.Thread.State: RUNNABLE
    
    "Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x152c3000 nid=0x1e3c runnable [0x00000000]
       java.lang.Thread.State: RUNNABLE
    
    "Finalizer" #3 daemon prio=8 os_prio=1 tid=0x1527a400 nid=0x2718 in Object.wait() [0x1557f000]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x04e07ee0> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
            - locked <0x04e07ee0> (a java.lang.ref.ReferenceQueue$Lock)
            at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
            at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
    
    "Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x15264400 nid=0x2630 in Object.wait() [0x154ef000]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on <0x04e05f68> (a java.lang.ref.Reference$Lock)
            at java.lang.Object.wait(Object.java:502)
            at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
            - locked <0x04e05f68> (a java.lang.ref.Reference$Lock)
            at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
    
    "VM Thread" os_prio=2 tid=0x02c6dc00 nid=0xcb4 runnable
    
    "VM Periodic Task Thread" os_prio=2 tid=0x1533b800 nid=0x5c4 waiting on condition
    
    JNI global references: 6
    
    
    Found one Java-level deadlock:
    =============================
    "Thread-1":
      waiting to lock monitor 0x15268f14 (object 0x04ee2840, a java.lang.Integer),
      which is held by "Thread-0"
    "Thread-0":
      waiting to lock monitor 0x15267624 (object 0x04ef8920, a java.lang.Integer),
      which is held by "Thread-1"
    
    Java stack information for the threads listed above:
    ===================================================
    "Thread-1":
            at com.agree.Exam.ThreadRunB.run(DiedsynchronizedTest.java:42)
            - waiting to lock <0x04ee2840> (a java.lang.Integer)
            - locked <0x04ef8920> (a java.lang.Integer)
    "Thread-0":
            at com.agree.Exam.ThreadRunA.run(DiedsynchronizedTest.java:21)
            - waiting to lock <0x04ef8920> (a java.lang.Integer)
            - locked <0x04ee2840> (a java.lang.Integer)
    
    Found 1 deadlock.
    

    "Thread-1" #9 prio=5 os_prio=0 tid=0x15360400 nid=0x280c waiting for monitor entry [0x159cf000]

    “Thread-1”:线程名称

    #9:线程编号

    prio:线程的优先级别

    os_prio:系统级别的线程优先级

    tid:线程id

    nid:native线程id

    waiting for monitor entry [0x159cf000]:线程当前状态

    进程区域的划分

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-grOSvspV-1610000415287)(C:\Users\srqnk\AppData\Roaming\Typora\typora-user-images\1596095856121.png)]

    先级

    tid:线程id

    nid:native线程id

    waiting for monitor entry [0x159cf000]:线程当前状态

    进程区域的划分

    [外链图片转存中…(img-grOSvspV-1610000415287)]

    重量级锁也就是通常说synchronized的对象锁,锁标识位为10,其中指针指向的是monitor对象(也称为管程或监视器锁)的起始地址。每个对象都存在着一个 monitor 与之关联,对象与其 monitor 之间的关系有存在多种实现方式,如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成,但当一个 monitor 被某个线程持有后,它便处于锁定状态。

    展开全文
  • jstack自动抓取脚本

    2016-05-27 10:51:23
    自动抓取jstack
  • #JStack 一个开源的在线评判系统
  • 主要介绍了如何通过jstack命令dump线程信息,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
  • windows系统jstack自动抓取脚本
  • 主要介绍了jstack和线程dump实例解析,具有一定借鉴价值,需要的朋友可以参考下
  • 主要介绍了通过jstack分析解决进程死锁问题实例代码,具有一定借鉴价值,需要的朋友可以参考下
  • jstack工具主要用来打印java堆栈信息,主要是java的class名字,方法名,字节码索引,行数等信息。这篇文章主要介绍了JDK14性能管理工具之jstack使用介绍,需要的朋友可以参考下
  • JStack和Java Thread Dumps分析
  • 本文给大家记录的是java自带的工具Jstack截取进程中的堆栈信息的方法,非常的实用,有需要的小伙伴可以参考下。
  • jstack使用

    2021-01-14 10:59:16
    使用jstack观察虚拟机栈情况 jstack(Stack Trace for Java)命令用于生成虚拟机当前时刻的线程快照,查看Java线程的调用堆栈的,可以用来分析线程问题(如死锁)。线程快照就是当前虚拟机内每一条线程正在执行的...

    使用jstack观察虚拟机栈情况

    jstack(Stack Trace for Java)命令用于生成虚拟机当前时刻的线程快照,查看Java线程的调用堆栈的,可以用来分析线程问题(如死锁)。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合.

    生成线程快照的目的主要是定位线程长时间出现停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈,就可以知道没有响应的线程到底在后台做些什么事情,或者在等待些什么资源。

    以检查线程死锁为例:

    public class Main_Work_2_1 {
        public static void main(String[] args) throws InterruptedException {
            Map<String, String> resource1 = Map.of("name", "resource1");
            Map<String, String> resource2 = Map.of("name", "resource2");
    
            Thread thread1 = new Thread(() -> runOverride(resource1, resource2), "线程1");
            Thread thread2 = new Thread(() -> runOverride(resource2, resource1), "线程2");
    
            thread1.start();
            thread2.start();
    
        }
    
        /**
         * run方法运行实例,主要是对先获得哪个锁做限制
         * @param first
         * @param second
         */
        public static void runOverride(Map<String, String> first, Map<String, String> second) {
            Thread threadName = Thread.currentThread();
            synchronized (first) {
                System.out.println(threadName + " get " + first.get("name"));
    
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
    
                System.out.println(threadName + " waiting get" + second.get("name"));
    
                synchronized (second) {
                    System.out.println(threadName + " get " + second.get("name"));
                }
            }
        }
    
    }
    

    运行输出:

    Thread[线程1,5,main] get resource1
    Thread[线程2,5,main] get resource2
    Thread[线程2,5,main] waiting getresource1
    Thread[线程1,5,main] waiting getresource2
    

    代码分析:线程1 通过 synchronized (first)获得resource1的监视器锁,然后通过Thread.sleep(1000);让线程1 休眠 1s;为的是让线程 2得到执行,然后获取到 resource2的监视器锁。线程 1 和线程 2休眠结束了都开始企图请求获取对方的资源,然后这两个线程就会陷入互相等待的状态,这也就产生了死锁。

    使用jstack进行栈情况分析:

    首先使用jps获取目标进程,可以看出Main_Work_2的进程pid为10566;

    jps
    

    在这里插入图片描述

    然后查看对应进程栈内容:

    jstack 10566
    

    运行结果部分截图如下:

    图一可以看出线程1处于BLOCKED状态,- waiting to lock <0x000000008df738d0>表示正在等待锁<0x000000008df738d0>,并且- locked <0x000000008df73878>表示正持有锁<0x000000008df73878>;线程2也处于BLOCKED状态,- waiting to lock <0x000000008df73878>表示正在等待锁<0x000000008df73878>,并且- locked <0x000000008df738d0>表示正持有锁<0x000000008df738d0>

    图二可以看出找到一个死锁,并且可以很明显的知道线程1在等待一个锁,该锁已被线程2获取;线程2也在等待一个锁,该锁已被线程1获取。
    在这里插入图片描述
    在这里插入图片描述

    如果将死锁代码修改成正常代码后,在进程正常运行时,再一次使用stack查看的话,就会发现运行结果正常了。

    也可以使用一下命令将结果输出到文件当中,方便记录和传阅。

    jstack pid > jstackOut.txt
    

    jstack命令

    命令格式

    jstack [ option ] pid
    jstack [ option ] executable core
    jstack [ option ] [server-id@] remote-hostname-or-IP
    

    常用参数说明

    1)options:

    executable:Java executable from which the core dump was produced.(可能是产生core dump的java可执行程序)

    core:将被打印信息的core dump文件

    remote-hostname-or-IP:远程debug服务的主机名或ip

    server-id:唯一id,假如一台主机上多个远程debug服务

    2)基本参数:

    -F:当’jstack [-l] pid’没有相应的时候强制打印栈信息,如果直接jstack无响应时,用于强制jstack),一般情况不需要使用

    -l:长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表,会使得JVM停顿得长久得多(可能会差很多倍,比如普通的jstack可能几毫秒和一次GC没区别,加了-l 就是近一秒的时间),-l 建议不要用。一般情况不需要使用

    -m:打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧,一般应用排查不需要使用

    -h | -help:打印帮助信息

    3)pid

    pid 需要被打印配置信息的java进程id,可以用jps查询.

    线程状态

    想要通过jstack命令来分析线程的情况的话,首先要知道线程都有哪些状态,下面这些状态是我们使用jstack命令查看线程堆栈信息时可能会看到的线程的几种状态:

    NEW:未启动的。不会出现在Dump中。

    RUNNABLE:在虚拟机内执行的。运行中状态,可能里面还能看到locked字样,表明它获得了某把锁。

    BLOCKED:受阻塞并等待监视器锁,被某个锁(synchronizers)给block住了。

    WATING:无限期等待另一个线程执行特定操作;等待某个condition或monitor发生,一般停留在park(), wait(), sleep(),join() 等语句里。

    TIMED_WATING:有时限的等待另一个线程的特定操作;和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。

    TERMINATED:已退出的。

    调用修饰

    表示线程在方法调用时,额外的重要的操作。线程Dump分析的重要信息,修饰上方的方法调用。

    locked <地址> 目标:使用synchronized申请对象锁成功,监视器的拥有者。

    waiting to lock <地址> 目标:使用synchronized申请对象锁未成功,在进入区等待。

    waiting on <地址> 目标:使用synchronized申请对象锁成功后,释放后在等待区等待。

    parking to wait for <地址> 目标:park是基本的线程阻塞原语,不通过监视器在对象上阻塞。随concurrent包会出现的新的机制,与synchronized体系不同。

    线程动作

    线程状态产生的原因

    runnable: 状态一般为RUNNABLE。

    in Object.wait(): 等待区等待,状态为WAITING或TIMED_WAITING。

    waiting for monitor entry: 进入区等待,状态为BLOCKED。

    waiting on condition: 等待区等待、被park。

    sleeping: 休眠的线程,调用了Thread.sleep()。

    展开全文
  • jstack-jboss-7.5.0-Final.zip

    2020-08-29 16:30:22
    这是一个 jstack 保存的死锁现场,由于 log4j consoleAppender 和 System.out 竞争资源导致的锁冲突,目前还不知道根本原因,需要分析。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,709
精华内容 14,283
关键字:

jstack