我正在从Galvin读到死锁的概念，并且我怀疑单个进程/线程是否会陷入死锁...？Coz的定义（或者实际上是Galvin的整个Deadlock一章）似乎并没有在谈论如果系统中只有一个进程/线程。（请告诉我是否有任何遗漏……阅读本书时……如果是的话，诚挚的道歉……为我先前的发言，但我在任何地方的章节中都找不到。）
[Galvin Book在描述死锁情况时每个使用“ Other”进程的地方...所以我觉得我的问题的答案是“否”，单个进程/线程永远不会陷入僵局。（我也是：我觉得在某些情况下一个进程可能导致无限期的等待，我可以称之为死锁吗？）]
要知道为什么我将死锁和无限期等待合并到一张图片中。（还请告诉我，假设无限期等待与死锁并不相同，我是否正确……我可能是错的。考虑一个场景：有一个线程（t）和一个锁（l）。锁定性质不允许进入。（意味着线程持有锁l时，它无法在释放它之前再次获取它...我只能在Internet上找到它作为定义。）（另一个条件：如果线程无法获取锁，则它将阻塞自身，直到它可用为止。是的，这很明显，但这是造成混乱的原因。请阅读下面的plz以获得见识。现在声称t获得了一个锁l，然后执行它，同时又需要相同的锁。（可能是因为它必须执行一些递归函数调用……就像在BFS / DFS中一样……或者是类似的东西..）因此很明显，它必须在获取该锁之前离开该锁...但是由于进程无法再次获取相同的锁，因此它必须等待或只是被阻塞直到它变得可用...现在重要的一点是...它将被阻塞，直到它..自身释放锁..现在我的问题是这种情况是否会导致死锁...（是的，它可以再次释放..然后重新获取...但是我的问题与这种情况无关。）所以我的问题是这种情况是否会导致死锁...（就像线程在等待自己...）->就像在最坏的情况下一样。（此外，每当进程/线程进入阻塞状态/等待状态时，它都会保持锁/资源。.plz也在这里阐明...）（我希望我在说的是明确的...如果不发表评论，并告诉我会尽力澄清...是的，这一点在我要提出疑问的地方非常微妙）]
该情况实际上是一个考试问题。其答案是：是的，具有单个锁的单个线程会导致死锁->我感到这与死锁定义冲突。我知道我提出了很多疑问，但主要问题是相同的。
以下是我所怀疑的重点摘要：
单个进程/处于死锁状态？
-不确定等待vs死锁
-进程/线程在进入阻塞/等待状态时是否有必要释放锁？
（（首先，如果您能做到这一点，谢谢。因为这真是一个很长的疑问。我这样做是为了明确我的观点...如果不发表评论，我会再说一遍。 ..）
单个进程/处于死锁状态？
是的，正如您提到的，如果线程中的函数持有锁并递归调用自身，则可能导致死锁。如果锁已实现为不阻塞，那么当已经持有的线程请求该锁时，我们当然不会出现死锁。
无限等待与死锁
不，这些不是同一个人。如果所有线程都无法取得进展，则会发生死锁。如果一个线程（持有锁）能够在无限期地阻塞/延迟其他线程的同时取得进展，那不是死锁。另一个有趣的概念是Livelocks-线程没有进步，但似乎是“活跃的” /活动的。
进程/线程是否有必要释放锁..何时进入阻塞/等待状态？
例如，假设一个线程持有一个锁以保护内存页面不被其他线程访问，然后开始从磁盘读取该内存页面。该I / O很可能会挂起线程，直到从磁盘完成传输为止。这是保持锁定和暂停的合法使用。在许多情况下，线程在持有锁的同时可能会阻塞。
关注您的帖子并不容易，但让我举一些例子
如果线程正在请求已经拥有的应用程序锁，那么好的锁管理器应该抛出异常。您需要在应用程序中包含记录您拥有锁的代码，以便可以在异常或正常终止时释放它。
锁可以是您说“获取唯一锁”的锁对象。
两个线程可以使用ECB / Mutex上的等待和发送进行通信。因此task1发布了互斥锁1，然后等待着互斥锁2
任务2正在等待互斥锁1，醒来，做了一些工作，发布互斥锁1，正在等待mutext2
任务1唤醒
如果您没有在运行任务2，则仅在任务1上执行任务1，然后等待互斥量永远不会发布。这可以被视为只有一个线程的死锁。
[您也可以在任务1具有锁1并正在等待锁2，任务2具有锁2并正在等待锁1的情况下得到“致命的拥抱”。
某些系统在获得lock2之前需要锁定1。
所以您的代码是
get lock1 get lock2 release lock1 ... release lock2这避免了致命的拥抱。
如果您要锁定数据库中的行，则可能会发生以下情况：更新需要对数据，页面，行等进行多次锁定，并在此处发生死锁-因此一项任务需要许多锁定。
编写死锁的过程很容易。尝试两次获取信号量...但是，这样的代码每次都会死锁，因此这并不是真正的问题，因为这样的错误也无法逃脱即使是最不专心的测试人员的注意。