描述

线程-A 可能获得了锁-1，但却永远不会释放它。线程-B 可能已经获得了锁-2，并且在等待获得锁-1。线程-C 可能正在等待获取锁-2。这种线程之间的可传递阻塞会使整个应用程序进入无响应状态。看看下方的真实例子吧。

• 非守护线程也被称为用户线程。

时至今日，我们依然需要以繁琐而单调的手动方式来分析线程转储文件：首先您需要联系 DevOps 团队，让他们把线程转储文件发过来，然后在收到文件后您还要将其上传至分析工具中，最后再用上自己的智慧对其进行分析。目前暂时还没有对线程转储文件进行主动分析的程序化方法。所以为了消除这样的麻烦，fastthread.io 打造了用于分析线程转储文件的 RESTful API。只需一行 CURL 命令，您就可以即时进行线程转储文件的分析工作。

如需对生产问题进行故障排除，您可能必须分析定期捕获的多个线程转储文件快照。每个线程快照中往往都会包含数百个线程，有时甚至会有数千线程。线程转储文件中的每个线程都可能会处于以下六种状态之一：

调用栈树提供了 3 大绝佳好处：

1. 一个简化的视图
2. 性能优化
3. 准确的冒烟测试
   下面我们就来详细聊聊吧。

描述

线程暂时阻塞并不是什么问题。不过，如果其长时间阻塞，这就是值得注意的问题了——因为其表明程序中存在一些问题。通常阻塞的线程会导致程序无响应。
在 10 秒间隔内捕获的 3 个线程转储文件中，如果线程都在相同的方法上并处于‘BLOCKED’状态，就说明可能存在问题。研究此类阻塞线程的栈追踪信息将说明其阻塞原因。可能的理由有：死锁、循环死锁、另一线程、获取了锁定且未将其释放、外部 SOR 可能无响应等等…

Java.net.SocketInputStream.socketRead0() API 的作用是什么？为什么其会频繁出现在多个线程转储文件中？为什么 fastThread.io 等线程转储文件分析工具会对其进行上报？这是否是我需要关心的信息？该问题的潜在解决方案是什么？下面就让我们来寻找一下这些问题的答案吧，

Here is a beautiful 1-page document on OutOfMemoryError.

OutOfMemoryError is a runtime error in Java that occurs when the Java Virtual Machine (JVM) is unable to allocate an object due to insufficient space in the Java heap. The Java Garbage Collector (GC) cannot free up the space required for a new object, which causes the error.

我们的垃圾回收日志分析 REST API 提供了作用强大的微指标。借助这些微指标，您可对程序的可用性和性能特征进行预测。