有什么推荐的 Java 分析教程吗？ [关闭]答案

【问题标题】：Any recommended Java profiling tutorial? [closed]有什么推荐的 Java 分析教程吗？ [关闭]
【发布时间】：2011-01-26 05:01:22
【问题描述】：

有推荐的 Java 应用程序分析教程吗？

我现在使用 JProfiler 和 Eclipse Test & Performance Tools Platform (TPTP) 进行分析。然而，虽然配备了出色的武器，但作为 Java 分析的新手，我仍然缺少查明瓶颈的一般理论和技巧。

【问题讨论】：

标签： java performance profiling

【解决方案1】：

JProfiler 附带它的帮助手册。我发现这非常好。

【讨论】：

【解决方案2】：

作为分析的新手，您应该首先寻找具有较长运行时间和/或在典型使用模式/出现瓶颈的地方多次调用的方法。

我不确定 Eclipse 与 JProfiler 的集成是如何工作的，因为我主要使用 NetBeans。但是，在 NetBeans 中有一个“快照”视图，它显示了方法调用的层次结构，其中运行时的总和达到 100%。我寻找占总时间（相对）较大百分比的层次结构部分。从那里您必须考虑这些方法在做什么，以及可能导致它们变慢的原因。

例如：我注意到一个被频繁调用的方法总体上花费了太多时间来完成，并且是一个严重的瓶颈。长话短说，代码使用.contains() 方法检查集合中是否存在项目，并且该集合是一个链接列表。这是一个问题的原因是，对于像.contains() 这样的函数，链表的时间复杂度为 O(n)。这种情况下的修复非常简单，因为我能够用哈希集替换链接列表，它在 O(1) 时间内执行 .contains() 的速度要快得多。

【讨论】：

【解决方案3】：

剖析是一门具有多个思想流派的主题。

更受欢迎的是您通过获取测量结果来继续。也就是说，您尝试查看每个函数需要多长时间和/或调用它的次数。显然，如果一个函数只需要很少的时间，那么加快它的速度将不会给你带来什么好处。但如果它需要很多时间，那么你必须做侦探工作来找出函数的哪一部分负责时间。不要指望函数时间加起来就是总时间，因为函数相互调用，函数A可能需要很多时间的原因是它调用函数B也需要很多时间。

这种方法可以发现很多问题，但这取决于您是一名优秀的侦探，并且能够清楚地思考不同类型的时间，例如挂钟时间与 CPU 时间，以及自我时间与包容时间。例如，应用程序可能看起来很慢，但功能时间可能全部报告为接近零。这可能是由于程序受 I/O 限制所致。如果 I/O 是您所期望的，那可能没问题，但它可能正在执行一些您不知道的 I/O，然后您又回到了侦探工作中。

对分析器的一般期望是，如果您可以修复足够多的东西以实现 10% 或 20% 的加速，那就太好了，而且我从未听说过反复使用分析器来获得比这更多的加速的故事。

另一种方法不是测量，而是捕获。它基于这样的想法，即在程序花费的时间（以挂钟时间）比您希望的时间长时，您主要想知道它在做什么，而找出答案的一种方法是停止它并询问或拍摄其状态的快照并对其进行分析，以完全了解它在做什么以及为什么在特定时间点这样做。如果您多次执行此操作，并且您看到它多次尝试执行的操作，那么您可以对该活动进行有效优化。不同之处在于您不是在问多少；你在问什么和为什么。 Here's another explanation.（请注意，拍摄此类快照的速度并不重要，因为您不是在问时间，而是在问程序在做什么以及为什么。）

在 Java 的情况下，here is one low-tech but highly effective 可以这样做，或者您可以使用 Eclipse 中的“暂停”按钮。另一种方法是使用特定类型的分析器，它在挂钟时间（不是 CPU，除非你想对 I/O 视而不见），当你想要它采样时（例如，不等待用户输入时），并在代码行级别进行汇总，而不仅仅是在函数级别，以及时间百分比，而不是绝对时间。要获得时间百分比，它应该告诉您，对于任何样本上出现的每一行代码，包含该行的样本的百分比，因为如果您可以使该行消失，您将节省该百分比。（你应该忽略它试图告诉你的其他事情，比如调用图、递归和自时间。）符合这个规范的分析器很少，但一个是 RotateRight/Zoom，但我不确定它是否适用于 Java，可能还有其他的。

在某些情况下，在实际运行缓慢期间，可能很难在需要时获取堆栈样本。然后，由于您所追求的是百分比，您可以对代码执行任何操作，以便在不更改百分比的情况下更轻松地获取样本。一种方法是放大代码，方法是在代码周围包裹一个临时循环，例如 100 次迭代。另一种方法是在调试器下设置数据更改断点。这将导致代码的解释速度比正常速度慢 10-100 倍。另一种方法是使用闹钟定时器在缓慢期间响起，并用它来抓取样本。

使用捕获技术，如果您反复使用它来查找和执行多项优化，您可以期望达到接近最佳的性能。在大型软件的情况下，瓶颈更多，这可能意味着大量因素。 StackOverflow 上的人报告了从 7 倍到 60 倍的因子。 Here is a detailed example of 43x.

捕获技术在难以弄清楚为什么线程在等待的情况下会遇到麻烦，例如在等待事务在另一个处理器上完成时。（测量也有同样的问题。）在这些情况下，我使用了一种费力的方法来合并带时间戳的日志。

【讨论】：

请注意，它不必一定是“非此即彼” - 通常以非侵入方式测量一些“典型测试运行”很有用，然后使用分析器作为用于查找热点的捕获工具。反复使用分析器进行更改，然后重新运行测量测试。
@Jon：我确实重新进行了测量（通常只是一个秒表），看看我浪费了多少时间。我是一个狂热者的地方在于寻找解决问题的方法，这很少是我定义的“热点”（程序计数器挂起的区域）或“瓶颈”（需要工作的地方变得拥挤）向上）。通常情况下，最终会调用成堆的代码（包括 IO），而这些代码（包括 IO）是您在编写代码时永远不会猜到的。
我发现仅仅使用IDEA的调试器中的暂停按钮是不够的，因为线程数很多。我每次都需要找到正确的线程 - 很麻烦。但是，我通过定期转储堆栈发现了相同的信息。无需暂停程序 :-)
@oligofren：只要您一次转储与线程状态无关的堆栈，并且您不需要检查堆栈以外的任何数据，那应该可以很好地工作。我知道如果有 100 个线程，找到需要查看的几个线程是一件苦差事，但如果你这样做，你应该得到相同的结果。 OTOH，每次转储时，您都可以有效地获取多个堆栈样本。祝你好运。

【解决方案4】：

您可能会发现 Java Platform Performance 一书很有趣。由 Sun Microsystems 出版。

【讨论】：

【解决方案5】：

我正在使用 Yourkit Java Profiler 11.0，它非常适合内存优化和监控 CPU 时间。 yourkit 网站也有很好的知识库和帮助主题。

【讨论】：