Charlie Hunt和Binu John撰写的Java Performance为Java SE和EE应用程序提供了性能调整建议。 具体来说，它提供有关性能监视，性能分析，调整HotSpot和Java EE应用程序性能调整的信息（后一部分由Binu John编写）。 它适合作为该主题的新开发人员的指南，他们希望他们更好地了解幕后情况，并且还为性能专家提供了出色的参考资料。
尽管还有许多其他书籍涵盖了类似的领域，但是这是一段时间以来该主题的第一本新书，因此它能够涵盖一些最新的Java性能调优技术，例如，当Steve Wilson等人撰写“ Java Platform Performance ”时可用。 本书不仅反映了基础技术和可用的优化技术的变化，还反映了通用软件工程实践的变化，例如，提倡将性能测试作为持续构建周期的一部分，并使项目涉众参与设置性能调整指标早。
本书特别擅长于低级细节，可以很好地呈现各种不同的HotSpot命令行选项，并且是有关JVM调优的出色分步指南。 涵盖概要分析的两章（一章重点介绍如何使用Oracle的Solaris Studio Performance Analyzer和NetBeans Profiler，另一章介绍解决常见问题），也是第一手的，我特别高兴地找到包含常见的源代码示例的附录，但很难解决，例如锁争用，调整Java集合大小和增加并行性等问题。 此外，关于编写有效基准测试以及智能JIT编译器可能引起的问题的部分非常强大，向您展示了如何查看JIT编译器生成的汇编代码以确保您的微基准测试是正确的。做你想做的事。
以及有关自上而下（即以应用程序为中心）的通用调优方法的详细信息，本书提供了有关自下而上（以硬件/ OS为中心）的调优方法的大量信息，并全面介绍了Windows，Linux和Solaris。 例如，这本书讨论了如何减少TLB丢失（也许是CPU缓存丢失的最常见形式）以及如何减少非自愿上下文切换。 为了减少其他类型的CPU停顿，第5章Java应用程序概要分析中有一个侧栏，它讨论了Oracle Solaris Studio Performance Analyzer的-h选项，该选项可用于在配置文件中合并硬件计数器信息，例如由于CPU缓存未命中。 同一边栏还讨论了替代实现如何影响访问Java对象字段的方式和时间，以及如何减少CPU缓存丢失。 但是，它也指出，通常只建议将这种类型的性能调优活动仅用于计算绑定的应用程序，而本书本身并非没有道理，没有提供有关此方法的完整细节。 Charlie＆Binu告诉我们：“实际上，人们认为很有必要调整操作系统非常有趣。” “有些东西很少需要调优。尽管很多人认为调优是“有趣”的，但我们提倡不要调优操作系统，除非您通过收集的数据有证据表明您需要调优需要。”
也许应该注意的是，尽管本书提供了许多有用的，通常适用的信息，但确实着重于Oracle的工具和硬件。 例如，第1章标题为“选择合适的CPU体系结构”的部分几乎全部集中在Oracle的SPARC芯片上，而不是在商用硬件上。 本节的目的是证明运行生产负载的子集作为评估系统性能的一种通用方法存在缺陷，但是可能并没有得到应有的认识。 在其他地方，两个探查器均具有（公认的出色）Oracle Solaris Studio Performance Analyzer工具和NetBeans探查器。 这可能部分是由于篇幅所限（550页加上附录，已经是一本很长的书了），但是如果能提供更多的覆盖范围，看到英特尔的VTune之类的替代品，那真是太好了。 我还希望看到有关替代垃圾收集器的一些讨论，例如Oracle的JRockit，IBM的Balanced GC（公平地说，对于本书的生产进度来说似乎已经很晚了）或Azul的C4，但都没有提及。 在Java EE部分的GlassFish中，所有示例都使用Java EE参考实现。 当然，这里的许多建议同样适用于其他容器，但是最好在文本中看到对它们的更多引用。
另一个挑剔：文本内缺少彩板有时会引起问题。 例如，在整个文本中使用单色屏幕快照会降低其实用性，特别是在第2章（操作系统性能监视）中，该页面缺少颜色使阅读图形比应有的困难。 考虑到59.99美元（美国）的标价，这似乎有些令人失望。
尽管有这些批评，但是，如果以Oracle为中心，这本书是该主题的极佳指南。 它没有提供解决所有问题的方法，但是确实为非性能专家开发人员以及其他与应用程序性能调整工作有关的人员提供了足够的信息，以解决大多数常见的性能问题。
鉴于该书提倡与该主题上的其他方法略有不同-建议使用案例，而不是以代码为中心的调优方法，并且建议软件专业人员在开发周期中考虑性能调优的时间要比通常做的要早得多。 -InfoQ与Charlie Hunt和Binu John进行了交谈，以在此处找到有关他们思想的更多信息。
InfoQ：是什么促使你写这本书的？
Charlie＆Binu ：我们意识到有关Java性能的许多可用信息已经过时，或者很快就过时了。 此外，我们认识到，对Java HotSpot VM的内部结构以及如何进行调优的一些结构了解得更多，这引起了人们的极大兴趣。 另外，我们注意到有些人正在使用Java HotSpot VM命令行选项的组合，但这根本没有道理。 似乎也没有材料将JVM，Java SE和Java EE性能信息的组合汇总到一个卷中。 而且，大多数情况下，我们希望提供我们多年来在Java性能方面学到的知识。 我们希望读者能够在书中找到至少对他们有帮助的一件事。
InfoQ：总的来说，与至少一种敏捷方法相比，至少在您使用的语言方面描述的方法在我看来似乎更适合RUP软件开发方法。 这是一个有效的意见，还是您认为所描述的方法应该适合任何软件开发方法？
在我们看来，我们认为该方法可以适应敏捷方法以及大多数软件开发方法。 我们希望读者能从中脱颖而出的是，应用程序的性能是整个软件开发过程中都应考虑的问题。 特别是，应尽可能早地了解应用程序的预期性能。 如果担心是否可以在软件开发过程的早期实现性能，那么您可以通过进行一些实验来确定这些风险是否“真实”，以及是否需要采取其他替代方法来减轻这种风险。决策，这可能需要对软件体系结构，设计或实现的选择进行重大转变。 此处的关键是无论软件开发方法如何，都能尽早“捕获”性能问题的能力。
InfoQ：您说什么才是开始性能调整之前需要准备的关键内容？
首先要做好的事情是准确地了解您要完成的工作。 如果没有清楚的了解，您可能仍然会学到一些东西，但是您有没有完成自己真正想要完成的事情的风险。
对要完成的任务有清晰的了解将有助于确定您在硬件，软件和其他环境需求方面的需求。 简而言之，我们认为，您对要达成的目标的态度越明确，就越容易确定实现该目标的必要条件。
在性能测试环境中，关键是要有一个环境能够产生一致的结果，并且结果/运行之间的差异尽可能小。 变异性越大，则越难确定是在性能调整工作中真正观察到改进（或回归），还是在运行实验时仅仅是随机噪声（变异性）。 可接受多少可变性取决于您要寻找的改进程度。
顺便说一句，有时很有必要了解为什么给定的环境，设置等会在测试运行之间引入较大的差异，尤其是在您寻求性能的小幅提高，或者您希望确定小百分比的提高时在性能上。 如果您花一些时间研究统计方法及其方程式，则可以在此处理解“可变性”讨论背后的原因。 在第8章“实验设计和统计方法的使用”的书籍部分中也涉及到此主题。
如果您的测试环境偏离生产环境，那么另一重要的事情是您了解差异，更重要的是，这些差异是否会影响或阻碍您在性能调整中要完成的工作。
InfoQ：如果您的测试硬件不是目标或生产环境的精确副本，您是否可以进行有意义的性能测试？
它取决于您想从性能测试中学到什么，还取决于环境如何偏离生产环境。 如果您对要从性能测试中学到的东西有很好的了解，而又没有生产环境的精确副本，那么您需要了解测试环境与生产环境的偏离情况。 如果可以证明环境偏差不会影响您要学习的内容，那么您可以使用不是完全相同的环境。
理想情况下，要确保成功实现性能目标的最大可能性，重要的是要确保测试计算机使用与生产计算机相同的CPU体系结构。 例如，UltraSPARC T系列CPU体系结构与Intel Xeon CPU或AMD CPU有很大不同。 例如，在Intel Xeon测试系统上生成的任何数据都无法轻松地转换为UltraSPARC T系列生产机器。 同样，重要的是要考虑到同一制造商的不同CPU家族之间的体系结构差异，例如：Intel Xeon与Intel Itanium。 下文将介绍更多芯片差异。
但是，请记住，您需要使自己和利益相关者信服，测试环境和生产环境之间的差异不会带来性能差异。 这可能是一项艰巨的任务。 记录您所做的任何假设并能够证明您所做的假设不会带来差异是明智的。 同样，这可能是一项艰巨的任务。
我们在这里也要指出两点。 首先，我们要在此处描述的是围绕您要回答的问题或要学习的知识进行“设计实验”的概念。 然后，确定一个可以满足“实验设计”要求的测试环境，而不会引入偏向或可变性，从而使您想要学习的内容陷入危险。 第二点是（回到芯片差异），这是本章“选择正确的平台并评估系统”，“选择正确的CPU体系结构”和“评估系统性能”的后半部分的原因之一。 “因此读者可以理解，通常，评估系统性能的常用传统方法是将生产系统的一个子集放入新系统中，然后以低于其全部容量的速度运行。在评估使用UltraSPARC T系列CPU的系统时存在缺陷的做法。 这种假设和方法存在缺陷的原因是其CPU体系结构的差异。 包括这些部分的动机是为了使正在评估系统的人们了解这种传统方法存在缺陷，并使读者理解为什么它有缺陷。 另外，我们希望读者也将质疑他们的测试环境与生产环境之间的任何其他差异是否会带来一些意想不到的或无法预料的缺陷。
另一个适用的主题是可伸缩性。 如果测试硬件的虚拟处理器少于生产硬件，则在不同硬件上进行测试通常不会显示可伸缩性问题。 这可以用第6章“ Java应用程序分析技巧和窍门”中使用的一些示例程序来说明。 如果您碰巧在带有少量虚拟处理器的硬件上运行其中的某些示例程序，则可能没有观察到与在具有大量虚拟处理器的测试系统上看到的相同的性能问题。 附录B中也指出了这些程序的示例源代码清单。 因此，如果您想从性能测试中学到什么与Java应用程序的扩展能力有关，那么拥有一个能够（尽可能接近）复制生产环境的测试环境就很重要。
InfoQ：一种性能调优的常用方法（例如，Jack Shirazi的“ Java Performance Tuning ”中提倡的）是设置性能测试，并使用探查器运行以确定例如2或3个性能最差的功能，这些问题并重复进行，直到满足您设置的性能标准。 在阅读本书时，您似乎主张一种不同的方法，即以用例为中心。 因此，您建议查看正在执行的包含该特定方法的用例，并考虑是否存在可用于实现该特定用例的替代方法或算法，它们可能会更好地执行。 这是一个公平的总结吗？如果是，为什么您赞成这种方法？
这是一个非常快速的摘要，但是相当准确。 为了更具体一点，我们提倡首先确定您是否需要分析应用程序。 通过使用JVM监视工具监视应用程序，查看GC日志，查看应用程序日志，并捕获操作系统统计信息，您将观察到下一步的症状或线索，这将为寻找性能的解决方案指明方向。问题。
值得一提的是，我们与正在研究性能问题的人们所注意到的一件事是，他们倾向于倾向于他们最了解的东西。 例如，Java开发人员倾向于立即查看代码，有些人将立即查看代码，系统管理员将查看操作系统数据，尝试调整操作系统，或者向Java开发人员传达他或她的应用程序是表现不佳并继续告诉他或她在操作系统中观察到的内容，并且具有JVM知识的人会倾向于首先调优JVM。 我认为这是可以理解的，因为我们都有“舒适区”。 但是，我们应该让收集的数据驱动性能调整。 正是这些数据将使您最快地获得性能分辨率。
我们提倡在操作系统，JVM和应用程序级别使用监视工具。 然后分析该数据以制定关于下一步的假设。 有时可能是应用程序性能分析，有时可能是JVM调优，有时可能是调优操作系统（我们的经验是很少进行操作系统调优）。
如果我们假设有足够的证据表明下一步是进行应用程序性能分析，那么我们提倡首先退回到调用路径级别的想法，这通常映射到一个用例，然后问自己是什么该应用程序实际上是在尝试做。 大多数现代分析器都提供“最热的呼叫路径”视图。 通过例如在“最热调用路径”中更改为更好的算法，您几乎总是能够比通过改善“最热方法”的性能实现更大的改进。
但是，如果您仅需要进行少量改进即可达到性能目标，那么寻找最热门的方法并加以改进可能会比“最热门的呼叫路径”方法更快地达到最终目标。
因此，我们之所以主张“最热门的呼叫路径”方法，是因为我们假设您正在寻找最佳性能。 我们认为大多数人都同意，退一步来看看替代算法或数据结构，与改变一种或多种方法的实现相比，可以提供更大的性能改进。
InfoQ：您还提倡在需求收集阶段考虑性能。 再说一次，这比我所经历的要早得多。 您为什么认为应该在那里做？
几个原因...它为您提供了识别潜在风险领域的机会，您可以立即开始进行缓解措施，并且越早识别潜在性能问题，在软件开发中后期处理这些问题的成本就越小周期。 它遵循一个众所周知的习惯用法，即“在软件开发生命周期中发现漏洞越早，修复它的成本就越低”。 而且，我们认为性能问题是一个错误。 ;-)
此外，在需求收集时考虑性能并尽早谈论性能有助于建立应用程序的人和将使用该应用程序的人的期望。 它也可能与应用程序的用户一起使用或作为验收测试计划的一部分。
InfoQ：除了单元和其他通常自动化的功能测试之外，建议将性能调整集成到一个连续的集成周期中。 鉴于此，您会提倡雇用性能专家，还是建议尽早解决性能调整问题，并将其作为构建周期的一部分，将任务推向开发人员？
首先，除非您需要专业知识，否则我们不建议雇用绩效专家。 建议将性能测试也包含在单元和其他功能测试中的原因是，应在引入性能问题后立即发现它们。 您越早发现性能问题，花费在查找和修复它们上的时间和金钱就越少。
之所以需要聘请性能专家，是因为无法发现性能问题，或者可能是就如何使性能测试成为单元和功能测试的一部分提供建议。
再次，这里的动机是在引入性能问题时最大程度地减少跟踪所需的时间和精力。 理想情况下，您希望先将性能问题集成到项目的源代码存储库中。 理想情况下，您希望开发人员在提交更改之前发现其性能问题。
InfoQ：您是否还会推荐其他有关该主题的书籍？
Jack Shirazi的书中肯定包含许多有用的技巧。 史蒂夫·威尔逊（Steve Wilson）和杰夫·凯塞尔曼（Jeff Kesselman）的“ Java平台性能”也有许多概念，这些概念今天仍然适用。 对于性能最佳的最佳实践，请查看Josh Bloch的“ Effective Java ”和Brian Goetz的“ 实践Java并发性 ”。
如果您对低级细节感兴趣，可以考虑Darryl Gove的“ Solaris Application Programming ”一书。 尽管它是特定于Solaris的，但Darryl的书中有许多很好的通用概念，它们可以继承Java性能和性能优化的机会，而现代JVM通常会帮您解决这些问题。 Darryl在书中谈到的许多优化类型是Java HotSpot VM的JIT编译器自动完成的优化类型。 Jim Mauro和Richard McDougall撰写的另一本也适合于底层细节领域的书是《 Solaris Internals 》。 同样，尽管一般来说，虽然特定于Solaris，但如果您了解现代操作系统的最重要部分，这些概念也适用于其他现代操作系统。 毕竟，他们通常试图解决类似的问题。
扫一扫
3833
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
