转自:http://blog.csdn.net/jackie_xiaonan/article/details/8546541
最近一段时间比较辛苦,产品上线之后问题不断,最近更出现了多个阻塞问题,全靠分析进程栈文件的内容来辅助定位问题。平心而论,做Java开发比较省心,平时开发过程中可能不像在Linux下做C/C++开发的兄弟一样,经常需要分析程序栈和Core文件,而且Java开发过程中可用的调试工具非常多,功能强大,而且调试时也非常方便,但是,分析程序栈仍然是不可或缺的、重要的方法,尤其在产品上线之后,用户出于各种原因可能不乐意软件开发人员部署各种各样的工具,这时,分析程序栈就成了唯一可用并且好用的方法。
首先,Java应用程序的栈如何获取?JDK提供了非常多的工具来完成这个需求,比如GUI界面的jconsole、jvisualvm,命令行下的jstack。GUI的工具比较简单,这里主要讲jstack,比较基础,特别适合在服务器上使用。如下是jstack工具的使用帮助。
- jstack -l
- 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
-l,一般用于附加到运行状态的Java应用,除导出栈信息外,还会记录各个线程当前持有或者等待的锁信息。
-m,附加到运行状态的Java应用,可以同时导出java语言和本地栈的信息。
-F,对于-l和-m选项无法导出栈信息时,就只好使用-F选项,强制导出应用的栈信息;照我的理解,这是最后的选择。
jstack强大之处在于除了可以导出在本地运行的Java应用的栈信息,还可以导出运行于远程机器上的Java应用的栈信息,不过这个特性没有怎么用过,需要什么配置还不清楚,这里就不展开了。
下面对一段实例解析,比如对日常开发中常用到的Eclipse导出栈信息,如下。
- 2013-01-13 11:02:31
- Full thread dump Java HotSpot(TM) Client VM (23.1-b03 mixed mode, sharing):
- "[ThreadPool Manager] - Idle Thread" daemon prio=6 tid=0x069a3400 nid=0x84 in Object.wait() [0x0795f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x239102b8> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor)
- at java.lang.Object.wait(Object.java:503)
- at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:106)
- - locked <0x239102b8> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor)
- Locked ownable synchronizers:
- - None
- "Worker-2" prio=6 tid=0x032e5400 nid=0xfc in Object.wait() [0x0655f000]
- java.lang.Thread.State: TIMED_WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x27fd3118> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185)
- - locked <0x27fd3118> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51)
- Locked ownable synchronizers:
- - None
- "Worker-1" prio=6 tid=0x052dd400 nid=0xd88 in Object.wait() [0x0645f000]
- java.lang.Thread.State: TIMED_WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x27fd3118> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185)
- - locked <0x27fd3118> (a org.eclipse.core.internal.jobs.WorkerPool)
- at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217)
- at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51)
- Locked ownable synchronizers:
- - None
- "Bundle File Closer" daemon prio=6 tid=0x052d0800 nid=0xed8 in Object.wait() [0x04aef000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x294bc768> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
- at java.lang.Object.wait(Object.java:503)
- at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397)
- - locked <0x294bc768> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
- at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333)
- Locked ownable synchronizers:
- - None
- "Java indexing" daemon prio=4 tid=0x04ddd400 nid=0x1b0 in Object.wait() [0x05e5f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x289f02e8> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager)
- at java.lang.Object.wait(Object.java:503)
- at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:381)
- - locked <0x289f02e8> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager)
- at java.lang.Thread.run(Unknown Source)
- Locked ownable synchronizers:
- - None
- "[Timer] - Main Queue Handler" daemon prio=6 tid=0x0398d800 nid=0x824 in Object.wait() [0x0416f000]
- java.lang.Thread.State: TIMED_WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x28105b68> (a java.lang.Object)
- at org.eclipse.equinox.internal.util.impl.tpt.timer.TimerImpl.run(TimerImpl.java:141)
- - locked <0x28105b68> (a java.lang.Object)
- at java.lang.Thread.run(Unknown Source)
- Locked ownable synchronizers:
- - None
- "Framework Event Dispatcher" daemon prio=6 tid=0x02c4c400 nid=0x56c in Object.wait() [0x03f6f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x27fd3140> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
- at java.lang.Object.wait(Object.java:503)
- at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397)
- - locked <0x27fd3140> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
- at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333)
- Locked ownable synchronizers:
- - None
- "Start Level Event Dispatcher" daemon prio=6 tid=0x03178400 nid=0xd50 in Object.wait() [0x03e6f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x27fd31b0> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
- at java.lang.Object.wait(Object.java:503)
- at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397)
- - locked <0x27fd31b0> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread)
- at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333)
- Locked ownable synchronizers:
- - None
- "State Data Manager" daemon prio=6 tid=0x02c4f400 nid=0x908 waiting on condition [0x03d6f000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at org.eclipse.osgi.internal.baseadaptor.StateManager.run(StateManager.java:306)
- at java.lang.Thread.run(Unknown Source)
- Locked ownable synchronizers:
- - None
- "Service Thread" daemon prio=6 tid=0x02c45c00 nid=0x1ac runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "C1 CompilerThread0" daemon prio=10 tid=0x02c43000 nid=0xd68 waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Attach Listener" daemon prio=10 tid=0x02c41800 nid=0xf64 waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Signal Dispatcher" daemon prio=10 tid=0x02c40000 nid=0x8ec runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Finalizer" daemon prio=8 tid=0x02c25000 nid=0xeb0 in Object.wait() [0x030ef000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x27eaf9c8> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- - locked <0x27eaf9c8> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(Unknown Source)
- at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
- Locked ownable synchronizers:
- - None
- "Reference Handler" daemon prio=10 tid=0x02c20000 nid=0xe90 in Object.wait() [0x02fef000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x27eaf680> (a java.lang.ref.Reference$Lock)
- at java.lang.Object.wait(Object.java:503)
- at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
- - locked <0x27eaf680> (a java.lang.ref.Reference$Lock)
- Locked ownable synchronizers:
- - None
- "main" prio=6 tid=0x00ad8400 nid=0xe4c runnable [0x0012f000]
- java.lang.Thread.State: RUNNABLE
- at org.eclipse.swt.internal.win32.OS.WaitMessage(Native Method)
- at org.eclipse.swt.widgets.Display.sleep(Display.java:4311)
- at org.eclipse.ui.application.WorkbenchAdvisor.eventLoopIdle(WorkbenchAdvisor.java:364)
- at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2406)
- at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
- at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
- at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
- at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
- at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493)
- at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
- at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
- at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194)
- 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:368)
- at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
- at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
- at java.lang.reflect.Method.invoke(Unknown Source)
- at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
- at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
- at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
- Locked ownable synchronizers:
- - None
- "VM Thread" prio=10 tid=0x02c1e800 nid=0x788 runnable
- "VM Periodic Task Thread" prio=10 tid=0x02c53800 nid=0xfbc waiting on condition
- JNI global references: 272
Eclipse是用Java开发的,所以导出的栈信息从格式上应当是具有普适性的。从上述样例中,首先可以看出这段栈信息是在2013-01-13 11:02:31导出的,时间精确到了秒;另外还给出了Eclipse运行时使用的JRE的版本和类型。JRE分为桌面版和服务器版,Client标识当前应用使用了桌面版JRE,针对桌面应用进行了特别的优化,其它方面的区别可以Google一下,差别比较大,这里不赘述。java应用启动时,可以通过命令行选项控制对字节码的执行方式为纯解释、解释加编译(混合,mixed mode)、纯编译,样例中使用了混合模式,JRE在运行时会对热点代码进行重点优化,翻译成机器代码运行,至于何为热点,可以继续Google,JVM有一套复杂的算法来甄别。
- "[ThreadPool Manager] - Idle Thread" daemon prio=6 tid=0x069a3400 nid=0x84 in Object.wait() [0x0795f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x239102b8> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor)
- at java.lang.Object.wait(Object.java:503)
- at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:106)
- - locked <0x239102b8> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor)
- Locked ownable synchronizers:
- - None
这是从样例中截取出来的一个线程的栈信息,从中可以得知如下的信息:
1、这个线程的名称为[ThreadPool Manager] - Idle Thread,实际开发过程中使用可以使用Thread对象的setName方法修改;这里可以看出设置线程名字属性的必要性,导出栈信息的时候就有用了,可以通过线程名字方便的定位到问题代码块;
2、优先级为6,不过优先级意义不大,对分析应用帮助不大,Java的教程中也不推荐修改线程的优先级,所以这里跳过;
3、tid和nid,16进制表示,这两个字段中有一个可以对应到操作系统调度时使用的线程ID,这在Linux下特别有用,因为top -H命令可以输出各个线程的CPU占用率,借助栈信息,可以方便的定位到CPU占用高的线程,这个很有用,在其它平台暂时还看不出什么意义;
4、当前栈顶,为java.lang.Object.wait方法;
5、线程状态,java.lang.Thread.State: WAITING (on object monitor);java.lang.Thread.State是什么?有兴趣的话可以翻看JDK的源码,源码很简单,注释很详细,给出了Java线程可能存在的状态;
6、当前线程是否处于同步块内, Locked ownable synchronizers:,这里值为None,说明当前线程没有处于同步块内。
限于我自己对于Java栈的理解,这里对于单个线程栈的解读比较粗,不过说来应当是够用了。
上面写了Java程序栈的获取方法和格式,那么有一个问题,为什么要获取栈信息、解析这个栈信息有什么用呢?这是一个好问题,毕竟无利不起早,程序员是世界上最聪明的人类群体,没有时间花费在没有产出的事情。虽然做Java开发相比较C/C++要容易一些,但在分析死锁、CPU高的问题时,分析的手法和C/C++程序员差不多,基本都要通过栈调用来分析问题。
通过栈信息分析CPU高的方法上面已经讲过,这里简单说明一下,借助Linux下的top -H命令,输出全部线程的CPU、内存信息,找到占用比较高的线程ID,换算成16进制,然后在栈信息文件中搜索,检查是否有匹配行,如果找到并且位置在nid=或者tid=的后面,说明事发线程找到了。
通过栈信息分析死锁问题的方法相对要麻烦一点,需要一点准备知识,对Java语言的线程可能处于的状态有一定了解,Java语言教程里的讲解比较抽象,这里先来点干货,直接上点JDK中的源码。引用JDK的源码希望不会招致JDK开发人员的不满,这里仅仅是为了叙述方便。
- public enum State {
- /**
- * Thread state for a thread which has not yet started.
- */
- NEW,
- /**
- * Thread state for a runnable thread. A thread in the runnable
- * state is executing in the Java virtual machine but it may
- * be waiting for other resources from the operating system
- * such as processor.
- */
- RUNNABLE,
- /**
- * Thread state for a thread blocked waiting for a monitor lock.
- * A thread in the blocked state is waiting for a monitor lock
- * to enter a synchronized block/method or
- * reenter a synchronized block/method after calling
- * {@link Object#wait() Object.wait}.
- */
- BLOCKED,
- /**
- * Thread state for a waiting thread.
- * A thread is in the waiting state due to calling one of the
- * following methods:
- * <ul>
- * <li>{@link Object#wait() Object.wait} with no timeout</li>
- * <li>{@link #join() Thread.join} with no timeout</li>
- * <li>{@link LockSupport#park() LockSupport.park}</li>
- * </ul>
- *
- * <p>A thread in the waiting state is waiting for another thread to
- * perform a particular action.
- *
- * For example, a thread that has called <tt>Object.wait()</tt>
- * on an object is waiting for another thread to call
- * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
- * that object. A thread that has called <tt>Thread.join()</tt>
- * is waiting for a specified thread to terminate.
- */
- WAITING,
- /**
- * Thread state for a waiting thread with a specified waiting time.
- * A thread is in the timed waiting state due to calling one of
- * the following methods with a specified positive waiting time:
- * <ul>
- * <li>{@link #sleep Thread.sleep}</li>
- * <li>{@link Object#wait(long) Object.wait} with timeout</li>
- * <li>{@link #join(long) Thread.join} with timeout</li>
- * <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
- * <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
- * </ul>
- */
- TIMED_WAITING,
- /**
- * Thread state for a terminated thread.
- * The thread has completed execution.
- */
- TERMINATED;
- }
对于有一定多线程开发经验的人来说,上面的注释理解起来应当不是问题。
1、什么状态下是NEW,线程对象被new出来,但是还没有调用start方法,这时就被称为NEW;
2、RUNNABLE,线程对象已经被调用了start方法,但是,这个线程的run方法可能运行也可能没有运行,依赖于操作系统的行为;
3、BLOCKED,简单的说,线程进入了synchronized关键字标识的同步块,但和4状态有所区别;
4、WAITING和TIMED_WAITING差不多,一般是调用了对象的wait方法,需要其它线程在特定场景使用notify/notifyAll方法;
5、TERMINATED,这个状态比较直白,run方法退出运行,即进入这个状态;
栈信息本身并不神秘,格式和内容都比较单一,但借助程序的调用栈信息可以观察到很多有用的信息。借助栈信息来分析有时候被认为是一种秘技,实际上这是一种误解。古人云,读书百遍,其义自见,程序调用栈信息看多了自然就会明白。下面结合java.lang.Thread.State类的注释,举几个代码及其调用栈的例子,相信对于聪明的同学,入门就不困难了。但原理什么的,就得靠自己了,至少得读一下java.lang.Thread.State类的注释吧。
下面的例子都是使用Oracle公司出品的Java7编译和测试的,具体的版本信息如下。
- java -version
- java version "1.7.0_11"
- Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
- Java HotSpot(TM) Client VM (build 23.6-b04, mixed mode, sharing)
例子一
- public class DeadLock {
- public static void main(final String[] args) throws Exception {
- final Object obj = new Object();
- new Thread() {
- @Override
- public void run() {
- callWait(obj);
- };
- }.start();
- Thread.sleep(3000L);
- synchronized (obj) {
- try {
- obj.wait();
- }
- catch (final InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- static void callWait(final Object obj) {
- synchronized (obj) {
- try {
- obj.wait();
- }
- catch (final InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- }
这段代码并不复杂,做的事情比较明确,一共存在有两个线程,都会调用callWait方法,在callWait方法中又会对一个对象加锁,调用对应的wait方法。这个例子模拟的错误就是wait方法和notify/notifyAll方法没有成对的调用,导致程序出现死锁现象。问题说到这里,解决的方法自然非常明确,但是重点在根据程序的调用栈来发现问题,因而需要实地执行程序,同时使用jstack工具获取栈信息,了解从栈信息中如何发现问题的根本原因。
- "main" prio=6 tid=0x00868800 nid=0x1370 in Object.wait() [0x0098f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x22bc2c08> (a java.lang.Object)
- at java.lang.Object.wait(Object.java:503)
- at DeadLock.main(DeadLock.java:30)
- - locked <0x22bc2c08> (a java.lang.Object)
- Locked ownable synchronizers:
- - None
- "Thread-0" prio=6 tid=0x02b22000 nid=0x1044 in Object.wait() [0x0316f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x22bc2c08> (a java.lang.Object)
- at java.lang.Object.wait(Object.java:503)
- at DeadLock$1.run(DeadLock.java:14)
- - locked <0x22bc2c08> (a java.lang.Object)
- Locked ownable synchronizers:
- - None
上面只是栈文件中的一部分,两个线程的栈信息块之间可能也没有离这么近,为了缩短篇幅,做了一定的裁剪,去掉了问题不相关的部分。可以发现0x22bc2c08一共出现了四次,两段栈信息中各出现再次,顺序一样,都是调用了wait方法后进入了WAITING状态,同时都没有持有对象的锁。有趣的现象哈。
例子二
- public class DeadLock {
- public static void main(final String[] args) throws Exception {
- Thread.currentThread().setName("main thread");
- final Thread r = new Thread() {
- @Override
- public void run() {
- try {
- Thread.sleep(200000L);
- }
- catch (final InterruptedException e) {
- e.printStackTrace();
- }
- };
- };
- r.setName("another thread");
- r.start();
- System.out.println("start to sleeping");
- Thread.sleep(100000L);
- System.out.println("start to joining");
- r.join();
- }
- }
这段样例代码很简单,就是两个线程各自调用了sleep方法,但时间不相同,然后在主函数结尾处,还等待新线程结束。对于这段样例,存在两次抓取栈信息的机会,第一次是屏幕输出“start to sleeping”时,可以截取出如下的栈信息。
- "another thread" prio=6 tid=0x02b22400 nid=0x2058 waiting on condition [0x0316f000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at DeadLock$1.run(DeadLock.java:9)
- Locked ownable synchronizers:
- - None
- "main thread" prio=6 tid=0x00868800 nid=0x2720 waiting on condition [0x0098f000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at DeadLock.main(DeadLock.java:19)
- Locked ownable synchronizers:
- - None
很明显,两个线程当前都处于sleep状态。第二次抓取栈信息是屏幕输出“start to joining”,这时主线程的等待已执行完成,主线程开始等待新线程执行完成,可以截取到如下的栈信息。
- "another thread" prio=6 tid=0x02b22400 nid=0x2058 waiting on condition [0x0316f000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at DeadLock$1.run(DeadLock.java:9)
- Locked ownable synchronizers:
- - None
- "main thread" prio=6 tid=0x00868800 nid=0x2720 in Object.wait() [0x0098f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x22bc3d70> (a DeadLock$1)
- at java.lang.Thread.join(Thread.java:1258)
- - locked <0x22bc3d70> (a DeadLock$1)
- at java.lang.Thread.join(Thread.java:1332)
- at DeadLock.main(DeadLock.java:21)
- Locked ownable synchronizers:
- - None
和预期一致,新线程处于sleep状态,而主线程已进入了wait状态。
例子三
- public class DeadLock {
- public static void main(final String[] args) throws Exception {
- final Object lock1 = new Object();
- final Object lock2 = new Object();
- Thread.currentThread().setName("main-thread");
- final Thread r = new Thread("another-thread") {
- @Override
- public void run() {
- try {
- synchronized (lock2) {
- Thread.sleep(20000);
- synchronized (lock1) {
- Thread.sleep(20000);
- }
- }
- }
- catch (final Exception e) {
- e.printStackTrace();
- }
- }
- };
- r.start();
- Thread.sleep(5000);
- synchronized (lock1) {
- Thread.sleep(20000);
- synchronized (lock2) {
- Thread.sleep(20000);
- }
- }
- }
- }
这段代码可能有点复杂,但原理不麻烦,就是描述了经典的加锁顺序问题。栈信息比较有趣,裁剪之后如下。
- "another-thread" prio=6 tid=0x02b22400 nid=0x2250 waiting for monitor entry [0x0316f000]
- java.lang.Thread.State: BLOCKED (on object monitor)
- at DeadLock$1.run(DeadLock.java:14)
- - waiting to lock <0x22bc3f90> (a java.lang.Object)
- - locked <0x22bc3f98> (a java.lang.Object)
- Locked ownable synchronizers:
- - None
- "main-thread" prio=6 tid=0x00868800 nid=0x2634 waiting for monitor entry [0x0098f000]
- java.lang.Thread.State: BLOCKED (on object monitor)
- at DeadLock.main(DeadLock.java:28)
- - waiting to lock <0x22bc3f98> (a java.lang.Object)
- - locked <0x22bc3f90> (a java.lang.Object)
- Locked ownable synchronizers:
- - None
- Found one Java-level deadlock:
- =============================
- "another-thread":
- waiting to lock monitor 0x02ad433c (object 0x22bc3f90, a java.lang.Object),
- which is held by "main-thread"
- "main-thread":
- waiting to lock monitor 0x02ad363c (object 0x22bc3f98, a java.lang.Object),
- which is held by "another-thread"
- Java stack information for the threads listed above:
- ===================================================
- "another-thread":
- at DeadLock$1.run(DeadLock.java:14)
- - waiting to lock <0x22bc3f90> (a java.lang.Object)
- - locked <0x22bc3f98> (a java.lang.Object)
- "main-thread":
- at DeadLock.main(DeadLock.java:28)
- - waiting to lock <0x22bc3f98> (a java.lang.Object)
- - locked <0x22bc3f90> (a java.lang.Object)
- Found 1 deadlock.
主线程中提示了当前持有的锁和期望获取的锁,而新线程也存在类似的提示,只是获取锁的顺序不同。从栈信息可以看出,两个线程都处于BLOCKED状态。可能是源代码中的问题过于明显,导出的栈信息中给出了死锁的提示信息,实际项目的业务代码比样例要复杂,JVM可能做不到这么智能。这里的提示信息多多少少有点让我失望,在主线程栈信息的最后一部分没有输出当前持有锁的列表,很奇怪,不知道是不是和JDK的实现有关。
样例四
- import java.security.SecureRandom;
- import java.util.concurrent.SynchronousQueue;
- import java.util.concurrent.ThreadFactory;
- import java.util.concurrent.ThreadPoolExecutor;
- import java.util.concurrent.TimeUnit;
- import java.util.concurrent.atomic.AtomicInteger;
- import java.util.concurrent.locks.ReentrantLock;
- public class DeadLock {
- private final ReentrantLock lock = new ReentrantLock();
- private static final SecureRandom random = new SecureRandom();
- public DeadLock() {
- }
- public void runWork() {
- final ThreadPoolExecutor threadpool = new ThreadPoolExecutor(3, 3, 60L, TimeUnit.DAYS,
- new SynchronousQueue<Runnable>(), new ThreadFactory() {
- private final AtomicInteger counter = new AtomicInteger(1);
- @Override
- public Thread newThread(final Runnable r) {
- return new Thread(r, "thread-sn-" + counter.getAndIncrement());
- }
- });
- threadpool.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
- Thread.currentThread().setName("main-thread");
- for (int i = 0; i < 15; ++i) {
- threadpool.submit(new Runnable() {
- @Override
- public void run() {
- try {
- int timeout = 0;
- while ((timeout = random.nextInt()) <= 0) {
- }
- timeout = timeout % 111;
- Thread.sleep(timeout * 100L);
- lock.lock();
- callLongTime();
- }
- catch (final Exception e) {
- e.printStackTrace();
- }
- finally {
- lock.unlock();
- }
- }
- });
- }
- threadpool.shutdown();
- }
- public static void main(final String[] args) throws Exception {
- new DeadLock().runWork();
- }
- static long callLongTime() {
- System.out.println("thread name " + Thread.currentThread().getName());
- long sum = 0;
- for (long i = 0; i < 10000000000L; ++i) {
- sum = sum ^ i + i;
- }
- return sum;
- }
- }
最后一个样例,写的比较复杂,但事情比较简单,线程之间的同步关键字换成了Java5提供的concurrent库中的重入锁。
- "thread-sn-3" prio=6 tid=0x02de8400 nid=0x2688 runnable [0x0320f000]
- java.lang.Thread.State: RUNNABLE
- at DeadLock.callLongTime(DeadLock.java:63)
- at DeadLock$2.run(DeadLock.java:41)
- at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
- at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
- at java.util.concurrent.FutureTask.run(FutureTask.java:166)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
- at java.lang.Thread.run(Thread.java:722)
- Locked ownable synchronizers:
- - <0x22be1488> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- - <0x22be66d8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
- "thread-sn-2" prio=6 tid=0x02de6c00 nid=0x218c waiting on condition [0x031bf000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x22be1488> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
- at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
- at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
- at DeadLock$2.run(DeadLock.java:40)
- at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
- at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
- at java.util.concurrent.FutureTask.run(FutureTask.java:166)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
- at java.lang.Thread.run(Thread.java:722)
- Locked ownable synchronizers:
- - <0x22be64e0> (a java.util.concurrent.ThreadPoolExecutor$Worker)
栈信息比较有趣,JVM在每个线程线的最后部分输出了当前线程持有的锁对象,类型和地址。从上述的信息中可以找到,当前处于运行状态的线程持有了一个地址为0x22be1488的锁,而这个锁正是其它线程等待获取的锁对象。
关于Java应用导出的栈信息,由于包含了线程ID,因而还有一个妙用,即可以用来分析各个线程CPU占用情况,这样可以用来分析CPU占用过高的问题,从而指导CPU相关的优化类工作。
先看导出的栈信息的一部分。
- "main" prio=6 tid=0x00868c00 nid=0x19a4 waiting on condition [0x0098f000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at DeadLock.main(DeadLock.java:3)
- Locked ownable synchronizers:
- - None
nid字段即标识出了操作系统的线程ID,使用16进程表示。现在有了操作系统的线程ID,那么有什么方法可以观察到各个线程占用的CPU吗?
对于Linux平台,可以使用top命令和选项H,样例如下。
- # top -H -p <pid>
从输出中可以找到各个线程的ID,使用10进制表示。为了找到各个线程对应的栈信息,需要手工把用top命令观察到的线程ID转换为16进制表示,然后在进程的栈信息文件中查找。
对于Windows平台,需要下载一个免费的工具,鼎鼎大名的ProcessExplorer。通过这个工具,可以方便的查看目标Java进程的线程ID列表及CPU占用率,但为了查明占用CPU高的线程具体在做什么,还是需要将线程ID手工转换为16进制表示,然后到栈信息文件中查找。
如果亲自动手分析Java应用导出的栈信息的话,可以惊讶的发现,原来栈信息中包括了JVM完成自己特定任务的线程栈信息。下面看个例子。
- public class Test {
- public static void main(final String[] args) throws Exception {
- Thread.sleep(200000L);
- }
- }
这是一段非常简单的代码,只有一个线程,并且只做了一件事,那就是睡大觉。为了能够说明问题,在Eclipse中运行这段代码时,增加如下的JVM启动参数,配置如下参数的原因下面会提到。
- -XX:+UseConcMarkSweepGC
程序启动后,使用jstack命令导出线程栈的列表,如下。
- 2013-02-12 01:27:24
- Full thread dump Java HotSpot(TM) Client VM (23.6-b04 mixed mode):
- "Service Thread" daemon prio=6 tid=0x17975c00 nid=0x202c runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "C1 CompilerThread0" daemon prio=10 tid=0x17973400 nid=0x25dc waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Attach Listener" daemon prio=10 tid=0x1796e400 nid=0x1cf0 waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Signal Dispatcher" daemon prio=10 tid=0x1796cc00 nid=0x1d3c runnable [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Surrogate Locker Thread (Concurrent GC)" daemon prio=6 tid=0x1796b400 nid=0x21ec waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- Locked ownable synchronizers:
- - None
- "Finalizer" daemon prio=8 tid=0x17921800 nid=0x2618 in Object.wait() [0x177df000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x02be56a0> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- - locked <0x02be56a0> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
- at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
- Locked ownable synchronizers:
- - None
- "Reference Handler" daemon prio=10 tid=0x02b3e400 nid=0x2304 in Object.wait() [0x1778f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x02be5278> (a java.lang.ref.Reference$Lock)
- at java.lang.Object.wait(Object.java:503)
- at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- - locked <0x02be5278> (a java.lang.ref.Reference$Lock)
- Locked ownable synchronizers:
- - None
- "main" prio=6 tid=0x00868c00 nid=0x1dc waiting on condition [0x0098f000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at DeadLock.main(DeadLock.java:3)
- Locked ownable synchronizers:
- - None
- "VM Thread" prio=10 tid=0x02b38800 nid=0x195c runnable
- "Gang worker#0 (Parallel GC Threads)" prio=10 tid=0x0086c800 nid=0x2780 runnable
- "Gang worker#1 (Parallel GC Threads)" prio=10 tid=0x02a40c00 nid=0x25a0 runnable
- "Concurrent Mark-Sweep GC Thread" prio=10 tid=0x02ab6000 nid=0x1828 runnable
- "VM Periodic Task Thread" prio=10 tid=0x17989c00 nid=0x20b0 waiting on condition
- JNI global references: 115
是不是非常壮观,这么简单的代码在JVM内部运行时,居然需要生成这么多的线程。另外在文件的尾部,还可以看到CMS垃圾回收器的线程,是不是很有意思?这也是上面增加相关参数的原因。
这里举这个例子只是想说明通过分析Java应用导出的栈信息文件是一种很有效的窥视JVM内部实现的方法,至于能窥视到多少信息,就要看各人的实力了。本人才疏学浅,暂时还看不出什么特别的东东,目前只能看出JVM自动生成了哪些线程,至于各个线程的作用,除了垃圾回收器相关的,其它线程的功能暂时还不清楚,留待以后找到资料再说。
曾经在工作中借助top之类的命令来定位Java应用占用CPU过高的问题时,偶然发现过执行垃圾回收任务的线程占用很高CPU的情况,不过问题的根本原因和JVM倒没有什么关系。
相关推荐
【学堂在线-树洞小程序源码】是一款基于微信小程序开发的互动平台,旨在提供一个匿名分享内心秘密、情感倾诉的在线空间。该源码包含了实现这一功能所需的所有编程文件和资源,对于学习微信小程序开发以及理解社交...
2. **常量池解析**:常量池是类文件中的重要部分,存储了字符串、类引用、方法引用等信息。jclasslib可以清晰地展示常量池的内容,方便开发者分析类文件的依赖关系。 3. **字段与方法详细信息**:包括访问标志、...
在这个代理源码项目中,这个文件可能包含了程序的界面元素、图标、版本信息等,这些对于构建具有图形用户界面的代理软件至关重要。 在学习和分析这个源码时,开发者需要具备一定的编程基础,特别是对网络编程和代理...
5. **文件I/O**:为了保存游戏进度、读取配置文件或者加载游戏资源(如图像、音频),开发者会使用Java的文件I/O功能。 6. **网络编程**:如果游戏支持多人在线模式,Java的网络套接字(Socket)API可以帮助实现...
溢出植入型木马是一种利用计算机程序中的缓冲区溢出漏洞进行攻击的恶意软件。它的工作原理基于程序处理数据时的内存管理问题,通常涉及到不当的数据输入验证和内存分配。以下将详细介绍溢出植入型木马的原理及其实现...
根据提供的文件信息,我们可以归纳出以下关于“数据结构与算法”的相关知识点: ### 数据结构与算法概述 #### 讲师信息: - **讲师姓名**:刘志强 - **职称**:博士、副教授 - **所在单位**:西北工业大学软件与微...
此外,这也有助于提升我们对于Java编程语言的理解,因为BlueJ本身就是用Java编写,因此,深入其源码也是对Java技术栈的一次深入学习。 总的来说,这个压缩包为我们提供了一个宝贵的学习资源,无论是为了教学目的...
首先,我们注意到这个项目涉及到的主要技术栈包括Kafka、IntelliJ IDEA、Scala、Java以及Flink。 **一、项目运行** 1. 使用IntelliJ IDEA作为集成开发环境(IDE)打开项目,为了正确运行项目,我们需要确保已安装...
项目结构可能包括了src/main/java目录存放Java源码,src/main/resources存储资源配置,pom.xml或build.gradle文件管理依赖,以及一个README文件来解释项目的用途、如何构建和运行等信息。 为了深入理解这个项目,...
《编码:隐匿在计算机软硬件背后的语言》是作者查尔斯·佩措尔德的一部经典著作,深入浅出地揭示了计算机世界中隐藏的编码秘密。这本书是计算机科学入门者和爱好者理解计算机工作原理的重要读物,尤其适合对计算机...
这个名为"undocumented.windows.2000.rar"的压缩包文件,正是关于Windows 2000系统中未公开特性的研究资料集合,包含了一些鲜为人知的技术细节和隐藏功能。 1. **系统内核的秘密**:Windows 2000采用了NT5.x内核,...
5. 后端逻辑:后端代码负责处理前端请求,与网盘服务通信,处理业务逻辑,可能基于Node.js、Python的Flask/Django、Java的Spring Boot等技术栈。 【配置教程】: 配置教程是为了帮助开发者或使用者正确设置和运行...
6. **文件操作**:游戏可能会保存玩家进度或读取资源文件,Java的I/O流类库如`FileReader`、`FileWriter`和`BufferedReader`等将派上用场。 7. **设计模式**:游戏开发中常用的设计模式有单例模式(如游戏状态管理...
Java程序运行时,类需要被加载到JVM中才能执行。这一过程包括加载、验证、准备、解析和初始化五个阶段。类加载器在此过程中起到关键作用,它负责找到并加载类文件。 此外,JVM的性能调优也是重要一环。通过JDK提供...
通过修改注册表中的相关键值(例如TcpWindowSize),可以改善TCP/IP协议栈的效率。 **三、秘密与高级功能** 1. **隐藏文件夹快速访问** - 在资源管理器地址栏输入`%SystemRoot%`可以直接打开系统根目录;输入`%...
《数据波:Java技术在数据探索中的应用》 在当今数字化时代,数据是企业和社会运行的重要燃料。"Data-Wave"项目就是一个将原始数据转化为可探索的波浪状图形的工具,它使得复杂的数据集变得直观易懂。本文将深入...
虽然没有在“标签”中给出具体的技术细节,但从“压缩包子文件的文件名称列表”来看,我们可以推测这可能是一个开源或个人项目,名为"SecretWordGame-main"。下面我们将深入探讨这个游戏可能涉及到的IT知识点。 1. ...
WSG-MSClients是一个基于Java技术栈的微服务应用,专门设计用于处理客户端管理和身份验证的需求。在现代分布式系统中,身份验证和授权是核心组件,确保系统的安全性与用户数据的保护。WSG-MSClients通过微服务架构...
- **什么是资源**:在Webx框架中,“资源”通常指代任何可以被应用程序访问的数据或文件,包括但不限于图片、CSS样式表、JavaScript脚本等。 - **如何表示资源**:为了统一资源的表示方式,Webx定义了一套标准化的...