线程转储文件往往会有几百行代码（有时会有几千行）。由于其十分冗长，所以我们很难了解其中的所有信息。由 fastThread 工具生成的火焰图能够将这些信息压缩成一个紧凑的图表格式。其能帮助您快速识别热门代码路径（hot code path）。在本文中，我们将了解如何使用 fastThread 工具生成火焰图，从而有效进行调试和故障排除工作。

描述

维基百科恰当地给出了“死锁”的定义：当两个以上的运算单元，双方都在等待对方停止执行，以获取系统资源，但是没有一方提前退出时，就称为死锁。JVM 中发生死锁之后，恢复的唯一方法是重新启动 JVM。

StackOverFlowError 是最为常见的 JVM 错误之一。在本博文中，我们将了解线程栈的内部机制、触发 StackOverFlowError 的可能原因以及解决此类错误的潜在解决方案。

为了更加深入地了解 StackOverFlowError，下面就让我们来看看这一个简单程序：

描述

哲学家聚餐问题是并发编程中的经典计算机科学问题。哲学家聚餐问题将导致循环死锁问题。循环死锁是死锁问题的一种变体。发生死锁之后，恢复的唯一方法是重新启动 JVM。

描述

如果线程转储文件中的多个线程最终都调用了同一个方法，那么这可能需要引起您的关注。在存在问题的大多数情况下（比如：数据源响应迟缓、锁未释放、无限循环线程等等），会出现大量线程调用同一个方法的情况。我们需要对这个方法进行详细的分析。

描述

不同 GC 算法类型（Serial、Parallel、G1、CMS）将创建数量不同的默认垃圾回收线程。有关创建的默认线程数详情如下所述。有时，系统会根据默认配置创建过多无用的 GC 线程。我们曾经见过基于默认配置创建 128、256、512 个 GC 线程的情况。太多的 GC 线程也会影响应用程序性能。所以我们应该谨慎配置 GC 线程数量。

您应当调查抛出异常或错误的线程。因为此类线程栈追踪信息通常指明了问题的起因所在。下方是抛出 java.lang.OutOfMemoryError 的线程的栈追踪信息：

描述

处于‘RUNNABLE’（可运行）状态的线程会消耗 CPU。所以在对消耗较多 CPU 资源的线程转储文件进行分析时，您应该仔细检查处于‘RUNNABLE’状态的线程。通常，线程转储文件会有多个线程被分类为‘RUNNABLE’状态。不过在实际运行过程中，其中的有些不会运行，只是处于等待状态。此时 JVM 仍然会将其分类为‘RUNNABLE’。您需要学会如何将那些假装自己在运行的‘RUNNABLE’线程揪出来。

描述

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