精华内容
下载资源
问答
  • 主要介绍了Java线程Dump分析工具jstack解析及使用场景,具有一定借鉴价值,需要的朋友可以参考下
  • Runnable:一般指该线程正在执行状态中,该线程占用了资源,正在处理某个请求,有可能正在传递SQL到数据库执行,有可能在对某个文件操作,有可能进行数据类型等转换。Waiting on condition:等待资源,或等待某个...

    含义如下所示:

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

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

    Waiting on condition:等待资源,或等待某个条件的发生。具体原因需结合 stacktrace来分析。

    如果堆栈信息明确是应用代码,则证明该线程正在等待资源。一般是大量读取某资源,且该资源采用了资源锁的情况下,线程进入等待状态,等待资源的读取。

    又或者,正在等待其他线程的执行等。

    如果发现有大量的线程都在处在 Wait on condition,从线程 stack看,正等待网络读写,这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。

    一种情况是网络非常忙,几乎消耗了所有的带宽,仍然有大量数据等待网络读写;

    另一种情况也可能是网络空闲,但由于路由等问题,导致包无法正常的到达。

    另外一种出现 Wait on condition的常见情况是该线程在 sleep,等待 sleep的时间到了时候,将被唤醒。

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

    Waiting for monitor entry 和 in Object.wait():Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。从下图1中可以看出,每个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程都是 “Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”,而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。

    b8b1562fe3661bddc3f40db93d770be5.png

    图1 A Java Monitor

    综合示范二: W aiting on condition 和 TIMED_WAITING

    实例如下:

    "RMI TCP Connection(idle)" daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2  waiting on condition [0x00007fd4f1a59000]

    java.lang.Thread.State:  TIMED_WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    -  parking to wait for  <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)

    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)

    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)

    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)

    at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)

    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

    at java.lang.Thread.run(Thread.java:662)

    1)“ TIMED_WAITING (parking)”中的 timed_waiting 指等待状态,但这里指定了时间,到达指定的时间后自动退出等待状态;parking指线程处于挂起中。

    2)“ waiting on condition”需要与堆栈中的“ parking to wait for  <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先,本线程肯定是在等待某个条件的发生,来把自己唤醒。其次,SynchronousQueue 并不是一个队列,只是线程之间移交信息的机制,当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务,因此这就是本线程在等待的条件。

    3)别的就看不出来了。

    综合示范三:in Obejct.wait() 和 TIMED_WAITING

    实例如下:

    "RMI RenewClean-[172.16.5.19:28475]" daemon prio=10 tid=0x0000000041428800 nid=0xb09  in Object.wait() [0x00007f34f4bd0000]

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

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

    -  waiting on <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock)

    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)

    -  locked <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock)

    at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516)

    at java.lang.Thread.run(Thread.java:662)

    1)“ TIMED_WAITING (on object monitor)”,对于本例而言,是因为本线程调用了 java.lang.Object.wait(long timeout) 而进入等待状态。

    2)“Wait Set”中等待的线程状态就是“  in Object.wait() ”。当线程获得了 Monitor,进入了临界区之后,如果发现线程继续运行的条件没有满足,它则调用对象(一般就是被 synchronized 的对象)的 wait() 方法,放弃了 Monitor,进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ,“ Wait Set”队列中线程才得到机会去竞争,但是只有一个线程获得对象的 Monitor,恢复到运行态。

    3)RMI RenewClean 是 DGCClient 的一部分。 DGC 指的是 Distributed GC,即分布式垃圾回收。

    4)请注意,是先  locked <0x00000000aa672478>,后  waiting on <0x00000000aa672478>,之所以先锁再等同一个对象,请看下面它的代码实现:

    static private class  Lock { };

    private Lock lock = new Lock();

    public Reference extends T>  remove(long timeout)

    {

    synchronized (lock) {

    Reference extends T> r =  reallyPoll();

    if (r != null) return r;

    for (;;) {

    lock. wait(timeout);

    ……

    }

    }

    即,线程的执行中,先用 synchronized 获得了这个对象的 Monitor(对应于   locked <0x00000000aa672478> );当执行到 lock.wait(timeout);,线程就放弃了 Monitor 的所有权,进入“Wait Set”队列(对应于   waiting on <0x00000000aa672478> )。

    5)从堆栈信息看,是正在清理 remote references to remote objects ,引用的租约到了,分布式垃圾回收在逐一清理呢。

    展开全文
  • 前言 前面写了jmap 和 visualVM, jstack在实际生产中也用到过,不过当时都记在印象笔记了~ 最近整理拿出来。 使用

    目录

    前言

    线上问题

    jps -lvm

    jstack -l pid

    jstack -l > xxxx.jstack

    说明

    常用参数

    网上的一些使用方式

    top命令

    实例1:多线程竞争synchronized锁

    实例2:通过wait挂起线程

    总结


    前言

    前面写了jmap 和 visualVM,

    jstack在实际生产中也用到过,不过当时都记在印象笔记了~

    其实都是总结学习吧,因为之前在职,很多东西没时间写博客。就简单记录在笔记上面了。

    这次刷题准备面试,记录博客也是让自己知识更成体系吧。 时间浪费点希望能有更多的价值。

    虽然选择高优的事情直接背八股文更加效率,但是我喜欢慢工出细活,欲速则不达。

    线上问题

    我们查询内容质量校验的时候,

    发现,查询hive可能线程卡死了

    因为使用线程池做的数据查询。

    但是有的日志并不连续,感觉像是没有执行完的样子。

    很偶现的事情,后续把日志打印完成,该进行异常处理的都处理,并打印日志,后续就没有发生这个问题了。

    jps -lvm

    jps -lvm 用于查看当前机器上运行的java进程。

    然后用:

    jstack -l pid

    我们使用 jstack -l 6812 查看我们的应用堆栈信息:

    "G1 Concurrent Refinement Thread#11" os_prio=0 tid=0x00007f96b0050800 nid=0x186f runnable

    只是看当前堆栈的信息,历史信息并不能看到。

    并没法复现现场,因为是0点之后才会做数据质量的校验。

    jstack -l > xxxx.jstack

    jstack 是一个抓取 thread dump 文件的有效的命令行工具,它位于 JDK 目录里的 bin 文件夹下(JDK_HOMEbin),以下是抓取 dump 文件的命令:

    jstack -l > 

    比如:

    jstack -l 6227 >6227.jstack

    文件就不放出了,之后可以用fastthread.io分析:[JVM]dump分析工具_fastthread.io

    说明

    jstack,主要分析线程问题,跟jmap主要分析OOM和堆内存问题不同。

    主要用来跟踪java进程中的线程的执行状态,比较重要。

    jstack pid;  //可以打印出进程中线程的栈,及状态;

    作用:

    线程发生问题-死锁;

    线程状态;

    常用参数

    localhost:~ bjhl$ jstack -h
    Usage:
        jstack [-l] <pid>
            (to connect to running process)
        jstack -F [-m] [-l] <pid>
            (to connect to a hung process)
        jstack [-m] [-l] <executable> <core>
            (to connect to a core file)
        jstack [-m] [-l] [server_id@]<remote server IP or hostname>
            (to connect to a remote debug server)

    Options:
        -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
        -m  to print both java and native frames (mixed mode)
        -l  long listing. Prints additional information about locks
        -h or -help to print this help message

    这边可能会引出,线程的几种状态和生命周期等等

    网上的一些使用方式

    该部分来自:如何使用jstack分析线程状态

    作者:Jessica程序猿

    大概就是:

    测试环境的服务器cpu使用率一直处于100%,本地又没有什么接口调用,为什么会这样?cpu使用率居高不下,自然是有某些线程一直占用着cpu资源,那又如何查看占用cpu较高的线程?

    top命令

    在linux环境下,可以通过top命令查看各个进程的cpu使用情况,默认按cpu使用率排序

    1、看出pid为23344的java进程占用了较多的cpu资源;
    2、通过top -Hp 23344可以查看该进程下各个线程的cpu使用情况;

    从进程,找到线程, 然后用jstack:

    占了较多的cpu资源,利用jstack命令可以继续查看该线程当前的堆栈状态。

     

    jstack pid

    通过top命令定位到cpu占用率较高的线程之后,继续使用jstack pid命令查看当前java进程的堆栈状态

    jstack命令生成的thread dump信息包含了JVM中所有存活的线程,为了分析指定线程,必须找出对应线程的调用栈,应该如何找?

    在top命令中,已经获取到了占用cpu资源较高的线程pid,将该pid转成16进制的值,在thread dump中每个线程都有一个nid,找到对应的nid即可;隔段时间再执行一次stack命令获取thread dump,区分两份dump是否有差别,在nid=0x246c的线程调用栈中,发现该线程一直在执行JstackCase类第33行的calculate方法,得到这个信息,就可以检查对应的代码是否有问题。

    实例1:多线程竞争synchronized锁

    很明显:线程1获取到锁,处于RUNNABLE状态,线程2处于BLOCK状态
    1、locked <0x000000076bf62208>说明线程1对地址为0x000000076bf62208对象进行了加锁;
    2、waiting to lock <0x000000076bf62208> 说明线程2在等待地址为0x000000076bf62208对象上的锁;
    3、waiting for monitor entry [0x000000001e21f000]说明线程1是通过synchronized关键字进入了监视器的临界区,并处于"Entry Set"队列,等待monitor

    实例2:通过wait挂起线程

    static class Task implements Runnable {
        @Override
        public void run() {
            synchronized (lock) {
                try {
                    lock.wait();
                    //TimeUnit.SECONDS.sleep(100000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    dump结果

    线程1和2都处于WAITING状态

    (这边代码不全,我理解是 用了一个对象当锁,所以都需要等同一个对象。)
    1、线程1和2都是先locked <0x000000076bf62500>,再waiting on <0x000000076bf62500>,之所以先锁再等同一个对象,是因为wait方法需要先通过synchronized获得该地址对象的monitor;
    2、waiting on <0x000000076bf62500>说明线程执行了wait方法之后,释放了monitor,进入到"Wait Set"队列,等待其它线程执行地址为0x000000076bf62500对象的notify方法,并唤醒自己

    (这部分需要多理解一下,Object.wait/notify实现机制,如果只是wait不换型出现什么)

     

    总结

    通过top命令定位到cpu占用率较高的线程之后,继续使用jstack pid命令查看当前java进程的堆栈状态(因为jstack pid 只能打印出对应的java进程的所有栈信息,所以需要找到对应的线程,需要转一下16进制)

    在top命令中,已经获取到了占用cpu资源较高的线程pid,将该pid转成16进制的值,在thread dump中每个线程都有一个nid,找到对应的nid即可; 可以用来把thread dump的东西分析出来。

    然后隔一段时间,在打印一下当前的线程调用栈的信息,查看一下代码是否有问题。

    在dump中,线程一般存在如下几种状态:
    1、RUNNABLE,线程处于执行中
    2、BLOCKED,线程被阻塞
    3、WAITING,线程正在等待

    jstack命令主要用来查看Java线程的调用堆栈的,可以用来分析线程问题(如死锁)。

    jstack用于生成java虚拟机当前时刻的线程快照。

    线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合,生成线程快照的主要目的是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等。

    线程出现停顿的时候通过jstack来查看各个线程的调用堆栈,就可以知道没有响应的线程到底在后台做什么事情,或者等待什么资源。

    如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。

    另外,jstack工具还可以附属到正在运行的java程序中,看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态,jstack是非常有用的。

    展开全文
  • 通过jstack日志分析和问题排查

    万次阅读 2017-02-10 15:44:13
    整个服务系统发生雪崩,系统彻底访问不了),一开始怎么都找不到问题的根源,日志的表现形式是dubbo线程池用完了,那么具体是什么导致的没有找到,后然通过jstack日志分析才找到问题的根源,根源就是系统日志代码写...

                              转自:http://www.ccblog.cn/84.htm

    前段事件公司出现了一个严重故障(调用dubbo服务一直处于超时,整个服务系统发生雪崩,系统彻底访问不了),一开始怎么都找不到问题的根源,日志的表现形式是dubbo线程池用完了,那么具体是什么导致的没有找到,后然通过jstack日志分析才找到问题的根源,根源就是系统日志代码写有问题。通过这个故障我们来了解下如何通过jstack日志分析线上问题。首先了解下jstack


    简介

    jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合,生成线程快照的主要目的是定位线程出现长时间停顿的原因,如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈,就可以知道没有响应的线程到底在后台做什么事情,或者等待什么资源。 如果java程序崩溃生成core文件,jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外,jstack工具还可以附属到正在运行的java程序中,看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态,jstack是非常有用的。


    一:jstack


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

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

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


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


    1:dump 文件里,值得关注的线程状态有


    死锁, Deadlock(重点关注) 

    执行中,Runnable   

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

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

    暂停,Suspended

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

    阻塞, Blocked(重点关注)  

    停止,Parked

    2:Dump文件中的线程状态含义及注意事项

    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。



    三:各种情况演示分享


       分享dump日志我们需要找到一个分析工具,一直没找到好的分析工具后然我同事分享了我一个是IBM开发的工具叫

        "IBM Thread and Monitor Dump Analyzer for Java" 下载地址:https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=2245aa39-fa5c-4475-b891-14c205f7333c

        

        1:Deadlock(死锁)

        

        演示代码


      public class DiedsynchronizedTest {
            public static void main(String[] args) {
                Thread a = new ThreadRunA();
                Thread b = new ThreadRunB();
                a.start();
                b.start();
            }
        }
        class ThreadRunA extends Thread {
            public void run() {
                System.out.println("================A===================");
                synchronized (A.A) {
                    System.out.println("我要开始执行任务A。。。。" + Thread.currentThread().getName());
                    try {
                        Thread.sleep(5000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    synchronized (B.B) {
                    }
                    System.out.println("我在执行任务结束了A。。。。" + Thread.currentThread().getName() + ":" + B.B.hashCode() + ":"
                                       + A.A.hashCode());
                }
            }
        }
        class ThreadRunB extends Thread {
            public void run() {
                System.out.println("================B===================");
                synchronized (B.B) {
                    System.out.println("我要开始执行任务B。。。。" + Thread.currentThread().getName());
                    try {
                        Thread.sleep(1000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    synchronized (A.A) {
                    }
                    System.out.println("我在执行任务结束了B。。。。" + Thread.currentThread().getName() + ":" + B.B + ":" + A.A);
                }
            }
        }
        class A {
            static Integer A = new Integer(1);
        }
        class B {
            static Integer B = new Integer(1);
        }

        这是个简单的死循环的代码,我们用jstack命令dump他的信息导入分析工具如图

        

        从图上能清醒的看到Thread-1和Thread-0现实 Deadlock,而且还帮你定位到了具体的类和行数。

        所以我们在系统中实用锁的时候,一定要考虑到多线程并发,避免出现交叉调用。

        

        2:Runnable 


        有时候我们发现CPU性能消耗很厉害,系统日志也看不出什么问题,那么这个时候我们要坚持运行中的线程有没有出现异常,

        下面我们看下代码

      public class DumpWhileDemo {
            public static void main(String[] args) {
                new Thread(new WhileThread()).start();
                System.out.println();
            }
        }
        class WhileThread implements Runnable {
            @Override
            public void run() {
                while (true) {
                    System.out.println("Thread");
                }
            }
        }

        这段代码我们可以看出new一个线程,线程里面是无线循环,执行main方法后,CPU会直线上升。可以通过linux的top命令看出来。

        我们jstack命令dump它的信息导入查看如下图

        

        我们能看到线程Thread-0的Method方法列显示的是我们的自己写的类,其他两个run的的都显示NO JAVA STACK.

        如果我还是怀疑Thread-0方法那么我多dump几次查看,如果依旧还是这样那么可以说明此访问有问题。

        因为我们使用jstack的时候打印的是当时的状态,所以多打印几次基本能确定是否是有异常方法.不要天真的认为Runnable状态的就

        没问,一切皆有可能。

         

        3:Waiting on monitor entry 和 in Object.wait()


        这个我就直接拿我们线上出的故障来和大家分享下,当时我们分析的时候吧dump日志下载到本地,然后导入到工具里面,看下图

        

        

        线上我们可以清楚的看到DubboServerHandler有200的线程(dubbo服务默认线程池就200,这个了解dubbo的同学都应该清楚),

        我们再看右侧报错的内容backlog日志出问题了,后面我开发同学进一步分析是dubbo日志打印没有控制线程数量。

        

     JAVA程序中,实现线程之间的同步,就要说说Monitor。Monitor是Java中用以实现线程之间的互斥与协作的主要手段,

     它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。下面这个图,描述了线程和 Monitor之间关系,以及线程的状态转换图:

     

     从图中可以看出,每个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程都是 “Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitorentry”,而在 “Wait Set”中等待的线程状态是“in Object.wait()”。 


        4、 Blocked  

        还是上面说的那个故障,这个时候线程已经阻塞了看下图,导致阻塞的原因就是就是200个默认线程一直没有释放或者,

        等待进入的线程太多

        

        

     总结

     Java线程 DUMP的基本知识和分析的基本方法,并且解释了如何利用线程的 DUMP信息,以及结合操作系统的各种资源使用情况,

    分析程序的性能问题,从而达到改进程序,提高性能的目的。

    展开全文
  • GC日志 gceasy.io Jstack日志 fastthread.io

    GC日志

    gceasy.io

    Jstack日志

    fastthread.io

    展开全文
  • JVM分析工具——jstack实践一、不是万能的jstack企业级的Java程序中,java程序出现性能低下甚至直接崩溃时,就不能像解决业务bug那样,从行为表现上来修复问题了。性能问题一般是jvm资源告罄的表现,需要结合jvm的...
  • 需要本地安装JDK并配置JAVA环境变量。 之后使用java -jar jca469.jar即可打开工具。 直接将dump出来的堆栈信息,打开,便可分析
  • jstack 等jvm 性能分析

    千次阅读 2018-05-30 22:04:16
    如果java程序崩溃生成core文件jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地 知道java程序是如何崩溃和在程序何处发生问题 。另外,jstack工具还可以附属到正在运行的java...
  • 使用方法很简单,直接将dump出来的堆栈信息,打开,便可分析
  • 【JVM性能调优】jstack和线程dump分析

    万次阅读 多人点赞 2018-02-22 21:27:59
    1、jstack命令的语法格式:jstack &lt;pid&gt;,可用于查看java进程id。 2、Dump文件:Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到dump文件中。Dump文件是用来给驱动程序编写人员...
  • 问题分析: 1、其他操作都比较流畅,初步怀疑是有同步锁导致的线程阻塞 2、使用jstack命令收集堆栈信息。 进程号为7689,命令如下: jstack -l 7689 &gt; aa.tdump 参考...
  • jstack分析工具

    2020-11-18 14:13:43
    jstack状态web版分析工具,将锁或相关联的线程聚合到一起 http://spotify.github.io/threaddump-analyzer/
  • jstack工具解析及案例

    千次阅读 2016-09-29 13:37:30
    命令描述jstack:用来查看指定java进程的jvm线程栈信息使用方法jstack -[operation] pid 其中operation: -F:当 jstack pid没有响应时,使用-F强制dump线程信息 -m:打印java线程栈和本地线程栈 -l:长期监听,打印...
  • 通过ps到java进程号将进程的jstack信息输出。jstack信息是java进程的线程堆栈信息,通过该信息可以分析java的线程阻塞等问题。
  • jdk分析工具:jps和jstack

    2021-02-27 22:30:18
    jstack 如果java程序崩溃生成core文件jstack工具可以用来获得core文件的java stack和native stack的信息,从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外,jstack工具还可以附属到正在运行的...
  • 前一段时间上线的系统升级之后,出现了严重的高CPU的问题,于是开始了一系列的优化处理之中,现在...在对Java内存泄漏进行分析的时候,需要对jvm运行期间的内存占用、线程执行等情况进行记录的dump文件,常用的主要...
  • JSTACK 内存溢出分析

    2021-03-13 05:09:25
    引用:http://developer.51cto.com/art/201203/321424.htm1、介绍jstack用于打印出给定的java进程ID或corefile或远程调试服务的Java堆栈信息,如果是在64...jstack [-l] pid如果java程序崩溃生成core文件jstack工...
  • jstack生成的Thread Dump日志.docx 系统线程状态 (Native Thread Status) 系统线程有如下状态: deadlock 死锁线程,一般指多个线程调用期间进入了相互资源占用,导致一直等待无法释放的情况。 ...
  • 一般问题发生时我们都会去查看日志,经常遇到没有日志的情况(此时服务无法响应client请求),甚至要去找几个小时前的日志现象发生时,有些接口甚至没有日志打印,查找起来很困难,利用jvm的线程栈工具jstack对于...
  • java性能分析 jmap jstack

    2018-08-06 19:58:11
    java程序性能分析thread dump和heap dump,dump文件:在故障定位(尤其是out of memory)和性能分析的时候,dump文件记录了JVM运行期间的内存占用、线程执行等情况。 heap dump:记录某一时刻JVM堆中对象使用情况,哪些...
  • jstack堆栈日志分析

    千次阅读 2019-01-12 16:33:58
    jstack Dump 日志文件中的线程状态, dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注) 执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on ...
  • jstack调试core文件

    2018-09-19 15:38:00
    摘自:https://stackoverflow.com/questions/37331266/jstack-throws-exception-interrogating-a-core ...// 错误示例 1 [root@localhost rpmuser]# jstack core.2299 2 Attaching to remote server core.2299, p...
  • 大部分的说法也只是看oom日志,使用jstack或者是其他的分析工具进行分析。但是具体怎么做还是感觉有点含糊。不够清楚 准备工作 一个spring boot的项目,用docker打包启动。注意java进程不要占据Pid为1的位置。用...
  • 1、使用jstack命令打印堆栈信息 jstack -l pid>> thread.txt 示例 jstack -l 7052 >> thread.txt 2、分析堆栈信息 将thread.txt下载到本地,使用IBM Thread and Monitor Dump Analyzer for Java...
  • (2)堆信息:jmap -dump 输出的文件,(3)jstat查看gc情况,jstat -gc 间隔毫秒数 比如 jstat -gc 12345 5000 也就是每隔5秒打印进程12345的 gc情况一、看一下 jstackjstack -m >jvm_deadlocks.txt jstack -l >...
  • Jstack 命令分析

    2021-03-13 21:14:32
    Jstack 命令分析jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,如果是在64位机器上,需要指定选项"-J-d64",Windows的jstack使用方式只支持以下的这种方式:jstack [-l][F] pid如果...
  • jstack dump日志文件详细分析

    千次阅读 2014-10-28 17:46:20
    jstack Dump 日志文件中的线程状态dump 文件里,值得关注的线程状态有:  (特殊颜色的部分需要重点关注) 死锁,Deadlock 执行中,Runnable 等待资源,Waiting on condition 等待获取监视器,Waiting on ...
  • 也许是它病了,需要用jstack拍个片子分析分析,才能诊断具体什么病症,是死锁综合征,还是死循环等其他病症,本文我们一起来学习jstack命令~jstack 的功能jstack用法线程状态等基础回顾实战案例1:jstack 分析死锁...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 17,203
精华内容 6,881
关键字:

jstack文件分析