java 性能调优
这是本系列中的最后一篇文章，我们将分析我们在2014年10月进行的Java Performance Tuning Survey的结果。如果您尚未阅读第一篇文章，建议您首先阅读以下内容：
- 性能问题的频率和严重性
- 最受欢迎的监控解决方案
- 查找根本原因的工具和技术
这篇文章打开了一些有趣的相关数据并总结了结果。
复制是快速成功的关键
当您负责解决性能问题时，您需要证据来找到根本原因。 为了获得证据，您通常需要重现问题。 在调查中，我们询问了受访者是否能够重现该问题 ：
- 9％不需要复制，已经有足够的证据
- 27％无法重现该问题
- 64％设法重现该问题
在另一个问题中，我们问“ 找到并解决您遇到的问题需要花费多长时间”。 平均而言，这花费了80个小时 。 我们分析了是否有27％无法重现该问题的人是否还在苦苦挣扎。 结果很明显：
- 如果受访者能够重现问题，则平均需要65个小时
- 如果响应者无法重现该问题，则 需要花费 113个小时或74％的时间才能找到根本原因并加以解决。
区别清晰可见。 造成这种差异的原因隐藏在故障排除过程中。 要解决问题，您需要证据，通常是从各种来源收集的证据，例如日志文件，线程转储或堆转储。 但是，只有在能够重现案件的情况下（最好是随心所欲），您才能获得证据。 如果您无法重现问题，那么您将没有证据，而武库中唯一的工具往往是良好的旧尝试和错误。 面对超过100,000行代码，您注定会在此过程中面临许多失败的尝试。
有些问题比其他问题难。
受访者还向我们提供了他们正在解决的性能问题的根本原因。 我们研究了不同的问题，以了解某些问题是否比其他问题更难解决
让我们再次回顾一下，发现和解决问题的平均时间为80个小时。 在按问题类型进行分类时，我们发现了以下内容：
- 查找和修复最简单的问题与网络IO有关：平均花费51个小时。
- 内存泄漏按所花费的时间准确地排在平均水平：平均发现并修复一个泄漏所花费的时间为80小时24分钟。
- 另一方面是架构问题–根本原因与整体架构和HTTP会话膨胀有关，分别花费了98 和105个小时。 查找和解决原因的时间增加了大约100％ 。
从极端来看，这实际上并不奇怪。 当您的体系结构引起性能问题时，修复程序本身往往很复杂且耗时，因此需要更多的时间来修复。 而且当您倾向于滥用网络时，它通常可以归结为一个恶意呼叫，您可以轻松地对其进行隔离和修复。
随机工具帮助
接下来，我们分析了用于解决某些潜在根本原因的工具和技术。 我们注意到，平均而言，用户不会尝试使用不少于四种不同的工具来收集证据并找到根本原因 。 最流行的工具和技术涉及日志分析，堆/线程转储和分析器。
当我们研究工具在各种潜在问题中的使用时，我们感到非常惊讶。 根本的问题和用于进行故障排除的工具之间几乎没有关联-列出了相同的工具，而频率与出现的问题无关。
最好的例子可能是线程转储分析。 这是收集有关并发问题的证据的好方法。 实际上，解决并发问题的受访者中有52％使用线程转储分析作为根本原因分析来源之一。 但是例如，当眼前的问题是内存泄漏时，则有42％的情况列出了相同的线程转储分析。
或者，从工具的角度看–与问题类型无关，有41-53％的受访者使用探查器收集证据，而与症状和潜在问题无关。
从这些数据得出结论是很棘手的，但是看来证据收集和分析过程是非常非正式的，涉及使用该特定人员以前使用或听说过的工具和技术。
结论
进行这项调查是为了指导Plumbr的进一步发展。 对我们而言，主要结论基于调查的四个关键结果：
- 查找和解决性能问题的平均时间为80小时
- 对于76％的案件，大部分时间都花在了恶性的“试图复制-收集证据-解释证据”周期中。
- 27％的情况无法复制。 在这种情况下，查找和解决问题所花费的时间增加了73％。
- 证据收集过程是完全非正式的，平均涉及四个随机选择的工具
我们承诺从这里开始，并为上述问题提供解决方案。 使用Plumbr监视系统，可以立即将您准确定位到根本的根本原因，从而完全跳过“尝试复制-收集证据-解释证据”的周期：
我们当前的产品允许线程锁定，低效率的GC和内存泄漏，但是我们一直在扩展我们的产品，因此您将拥有一个安全网来应对影响JVM的所有性能问题。
翻译自: https://www.javacodegeeks.com/2014/12/java-performance-tuning-survey-results-part-iv.html
java 性能调优
