这是一个循环死锁还是循环等待？

Question

我正在使用JProfiler 对一个Restful Java 微服务进行仪器化, 同时用JMeter发送多个请求。我发现有很多线程被阻塞。该微服务使用Spring和SpringBoot。 当发送多个请求时，问题就出现了。

在JProfiler工具中，我可以看到：

• 我阅读了Circular Deadlock, Dining philosophers后， 我认为这是一个环形死锁。这样对吗？
• 死锁和环形死锁之间有什么区别？ 在互联网上浏览一下后，我看到另一个概念，循环等待。那么循环等待是什么？
• 如果您查看监视器历史记录和概述部分，您会看到许多被阻止的线程，还有一个线程等待其他线程完成。问题出在ReentrantLock.NonfairSync类上。 但是如果您查看线程转储，您会发现线程处于等待状态，并且在堆栈跟踪的顶部看到sun.misc.Unsafe.park。使用park和unpark方法实现了线程锁定。您知道这可能是什么吗？
• 再次出现com.fasterxml库的问题吗？jackson项目

谢谢。

- Adrian

Answer 1

阅读完“循环死锁”、“哲学家就餐问题”后，我认为存在循环死锁。这个想法正确吗？

根据现有证据无法确定。

死锁和循环死锁有什么区别？

我从未见过“循环死锁”这个术语，但在那篇文章的背景下，“循环”似乎意味着有超过两个线程被死锁。在我看来，这不是一个特别有用的区分。

在浏览互联网时，我发现了另一个概念，循环等待。循环等待怎么样？

我在维基百科死锁页面上找到了这个术语。在那种情况下，它指的是任何你有N个代理（例如线程）A1到AN，并且：

• A₁ 等待 A₂
• A₂ 等待 A₃
• ...
• A_N 等待 A₁

在依赖关系中形成一个“循环”或“环”。请注意，N 可以小至 2。（这在维基百科页面中有清晰的解释。）

使用 park 和 unpark 方法实现线程锁。你知道它是什么吗？

这就是在 JVM 中实现锁和等待的方式。

com.fasterxml.jackson 库又出问题了吗？

这是可能的。也有可能是您使用库的方式存在问题。但这只是猜测。从您提供的信息来看，没有足够的证据说明问题所在。

---

我建议你停止寻找答案。相反，戴上思考帽子，开始阅读代码和Javadocs。

如果我猜的话，可能是你有多个线程试图共享某种XML解析器对象，而该对象不是设计用于共享的。

- Stephen C