打破冷漠僵局文章_研究僵局–第3部分

打破冷漠僵局文章

在本系列的前两个博客（ 第1部分和第2部分）中 ，我演示了如何创建一段会死锁的错误代码，然后使用该代码演示进行线程转储的三种方式。 在此博客中，我将分析线程转储以找出错误的原因。

下面的讨论同时涉及本系列第1部分中的Account和DeadlockDemo类，其中包含完整的代码清单。

我需要做的第一件事是从DeadlockDemo应用程序中进行线程转储，就像他们过去在Blue Peter上所说的那样：“这是我之前准备的”。

2012-10-16 13:37:03 Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.10-b01-428 mixed mode):"DestroyJavaVM" prio=5 tid=7f9712001000 nid=0x110247000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE"Thread-21" prio=5 tid=7f9712944000 nid=0x118d76000 waiting for monitor entry [118d75000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366f58> (a threads.deadlock.Account) - locked <7f3366ee0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-20" prio=5 tid=7f971216c000 nid=0x118c73000 waiting for monitor entry [118c72000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e98> (a threads.deadlock.Account) - locked <7f3366f58> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-19" prio=5 tid=7f9712943800 nid=0x118b70000 waiting for monitor entry [118b6f000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366f40> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-18" prio=5 tid=7f9712942800 nid=0x118a6d000 waiting for monitor entry [118a6c000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366f40> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-17" prio=5 tid=7f9712942000 nid=0x11896a000 waiting for monitor entry [118969000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366ec8> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-16" prio=5 tid=7f9712941000 nid=0x118867000 waiting for monitor entry [118866000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366ec8> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-15" prio=5 tid=7f9712940800 nid=0x118764000 waiting for monitor entry [118763000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366ef8> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-14" prio=5 tid=7f971293f800 nid=0x118661000 waiting for monitor entry [118660000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366f28> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-13" prio=5 tid=7f97129ae000 nid=0x11855e000 waiting for monitor entry [11855d000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-12" prio=5 tid=7f97129ad000 nid=0x11845b000 waiting for monitor entry [11845a000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366f40> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-11" prio=5 tid=7f97129ac800 nid=0x118358000 waiting for monitor entry [118357000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366f58> (a threads.deadlock.Account) - locked <7f3366eb0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-10" prio=5 tid=7f97129ab800 nid=0x118255000 waiting for monitor entry [118254000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-9" prio=5 tid=7f97129ab000 nid=0x118152000 waiting for monitor entry [118151000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e98> (a threads.deadlock.Account) - locked <7f3366ec8> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-8" prio=5 tid=7f97129aa000 nid=0x11804f000 waiting for monitor entry [11804e000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) - locked <7f3366f28> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-7" prio=5 tid=7f97129a9800 nid=0x117f4c000 waiting for monitor entry [117f4b000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) - locked <7f3366e80> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-6" prio=5 tid=7f97129a8800 nid=0x117e49000 waiting for monitor entry [117e48000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366e80> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-5" prio=5 tid=7f97128a1800 nid=0x117d46000 waiting for monitor entry [117d45000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:81) - waiting to lock <7f3366f28> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-4" prio=5 tid=7f97121af800 nid=0x117c43000 waiting for monitor entry [117c42000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e80> (a threads.deadlock.Account) - locked <7f3366e98> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-3" prio=5 tid=7f97121ae800 nid=0x117b40000 waiting for monitor entry [117b3f000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e80> (a threads.deadlock.Account) - locked <7f3366ef8> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"Thread-2" prio=5 tid=7f971224a000 nid=0x117a3d000 waiting for monitor entry [117a3c000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) - locked <7f3366f40> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)"RMI TCP Accept-0" daemon prio=5 tid=7f97128fd800 nid=0x117837000 runnable [117836000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408) - locked <7f32ee740> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:462) at java.net.ServerSocket.accept(ServerSocket.java:430) at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:34) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341) at java.lang.Thread.run(Thread.java:680)"Poller SunPKCS11-Darwin" daemon prio=1 tid=7f97128fd000 nid=0x117734000 waiting on condition [117733000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692) at java.lang.Thread.run(Thread.java:680)"Low Memory Detector" daemon prio=5 tid=7f971209e000 nid=0x1173ec000 runnable [00000000] java.lang.Thread.State: RUNNABLE"C2 CompilerThread1" daemon prio=9 tid=7f971209d000 nid=0x1172e9000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE"C2 CompilerThread0" daemon prio=9 tid=7f971209c800 nid=0x1171e6000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE"Signal Dispatcher" daemon prio=9 tid=7f971209b800 nid=0x1170e3000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE"Surrogate Locker Thread (Concurrent GC)" daemon prio=5 tid=7f971209a800 nid=0x116fe0000 waiting on condition [00000000] java.lang.Thread.State: RUNNABLE"Finalizer" daemon prio=8 tid=7f971209a000 nid=0x116d1c000 in Object.wait() [116d1b000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f3001300> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <7f3001300> (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)"Reference Handler" daemon prio=10 tid=7f9712099000 nid=0x116c19000 in Object.wait() [116c18000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <7f30011d8> (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 <7f30011d8> (a java.lang.ref.Reference$Lock)"VM Thread" prio=9 tid=7f9712096800 nid=0x116b16000 runnable"Gang worker#0 (Parallel GC Threads)" prio=9 tid=7f9712002800 nid=0x1135c7000 runnable"Gang worker#1 (Parallel GC Threads)" prio=9 tid=7f9712003000 nid=0x1136ca000 runnable"Concurrent Mark-Sweep GC Thread" prio=9 tid=7f971204d800 nid=0x116790000 runnable "VM Periodic Task Thread" prio=10 tid=7f97122d4000 nid=0x11793a000 waiting on condition"Exception Catcher Thread" prio=10 tid=7f9712001800 nid=0x1103ef000 runnable JNI global references: 1037Found one Java-level deadlock: ============================= "Thread-21": waiting to lock monitor 7f97118bd560 (object 7f3366f58, a threads.deadlock.Account), which is held by "Thread-20" "Thread-20": waiting to lock monitor 7f97118bc108 (object 7f3366e98, a threads.deadlock.Account), which is held by "Thread-4" "Thread-4": waiting to lock monitor 7f9711834360 (object 7f3366e80, a threads.deadlock.Account), which is held by "Thread-7" "Thread-7": waiting to lock monitor 7f97118b9708 (object 7f3366eb0, a threads.deadlock.Account), which is held by "Thread-11" "Thread-11": waiting to lock monitor 7f97118bd560 (object 7f3366f58, a threads.deadlock.Account), which is held by "Thread-20"Java stack information for the threads listed above: =================================================== "Thread-21": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366f58> (a threads.deadlock.Account) - locked <7f3366ee0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-20": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e98> (a threads.deadlock.Account) - locked <7f3366f58> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-4": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e80> (a threads.deadlock.Account) - locked <7f3366e98> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-7": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) - locked <7f3366e80> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-11": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366f58> (a threads.deadlock.Account) - locked <7f3366eb0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)Found 1 deadlock.Heap par new generation total 19136K, used 11590K [7f3000000, 7f44c0000, 7f44c0000) eden space 17024K, 68% used [7f3000000, 7f3b51ac0, 7f40a0000) from space 2112K, 0% used [7f40a0000, 7f40a0000, 7f42b0000) to space 2112K, 0% used [7f42b0000, 7f42b0000, 7f44c0000) concurrent mark-sweep generation total 63872K, used 0K [7f44c0000, 7f8320000, 7fae00000) concurrent-mark-sweep perm gen total 21248K, used 8268K [7fae00000, 7fc2c0000, 800000000)

快速浏览，您可以看到此线程转储分为四个部分。 这些是：

• 所有应用程序线程的完整列表
• 死锁线程列表
• 一小堆死锁线程
• 应用程序的堆摘要

线程列表

上面第一点中的线程列表是所有应用程序线程及其当前状态的列表。 从中您可以看到一个应用程序由一堆线程组成，您可以将它们大致分为两部分。 首先，有后台线程。 这些是每个应用程序所拥有的，而这些作为我们作为应用程序程序员通常不需要担心的肮脏工作。 这些具有以下名称：“ DestroyJavaVM ”， Low Memory Detector, Finalizer, Exception Catcher Thread and Concurrent Mark-Sweep GC Thread DestroyJavaVM Low Memory Detector, Finalizer, Exception Catcher Thread and Concurrent Mark-Sweep GC Thread 。 其次，您或我可能会在我们的代码中创建一些线程。 这些名称通常包含由单词Thread和数字组成的名称。 例如： Thread-3, Thread-6 and Thread-20.

"Thread-20" prio=5 tid=7f971216c000 nid=0x118c73000 waiting for monitor entry [118c72000] java.lang.Thread.State: BLOCKED (on object monitor) at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:82) - waiting to lock <7f3366e98> (a threads.deadlock.Account) - locked <7f3366f58> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:58)

详细查看Thread-20上提供的信息，您会发现它可以分为几部分。 这些是：

<td>线程20 <td>如上所述的线程名称。<tr> <td> prio = 5 <td>线程的优先级。 从1到10的数字，其中1是最低优先级，10是最高优先级。 <tr> <tr> <td> tid = 7f971216c000 <td>线程ID。 Thread.getId（）调用返回的唯一数字。 <tr> <td> nid = 0x118c73000 <td>本机线程ID。 这映射到平台相关的线程ID。 <tr> <td>等待监视器输入[118c72000]

java.lang.Thread.State：阻塞（在对象监视器上）<td>这是线程的状态； 在这种情况下，它已被阻止。 还包括堆栈跟踪概述，其中概述了阻塞线程的位置。

请注意，线程也可以标记为守护程序。 例如：
“ RMI TCP Accept-0”守护程序prio = 5 tid = 7f97128fd800 nid = 0x117837000可运行[117836000] java.lang.Thread.State：可运行
守护程序线程是后台任务线程，例如上面列出的RMI TCP Accept-0线程。 守护程序线程是不会阻止JVM退出的线程。 仅保留守护程序线程时，JVM将退出或关闭。

但是，线程列表并不能真正帮助您找到死锁的原因，因此请快速前进……

死锁线程列表

线程转储的此部分包含死锁中涉及的所有线程的列表。

Found one Java-level deadlock: ============================= "Thread-21": waiting to lock monitor 7f97118bd560 (object 7f3366f58, a threads.deadlock.Account), which is held by "Thread-20" "Thread-20": waiting to lock monitor 7f97118bc108 (object 7f3366e98, a threads.deadlock.Account), which is held by "Thread-4" "Thread-4": waiting to lock monitor 7f9711834360 (object 7f3366e80, a threads.deadlock.Account), which is held by "Thread-7" "Thread-7": waiting to lock monitor 7f97118b9708 (object 7f3366eb0, a threads.deadlock.Account), which is held by "Thread-11" "Thread-11": waiting to lock monitor 7f97118bd560 (object 7f3366f58, a threads.deadlock.Account), which is held by "Thread-20"

从上面的片段中，您可以看到有五个线程在实例threads.deadlock.Account类上全部阻塞

除去监视器ID和帐户实例，您可以看到“线程21”正在等待“线程20”，这正在等待“线程4”，而后者又在等待“线程7”。 “ Thread-7”正在等待“ Thread-11”，这正在等待“ Thread-20”：死锁循环，如下图所示：

死锁堆栈痕迹

难题的最后一部分是死锁线程堆栈跟踪的列表，如下所示：

Java stack information for the threads listed above: =================================================== "Thread-21": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366f58> (a threads.deadlock.Account) - locked <7f3366ee0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-20": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e98> (a threads.deadlock.Account) - locked <7f3366f58> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-4": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366e80> (a threads.deadlock.Account) - locked <7f3366e98> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-7": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366eb0> (a threads.deadlock.Account) - locked <7f3366e80> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-11": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f3366f58> (a threads.deadlock.Account) - locked <7f3366eb0> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)

从上一节中，我们知道Thread-20正在通过a回路径等待Thread-11而Thread-11正在等待Thread-20 。 这是我们的僵局。

下一步是使用上面的线程堆栈跟踪将此死锁与代码行联系起来，我在下图中对此进行了简化。

在上图中，为了清楚起见，我从对象ID中删除了7f3366前缀。 因此，对象7f3366f58现在是f58 。 从该图可以看到，对象f58在第59行被Thread-20锁定，并且正在等待第86行在对象e98上的锁定。沿着向下的箭头，您可以看到Thread-7在等待锁定。 eb0上线86，而这又是通过锁定Thread-11在线路59 Thread-11正在等待锁f58上线86，其，循环备份，对线58通过锁定Thread-20 。

那么，这些代码行在哪里？ 下面显示了第59行：

…这是第86行：

有时每个人都会感到惊讶，上面的堆栈轨迹使我感到惊讶。 我期望锁位于85和86行。 但是，它们分别在59和86上。由于第59行不包含synced关键字，因此我猜测编译器对transfer（…）方法的第一个synced关键字进行了一些优化。

由此得出的结论是，从列表中随机选择两个Account对象的代码将它们以错误的顺序锁定在第59行和第86行。那么，解决方法是什么？ 下次更多。 但是，还有最后一点需要注意，即每次在程序上生成线程转储时，死锁的组成可能都不相同。 再次运行DeadlockDemo程序并使用kill -3 PID来获取另一个线程转储时，我获得了以下结果：

Found one Java-level deadlock: ============================= "Thread-20": waiting to lock monitor 7fdc7c802508 (object 7f311a530, a threads.deadlock.Account), which is held by "Thread-3" "Thread-3": waiting to lock monitor 7fdc7a83d008 (object 7f311a518, a threads.deadlock.Account), which is held by "Thread-11" "Thread-11": waiting to lock monitor 7fdc7c802508 (object 7f311a530, a threads.deadlock.Account), which is held by "Thread-3"Java stack information for the threads listed above: =================================================== "Thread-20": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:86) - waiting to lock <7f311a530> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-3": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:87) - waiting to lock <7f311a518> (a threads.deadlock.Account) - locked <7f311a530> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59) "Thread-11": at threads.deadlock.DeadlockDemo$BadTransferOperation.transfer(DeadlockDemo.java:87) - waiting to lock <7f311a530> (a threads.deadlock.Account) - locked <7f311a518> (a threads.deadlock.Account) at threads.deadlock.DeadlockDemo$BadTransferOperation.run(DeadlockDemo.java:59)Found 1 deadlock.

在此线程转储中，死锁中涉及的线程数量较少，但是如果您对其进行分析，则可以得出与我的第一个示例相同的结论。

下次：修改代码…

有关更多信息，请参阅本系列中的其他博客。

该系列以及其他博客的所有源代码都可以在Github上找到，网址为git：//github.com/roghughe/captaindebug.git

参考： 调查死锁-第3部分： Captain Debug博客博客中来自我们JCG合作伙伴 Roger Hughes 的线程转储分析 。

翻译自: https://www.javacodegeeks.com/2012/11/investigating-deadlocks-part-3.html

打破冷漠僵局文章

总结

以上是生活随笔为你收集整理的打破冷漠僵局文章_研究僵局–第3部分的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。