怎样使用jstack诊断Java应用程序故障

怎样使用jstack诊断Java应用程序故障

intellij idea默认文件是自动保存的，但是手头有个项目jsp文件改动后，在tomcat中不能立即响应变化。要jsp文件改动后立刻看到变化，有个配置。
　　在idea tomcat 中server的配置里，有个on frame deactivation，选择update classes and resources。另外有个配置on update action，就是手动操作的时候采取什么动作，可以重启服务器，也可以像上面一样更新类和资源文件，我选的是Redeploy。 可是当前项目没有update classes and resources这个选项，有个Hot Swap classes。
　　这是由于服务器添加的Artifact类型问题，一般一个module对应两种类型的Artifact，一种是war，一种是war explored。
　　war就是已war包形式发布，当前项目是这种形式，在这种形式下on frame deactivation配置没有update classes and resources选项。war explored是发布文件目录，选择这种形式，on frame deactivation中就出现update classes and resources选项了。
  
public class DeadLock {  

    public static void main(String[] args) {  
        final Object obj_1 = new Object(), obj_2 = new Object();  

        Thread t1 = new Thread("t1"){  
            @Override  
            public void run() {  
                synchronized (obj_1) {  
                    try {  
                        Thread.sleep(3000);  
                    } catch (InterruptedException e) {}  

                    synchronized (obj_2) {  
                        System.out.println("thread t1 done.");  
                    }  
                }  
            }  
        };  

        Thread t2 = new Thread("t2"){  
            @Override  
            public void run() {  
                synchronized (obj_2) {  
                    try {  
                        Thread.sleep(3000);  
                    } catch (InterruptedException e) {}  

                    synchronized (obj_1) {  
                        System.out.println("thread t2 done.");  
                    }  
                }  
            }  
        };  

        t1.start();  
        t2.start();  
    }  

}

如果单靠通过查看代码是很难去发现这个问题,在这一次故障排查中,我也学到了怎样更好的使用jvm监控工具来进行诊断,主要用到了jstack和jmap命令,jmap上次已经讲过就不再讲了,下面就一个例子来讲怎么使用jstack来对的java程序进行诊断。 首先让我们来了解一下jstack这个命令的作用,jstack 是一个可以返回在应用程序上运行的各种各样线程的一个完整转储的实用程序,您可以使用它查明问题。jstack [-l] ,jpid可以通过使用jps命令来查看当前java程序的jpid值,-l是可选参数,它可以显示线程阻塞/死锁情况。 public class deadlock { public static void main(string[] args) { final object obj_1 = new object(), obj_2 = new object(); thread t1 = new thread("t1"){ @override public void run() { synchronized (obj_1) { try { thread.sleep(3000); } catch (interruptedexception e) {} synchronized (obj_2) { system.out.println("thread t1 done."); } } } }; thread t2 = new thread("t2"){ @override public void run() { synchronized (obj_2) { try { thread.sleep(3000); } catch (interruptedexception e) {} synchronized (obj_1) { system.out.println("thread t2 done."); } } } }; t1.start(); t2.start(); } } 以上deadlock类是一个死锁的例子,假使在我们不知情的情况下,运行deadlock后,发现等了n久都没有在屏幕打印线程完成信息。这个时候我们就可以使用jps查看该程序的jpid值和使用jstack来生产堆栈结果问题。 $ java -cp deadlock.jar deadlock & $ $ jps 3076 jps 448 deadlock $ jstack -l 448 > deadlock.jstack 结果文件deadlock.jstack内容如下： 2011-03-20 23:05:20 full thread dump java hotspot(tm) client vm (19.1-b02 mixed mode, sharing): "destroyjavavm" prio=6 tid=0x00316800 nid=0x9fc waiting on condition [0x00000000] java.lang.thread.state: runnable locked ownable synchronizers: - none "t2" prio=6 tid=0x02bcf000 nid=0xc70 waiting for monitor entry [0x02f6f000] java.lang.thread.state: blocked (on object monitor) at com.demo.deadlock$2.run(deadlock.java:40) - waiting to lock <0x22a297a8> (a java.lang.object) - locked <0x22a297b0> (a java.lang.object) locked ownable synchronizers: - none "t1" prio=6 tid=0x02bce400 nid=0xba0 waiting for monitor entry [0x02f1f000] java.lang.thread.state: blocked (on object monitor) at com.demo.deadlock$1.run(deadlock.java:25) - waiting to lock <0x22a297b0> (a java.lang.object) - locked <0x22a297a8> (a java.lang.object) locked ownable synchronizers: - none "low memory detector" daemon prio=6 tid=0x02bb9400 nid=0xa6c runnable [0x00000000] java.lang.thread.state: runnable locked ownable synchronizers: - none "compilerthread0" daemon prio=10 tid=0x02bb2800 nid=0xcb8 waiting on condition [0x00000000] java.lang.thread.state: runnable locked ownable synchronizers: - none "attach listener" daemon prio=10 tid=0x02bb1000 nid=0x7f4 waiting on condition [0x00000000] java.lang.thread.state: runnable locked ownable synchronizers: - none "signal dispatcher" daemon prio=10 tid=0x02bd2800 nid=0xd80 runnable [0x00000000] java.lang.thread.state: runnable locked ownable synchronizers: - none "finalizer" daemon prio=8 tid=0x02bab000 nid=0xe1c in object.wait() [0x02d3f000] java.lang.thread.state: waiting (on object monitor) at java.lang.object.wait(native method) - waiting on <0x229e1148> (a java.lang.ref.referencequeue$lock) at java.lang.ref.referencequeue.remove(referencequeue.java:118) - locked <0x229e1148> (a java.lang.ref.referencequeue$lock) at java.lang.ref.referencequeue.remove(referencequeue.java:134) at java.lang.ref.finalizer$finalizerthread.run(finalizer.java:159) locked ownable synchronizers: - none "reference handler" daemon prio=10 tid=0x02ba6800 nid=0xbe0 in object.wait() [0x02cef000] java.lang.thread.state: waiting (on object monitor) at java.lang.object.wait(native method) - waiting on <0x229e1048> (a java.lang.ref.reference$lock) at java.lang.object.wait(object.java:485) at java.lang.ref.reference$referencehandler.run(reference.java:116) - locked <0x229e1048> (a java.lang.ref.reference$lock) locked ownable synchronizers: - none "vm thread" prio=10 tid=0x02b6a400 nid=0x568 runnable "vm periodic task thread" prio=10 tid=0x02bc8400 nid=0x75c waiting on condition jni global references: 878 found one java-level deadlock: ============================= "t2": waiting to lock monitor 0x02baaeec (object 0x22a297a8, a java.lang.object), which is held by "t1" "t1": waiting to lock monitor 0x02baa2bc (object 0x22a297b0, a java.lang.object), which is held by "t2" java stack information for the threads listed above: =================================================== "t2": at com.demo.deadlock$2.run(deadlock.java:40) - waiting to lock <0x22a297a8> (a java.lang.object) - locked <0x22a297b0> (a java.lang.object) "t1": at com.demo.deadlock$1.run(deadlock.java:25) - waiting to lock <0x22a297b0> (a java.lang.object) - locked <0x22a297a8> (a java.lang.object) found 1 deadlock. 从这个结果文件我们一看到发现了一个死锁,具体是线程t2在等待线程t1,而线程t1在等待线程t2造成的,同时也记录了线程的堆栈和代码行数,通过这个堆栈和行数我们就可以去检查对应的代码块,从而发现问题和解决问题。

如以上回答内容为低俗、色情、不良、暴力、侵权、涉及违法等信息，可以点下面链接进行举报！

点此我要举报以上问答信息