这是该系列文章的第三篇，我们将分析2014年10月进行的调查的结果。如果您尚未这样做，我建议从该系列的前两篇文章开始： 问题严重性分析和监视域分析 。 这篇文章着重于故障排除/根本原因检测。

本调查部分的背景：意识到性能问题并了解其对最终用户的影响足以采取行动后，请执行以下过程：

• 重现问题。 您很少从足够的信息开始，因此第一步通常涉及重现问题以开始收集更多证据。
• 收集证据。 要了解实际情况，您需要收集更多信息（例如，通过日志记录，线程/堆转储等）来了解情况。
• 解释证据。 在收集了证据之后，对其进行任何理解可能仍然很棘手。 查看您的第一个堆转储并尝试找出导致内存泄漏的实际原因是一个很好的示例，其中解释部分可能会花费很多时间。
• 将证据与实际根本原因联系起来。 在最终弄清证据之后，您可以开始查找导致实际问题的实际代码或配置项的链接。

上述过程通常是完全非正式的，但是在大多数情况下还是存在的。 为了了解情况，我们通过询问受访者以下问题来分析当前状况：

• 您能够重现该问题吗？
• 您如何收集证据以找到根本原因？
• 您使用了哪些工具来收集证据？
• 真正的根本原因是什么？

重现问题。

因此，正如我们所见，为了获得证据，您首先需要重现问题（最好随意）。 当我们问这个问题时，受访者说：

我们可以看到9％的受访者甚至不需要重现该问题，这可能是因为已经有足够的证据。 但是，有27％的听众无法重现该问题 ，这为解决问题的道路设置了一个非常讨厌的障碍–无法重现该问题，大多数故障排除工具会让您空手而归。 在这种情况下，整个过程常常成为痛苦的反复试验的噩梦。

用于收集证据的工具和技术

当您能够重现问题时，下一步的目标是收集更多证据。 为此，存在各种各样的工具和技术。 在我们的调查中，我们要求受访者列出其武器库。 284位受访者列出了以下1,101个选项：

最常见的证据来源显然是申请日志-71％的受访者确认这是使用的来源之一。 这不会让任何人感到惊讶，尤其是当您回想起大多数受访者具有工程背景时。 毕竟，应用程序日志是由开发人员自己编写的，因此这是一个相当熟悉的领域，可以开始解决任何问题。

证据收集的第二种最常用的技术是使用JVM内置工具 （例如jconsole，jmc，jstat，jmap等）。 60％的受访者正在使用这些工具来寻找实际的根本原因。 如果我们再次回忆起大多数受访者是工程师，那么这又再次变得有意义-JVM嵌入式工具对于工程师来说是众所周知的，因此比OS内置工具可能更喜欢使用。

分析器声称在领奖台上排名第三-答案中有46％列出了诸如Yourkit和JProfiler之类的工具。 的确，如果您能忍受它们构成的开销，则分析器在许多情况下都是适合该工作的工具，因此该职位应有充分的理由。

接下来，是时候分析堆转储和线程转储了。 分别有39％和36％的响应列出了转储分析作为使用的技术之一。 考虑到该领域中的底层工具，多少使这些工具最终被使用是令人惊讶的。

查找根本原因所涉及的下一组工具和技术包括GC日志，调试器，数据库日志和OS级工具。 在25％至32％的案例中提到了这些工具。 特别是OS工具出人意料地不受欢迎–考虑到您可以通过sar，top，iostat等获得的信息，它一定程度上与响应调查的人员数量少有关。

在另一端，我们有七位受访者诚实地说他们转向了外部帮助。 在使用APM工具设法找到根本原因的受访者中，有 31位，即11％ 。 这与我们的经验相符–当前的APM工具擅长于评估性能事件的影响，尤其是根据用户体验来衡量时。 大多数APM提供程序还擅长在基础架构中定位故障节点。 但是，在此级别上，APM提供的见解通常会停止，而其他各种工具也将接管。

此阶段使用的大量工具肯定超出了我们的期望。 一个普通用户在设法收集足够的证据之前使用了不少于四种不同的工具 。

实际根本原因

我们要问的最后一个问题是找出触发性能事件的真正根本原因。 我们收到的778个回复分为以下几类：

在本节中，我们必须承认，由以内存泄漏检测功能闻名的公司发起的调查肯定会使结果歪曲。 根据我们的结果，内存泄漏是迄今为止最常见的性能瓶颈，我们实际上拒绝相信自己。

接下来的两个根本原因是一致的-创建太多数据库查询或效率低下的数据库查询实际上符合许多人的期望。 36％的受访者将这些问题之一列为当前性能问题的根本原因。

同步问题非常普遍，其中有24％的受访者认为同步不良是造成性能瓶颈的根本原因。 正如我们最近在该领域发布的解决方案一样，它很好地证明了我们自己的测量结果。 除此之外，考虑到大多数Java EE开发人员应该与并发算法完全隔离，这仍然是一个令人惊讶的结果。

接下来列出了缓存不良和GC效率低下的问题，分别有22％和21％的受访者将这些问题视为根本原因。 确实可以将这两者一起看待，因为前者经常触发第二个-构建不良的缓存往往会浪费大量时间，从而引发恶性循环，使GC难以应对。

解释其余的根本原因将使职位的长度超出合理的长度。 还有一件值得注意的事情是，可观的数量（10％）的受访者诚实地说他们不知道是什么原因导致了绩效错误。 这再次证实了以下事实：根本原因检测是一个复杂的领域，迫切需要改进工具。

翻译自: https://www.javacodegeeks.com/2014/11/java-performance-tuning-survey-results-part-iii.html