blocks|key|954976|text|这取决于你所说的“死锁”到底是什么意思。例如，您可以很容易地在没有任何脉冲的监视器上执行wait()+...但我认为我不会称之为死锁。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|954977|按照你的“调用自己的方法”的思路，如果你的服务器只运行一定数量的线程，它们可能都在忙于等待来自同一服务器的响应，如果这算数的话。(最简单的例子:服务器只使用一个线程进行处理。如果您编写一个请求处理程序来调用同一服务器，它将等待被阻塞的线程完成对请求的处理，然后才能为相同的请求提供服务...)这并不是真正的“同步块”类型的死锁，但这确实是一个需要注意的危险。|954978|编辑:要将此答案应用到其他定义中，此处的竞争操作将是“完成当前请求”和“处理新请求”。每个操作都在等待另一个操作的发生。|954979|entityMap^0|18|6|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

It depends on what you mean by "deadlock" exactly. For example, you could easily <code>wait()</code> on a monitor which nothing would ever pulse... but I don't think I'd call that deadlock, as such.

Thinking along your "method that calls itself" lines, if your server only ran a certain number of threads, they could all be busy waiting from responses from the same server, if that counts. (Simplest example: the server only uses one thread for processing. If you write a request handler which calls into the same server, it will be waiting for the blocked thread to finish handling the request before it can serve the same request...) This isn't really a "synchronized block" sort of deadlock, but it's certainly a danger to be aware of.

EDIT: To apply this answer to the definition in the others, the competing actions here would be "complete the current request" and "handle the new request". Each action is waiting for the other to occur.

blocks|key|955023|text|理想情况下，线程永远不应该使用“同步锁”来创建死锁本身，除非旧版本中的某些人使用'allegedly'+noticed在JVM本身中确实存在错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|955024|entityMap|0|LINK|mutability|MUTABLE|url|http://java.itags.org/java-core-apis/31962/^0|14|J|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Ideally a thread should never create a deadlock itself using 'synchronized locks' unless there really is a bug in the JVM itself as <a href="http://java.itags.org/java-core-apis/31962/" rel="nofollow noreferrer">'allegedly' noticed</a> by some people in older versions

blocks|key|955066|text|也许面试官在想的是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|955067|Thread.currentThread().join();|code-block|syntax|javascript|955068|然而，我认为这不能算作死锁。|955069|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Maybe what the interviewer was thinking of was:

<pre><code>Thread.currentThread().join();
</code></pre>

However I would argue that it does not count as a deadlock.

blocks|key|955105|text|虽然我还没有使用过Java，但我之前曾死锁过一个单线程应用程序。IIRC:例程A锁定了一段数据以更新它。例程B也锁定了相同的数据来更新它。由于需求变化，A最终调用了B。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|955106|当然，这只是我第一次尝试运行代码时捕获的一个普通的开发错误，但它本身确实死锁了。我认为这种类型的死锁在任何支持文件系统的语言中都是可能的。|955107|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

While I haven't used Java I have deadlocked a single-thread app before. IIRC: Routine A locked a piece of data to update it. Routine B also locked the same piece of data to update it. Due to requirements changes A ended up calling B. Oops.

Of course this was just an ordinary development bug that I caught the first time I tried to run the code but it did deadlock itself. I would think deadlocks of this type would be possible in any language that supports a filesystem.

blocks|key|1169384|text|从读锁升级到写锁(在持有读锁的同时尝试获取写锁)将导致线程完全阻塞。这是一个死锁吗？你来当法官吧。但这是使用单个线程创建效果的最简单方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1169385|http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html|offset|length|1169386|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|2R|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

Upgrading from a read lock to a write lock (trying to acquire a write lock while holding a read lock) will result in the thread getting completely blocked. Is that a deadlock? You be the judge... But that's the easiest way to create the effect with a single thread.

<a href="http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html" rel="noreferrer">http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html</a>

blocks|key|1169423|text|以下是线程自身死锁的一种方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1169424|public+class+DeadlockMe
{
++++public+static+void+main(String[]+args)
++++{
++++++++DeadlockThing+foo+=+new+DeadlockThing();
++++++++synchronized(foo)
++++++++{
++++++++++++try
++++++++++++{
++++++++++++++++foo.wait();
++++++++++++}
++++++++++++catch+(InterruptedException+e)
++++++++++++{
++++++++++++++++e.printStackTrace();
++++++++++++}
++++++++}
++++}
}|code-block|syntax|javascript|1169425|线程创建一个类的实例，并等待它。因为线程创建了一个具有局部作用域的对象，所以任何其他线程都无法通知该对象唤醒该线程。|1169426|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Here's a way for a thread to deadlock itself.

<pre><code>public class DeadlockMe
{
 public static void main(String[] args)
 {
 DeadlockThing foo = new DeadlockThing();
 synchronized(foo)
 {
 try
 {
 foo.wait();
 }
 catch (InterruptedException e)
 {
 e.printStackTrace();
 }
 }
 }
}
</code></pre>

The thread creates an instance of a class - any class and waits on it. Because the thread created an object with local scope, there's no possible way for any other thread to notify the object to wake up the thread.

blocks|key|955252|text|您可以编写一个线程，该线程可以接收来自其他线程的消息，通知它终止。您可以在线程中编写代码来监视其他线程，并向它们发送终止消息并等待响应。线程会发现自己在列表中，向自己发送一条消息以终止，并等待自己终止。如果它不是以一种优先于等待状态的方式编写的……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|955253|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You write a thread which can receive messages from other threads telling it to, for example, terminate. You write code in the thread to monitor other threads and send them terminate messages and wait for a response. The thread would find itself in the list, send itself a message to terminate and wait for itself to terminate. If it wasn't written in a way which prioritised incoming messages over the wait state ...

blocks|key|1169498|text|如果您扩展术语死锁的定义:单个线程可能会发现自己被先前获得的不可重入锁阻塞。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1169499|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you stretch the definition of the term deadlock: a single thread can find itself blocked on a non-reentrant lock that it took earlier.

blocks|key|1169536|text|当线程进入synchronized块时，它会检查当前线程是否为锁的所有者，如果是，则线程不等待就继续执行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1169537|所以我认为这是不可能的。|1169538|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

When a thread enters the synchronized block, it checks if the current thread is the owner of the lock, and if it is, the the thread just proceeds without waiting. 

So I don't think it is possible.

blocks|key|955364|text|JVM只跟踪具有监视器的本地线程，如果调用类在自身内部进行外部回调，则传入调用会导致原始线程自身死锁。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|955365|您应该能够运行以下代码来说明这一想法|955366|import+java.rmi.*;
import+java.rmi.registry.LocateRegistry;
import+java.rmi.registry.Registry;
import+java.rmi.server.*;

public+class+DeadlockThreadExample+{

++++public+static+interface+DeadlockClass+extends+Remote+{
++++++++public+void+execute()+throws+RemoteException;
++++}

++++public+static+class+DeadlockClassImpl+extends+UnicastRemoteObject+implements+DeadlockClass+{
++++++++private+Object+lock+=+new+Object();

++++++++public+DeadlockClassImpl()+throws+RemoteException+{
++++++++++++super();
++++++++}

++++++++public+void+execute()+throws+RemoteException+{
++++++++++++try+{
++++++++++++++++System.out.println("execute()::start");

++++++++++++++++synchronized+(lock)+{
++++++++++++++++++++System.out.println("execute()::Entered+Lock");
++++++++++++++++++++DeadlockClass+deadlockClass+=+(DeadlockClass)+Naming.lookup("rmi://localhost/DeadlockClass");
++++++++++++++++++++deadlockClass.execute();
++++++++++++++++}
++++++++++++++++System.out.println("execute()::Exited+Lock");
++++++++++++}+catch+(NotBoundException+e)+{
++++++++++++++++System.out.println(e.getMessage());
++++++++++++}+catch+(java.net.MalformedURLException+e)+{
++++++++++++++++System.out.println(e.getMessage());
++++++++++++}
++++++++++++System.out.println("execute()::end");
++++++++}
++++}

++++public+static+void+main(String[]+args)+throws+Exception+{
++++++++LocateRegistry.createRegistry(Registry.REGISTRY_PORT);
++++++++DeadlockClassImpl+deadlockClassImpl+=+new+DeadlockClassImpl();
++++++++Naming.rebind("DeadlockClass",+deadlockClassImpl);
++++++++DeadlockClass+deadlockClass+=+(DeadlockClass)+Naming.lookup("rmi://localhost/DeadlockClass");
++++++++deadlockClass.execute();
++++++++System.exit(0);
++++}
}|code-block|syntax|javascript|955367|程序的输出如下所示|955368|execute()::start
execute()::Entered+Lock
execute()::start|955369|此外，线程转储还显示以下内容|955370|"main"+prio=6+tid=0x00037fb8+nid=0xb80+runnable+[0x0007f000..0x0007fc3c]
++++at+java.net.SocketInputStream.socketRead0(Native+Method)
++++at+java.net.SocketInputStream.read(SocketInputStream.java:129)
++++at+java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
++++at+java.io.BufferedInputStream.read(BufferedInputStream.java:235)
++++-+locked+<0x02fdc568>+(a+java.io.BufferedInputStream)
++++at+java.io.DataInputStream.readByte(DataInputStream.java:241)


"RMI+TCP+Connection(4)-172.17.23.165"+daemon+prio=6+tid=0x0ad83d30+nid=0x1590+waiting+for+monitor+entry+[0x0b3cf000..0x0b3cfce8]
++++at+DeadlockThreadExample$DeadlockClassImpl.execute(DeadlockThreadExample.java:24)
++++-+waiting+to+lock+<0x0300a848>+(a+java.lang.Object)
++++at+sun.reflect.NativeMethodAccessorImpl.invoke0(Native+Method)


"RMI+TCP+Connection(2)-172.17.23.165"+daemon+prio=6+tid=0x0ad74008+nid=0x15f0+runnable+[0x0b24f000..0x0b24fbe8]+
++++at+java.net.SocketInputStream.socketRead0(Native+Method)
++++at+java.net.SocketInputStream.read(SocketInputStream.java:129)
++++at+java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
++++at+java.io.BufferedInputStream.read(BufferedInputStream.java:235)
++++-+locked+<0x02ffb6d8>+(a+java.io.BufferedInputStream)
++++at+java.io.DataInputStream.readByte(DataInputStream.java:241)|955371|，这表明线程确实已经设法锁定了自己。|955372|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

The JVM only keeps track of the local thread that has the monitor, if the calling class makes an external call back in on itself the incoming call causes the original thread to deadlock itself.

You should be able to run this code to illustrate the idea

<pre><code>import java.rmi.*;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.*;

public class DeadlockThreadExample {

 public static interface DeadlockClass extends Remote {
 public void execute() throws RemoteException;
 }

 public static class DeadlockClassImpl extends UnicastRemoteObject implements DeadlockClass {
 private Object lock = new Object();

 public DeadlockClassImpl() throws RemoteException {
 super();
 }

 public void execute() throws RemoteException {
 try {
 System.out.println("execute()::start");

 synchronized (lock) {
 System.out.println("execute()::Entered Lock");
 DeadlockClass deadlockClass = (DeadlockClass) Naming.lookup("rmi://localhost/DeadlockClass");
 deadlockClass.execute();
 }
 System.out.println("execute()::Exited Lock");
 } catch (NotBoundException e) {
 System.out.println(e.getMessage());
 } catch (java.net.MalformedURLException e) {
 System.out.println(e.getMessage());
 }
 System.out.println("execute()::end");
 }
 }

 public static void main(String[] args) throws Exception {
 LocateRegistry.createRegistry(Registry.REGISTRY_PORT);
 DeadlockClassImpl deadlockClassImpl = new DeadlockClassImpl();
 Naming.rebind("DeadlockClass", deadlockClassImpl);
 DeadlockClass deadlockClass = (DeadlockClass) Naming.lookup("rmi://localhost/DeadlockClass");
 deadlockClass.execute();
 System.exit(0);
 }
}
</code></pre>

The output from the program looks like

<pre><code>execute()::start
execute()::Entered Lock
execute()::start
</code></pre>

Additionally the thread also dump shows the following

<pre><code>"main" prio=6 tid=0x00037fb8 nid=0xb80 runnable [0x0007f000..0x0007fc3c]
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:129)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
 - locked &lt;0x02fdc568&gt; (a java.io.BufferedInputStream)
 at java.io.DataInputStream.readByte(DataInputStream.java:241)


"RMI TCP Connection(4)-172.17.23.165" daemon prio=6 tid=0x0ad83d30 nid=0x1590 waiting for monitor entry [0x0b3cf000..0x0b3cfce8]
 at DeadlockThreadExample$DeadlockClassImpl.execute(DeadlockThreadExample.java:24)
 - waiting to lock &lt;0x0300a848&gt; (a java.lang.Object)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


"RMI TCP Connection(2)-172.17.23.165" daemon prio=6 tid=0x0ad74008 nid=0x15f0 runnable [0x0b24f000..0x0b24fbe8] 
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.read(SocketInputStream.java:129)
 at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
 at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
 - locked &lt;0x02ffb6d8&gt; (a java.io.BufferedInputStream)
 at java.io.DataInputStream.readByte(DataInputStream.java:241)
</code></pre>

which indicates that the thread has indeed managed to lock itself

blocks|key|955401|text|使用ReentrantReadWriteLock时，您可能会陷入单线程死锁。写锁可以获得读锁，但反之亦然。下面的代码将会无限期地阻塞。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|955402|++++ReentrantReadWriteLock+lock+=+new+ReentrantReadWriteLock();
++++lock.readLock().lock();
++++lock.writeLock().lock();|code-block|syntax|javascript|955403|entityMap|0|LINK|mutability|MUTABLE|url|http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html^0|2|M|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

You can get yourself into a single thread Deadlock with <a href="http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html" rel="nofollow">ReentrantReadWriteLock</a>. Write locks can acquire read locks but not the other way around. The following will block indefinitely.

<pre><code> ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
 lock.readLock().lock();
 lock.writeLock().lock();
</code></pre>

blocks|key|1169741|text|尽管这里的评论是关于如果至少两个线程/操作竞争相同的资源就会发生“死锁”的书生气……我认为这个问题的精神是讨论重入锁的需要--特别是在“递归”锁的上下文中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1169742|下面是一个用Python语言编写的例子(我确信这个概念在Java语言中保持不变)：如果你把锁改为RLock+(即把可重入锁改为锁，线程就会挂起)|1169743|import+threading

"""
Change+RLock+to+Lock+to+make+it+"hang"
"""
lock+=+threading.Condition(threading.RLock())


def+print_list(list):
++++lock.acquire()
++++if+not+list:
++++++++lock.release()
++++++++return
++++print(list[0])
++++print_list(list[1:])
++++lock.release()


print_list([1,+2,+3,+4,+5])|code-block|syntax|javascript|1169744|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Although the comments here are being pedantic about "deadlock" happening if at least two threads/actions are competing for the same resource...I think the spirit of this question was to discuss a need for Reentrant lock - especially in context of "recursive" locking

Here's an example in python (I am certain the concept stays the same in Java):
If you change the RLock to Lock (i.e. reentrant lock to lock, the thread will hang)

<pre><code>import threading

"""
Change RLock to Lock to make it "hang"
"""
lock = threading.Condition(threading.RLock())


def print_list(list):
 lock.acquire()
 if not list:
 lock.release()
 return
 print(list[0])
 print_list(list[1:])
 lock.release()


print_list([1, 2, 3, 4, 5])
</code></pre>

Is it technically possible for a thread in Java to deadlock itself?

I was asked this at an interview a while back and responded that it wasn't possible but the interviewer told me that it is. Unfortunately I wasn't able to get his method on how to achieve this deadlock.

This got me thinking and the only situation that I can think of is where you can have this happen is where you have an RMI server process which contained a method that calls itself. The line of code that calls the method is placed in a synchronized block.

Is that even possible or was the interviewer incorrect?

The source code I was thinking about was along these lines (where testDeadlock is running in an RMI server process)

<pre><code>public boolean testDeadlock () throws RemoteException {
 synchronized (this) {
 //Call testDeadlock via RMI loopback 
 }
}
</code></pre>

Is it possible for a thread to Deadlock itself?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

Java中的线程在技术上有可能死锁自己吗？在不久前的一次面试中，我被问到这个问题，我回答说这是不可能的，但面试官告诉我这是可能的。不幸的是，我不能得到他关于如何实现这个死锁的方法。这让我开始思考，我能想到的唯一情况是，你有一个RMI服务器进程，其中包含一个调用自身的方法。调用该方法的代码行被放在synchronized...

问线程有可能死锁自己吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问线程有可能死锁自己吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问线程有可能死锁自己吗？
EN