VisualVM 未显示任何调用 CPU 性能分析的方法
我正在运行 Java 1.6_21 SDK 构建应用程序。它是在 Eclipse 中构建的，我使用 VistualVM eclipse 插件在应用程序启动时启动 VisualVM。
当我转到“配置文件”选项卡并单击“CPU 分析”时，它仅显示正在运行的线程，但不显示任何方法调用。几乎没有。我用谷歌搜索了一大堆东西，但似乎没有一个合适的。有人见过这个问题吗？有解决办法吗？？
环境：Windows XP 32位 “经典”Eclipse SDK 3.7.0 SDK 1.6_21 中的 VisualVM
对我来说没有任何意义。我可以获得内存堆信息，但成员调用信息为零。
非常感谢任何帮助。
I'm running a Java 1.6_21 SDK build app. Its been build in Eclipse, and i'm using the VistualVM eclipse plugin to launch VisualVM when the app starts.
When I go to the Profile tab and click CPU profiling, It only shows the THREADS that are running, but it doesn't show any METHOD calls. Quite litterally, none. I've googled a whole bunch of things, but nothing seems to fit. has ANYONE seen this problem? Is there a solution??
Environment: Windows XP 32-bit
"Classic" Eclipse SDK 3.7.0
VisualVM from SDK 1.6_21
It doesn't make any sense to me. I can get memory heap information, but zero member-calling information.
Any help is extremely appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否尝试过设置要分析的类。
选择窗口右上角的“设置”复选框设置需要分析的包。
have you tried setting classes to be profiled.
select the Settings checkbox in the top right cornet of the window & set the packages which needs to be profiled.
请参阅使用 VisualVM 进行分析，第 1 部分< /a> 和 使用 VisualVM 进行分析，第 2 部分了解如何设置 CPU 设置。
VisualVM 进行分析，第 1 部分
使用 VisualVM 进行分析，第 1 部分
作者：Jiri Sedlacek，发表于 2008 年 7 月 28 日
本文介绍了 VisualVM 工具的开箱即用的分析功能，无需任何其他配置，只需使用默认设置。
除了各种监视功能之外，该工具还包含一个基于 NetBeans 分析器。虽然 VisualVM 中的分析器 UI 看起来很简单（尤其是与 NetBeans 分析器相比），但分析功能几乎与 NetBeans 中的一样强大。这两个工具之间的主要区别在于它们的工作流程：NetBeans 探查器以项目/源为中心，是在应用程序开发过程中进行迭代测试/提高性能的绝佳工具，而 VisualVM 可以用作独立的探查器，可与任何正在运行的应用程序配合使用，而无需任何操作。具有源代码的任何上下文。
分析 UI 非常简单，默认情况下它仅显示三个按钮，用于分析性能（CPU 按钮）、内存使用情况（内存按钮）和停止分析会话（停止按钮）。其他 UI 元素是显示实际分析状态的状态区域和显示分析会话期间收集的实时分析数据的分析结果部分。对于高级分析，还有一个默认情况下隐藏的“设置”部分。它允许微调分析设置，[使用 VisualVM 进行分析，第 2 部分文章]（#使用 VisualVM 进行分析，第 2 部分文章）对此进行了详细描述。
分析性能
当按下 Profiler 选项卡中的 CPU 按钮时，分析器会连接到应用程序并开始分析其性能。一开始，探查器需要检测应用程序的某些方法，检测的方法的实际数量显示在“状态”区域中。由于分析器使用动态检测，因此检测方法的数量可能会在分析会话期间发生变化。连接探查器并开始收集数据后，视图如屏幕截图所示：
您可以查看应用程序的实时分析数据，包括每个分析方法的调用次数和总数显示执行时间。请注意，并非所有方法都会被分析，默认情况下 分析器不会分析来自 java.*、javax.*、sun.*、sunw.*、com.sun.* 的方法 (+ Mac OS X 上的 >com.apple.*、apple.awt.*）软件包。这些包中的方法所花费的时间会添加到调用它们的分析方法的执行时间中，例如自定义类 (CustomClass.) 的构造函数执行时间包括超级构造函数等的执行时间
。 sstatic.net/5GOGn.png" rel="nofollow noreferrer">
分析工具栏结果部分包含以下操作（从左至右）：
最重要的操作是拍摄收集结果的快照（也可在应用程序树中已分析应用程序的上下文菜单中作为分析器快照使用）。它拍摄收集的分析结果的快照（与 NetBeans 分析器快照兼容）并在单独的选项卡中打开它。此快照提供了几种不同的视图：调用树显示以线程开头的方法调用树，热点显示按执行时间排序的所有分析方法的列表以及组合方法 显示调用树和分析方法列表的视图。最后一个视图 Info 显示快照的基本信息和快照的详细分析配置。每个方法的上下文菜单中都有一个方便的操作，称为显示返回跟踪，并显示调用该方法的所有位置。
可以为单个分析拍摄多个分析器快照例如，会话可以比较应用程序的各种情况/负载/配置下的性能。然后，所有探查器快照都可以保存到单个应用程序快照中（使用应用程序树中已分析应用程序的上下文菜单中的“应用程序快照”操作），将它们存档在一个文件中或将它们发送给应用程序开发人员/质量人员工程师。
分析内存
当按下“分析器”选项卡中的“内存”按钮时，分析器将连接到应用程序并开始分析其内存消耗。一开始，探查器需要检测应用程序的所有类，检测的类的实际数量显示在“状态”区域中。由于所有应用程序类都需要进行检测，因此探查器需要一些时间才能开始收集数据。为了降低分析开销，默认情况下会跟踪每 10 个对象分配（也显示在状态区域中）。评估分析结果时请记住这一点。连接探查器并开始收集数据后，视图如屏幕截图所示：
您可以查看应用程序的实时分析数据，每个类的实时实例数和他们的显示尺寸。最右边的列显示幸存代指标，这对于检测内存泄漏非常有用。有关幸存一代的详细说明，请参阅 这篇文章。您还可以在一段时间内监视特定类的分配历史记录（底部的“历史记录”子选项卡），为此，请调用类上下文菜单中的记录类历史记录操作。
内存分析结果的工具栏与 CPU 分析结果的工具栏相同。您还可以使用分析结果部分工具栏中的“拍摄收集结果的快照”操作或分析器快照上下文菜单操作将收集的结果保存到快照中。这对于检测内存泄漏特别有用，使用“文件”菜单中提供的“比较内存快照”操作，您可以直观地显示两个可比较内存结果之间的差异，例如评估之后是否/哪些对象仍保留在堆上。执行一些动作。
探查器校准
当 VisualVM 第一次启动时，探查器会执行初始校准。在此过程中，将测量整个系统和实际 JDK 性能，这些数据随后用于从收集的性能数据中减去分析开销。分析器要求系统具有“稳定”的性能，这意味着任何用于动态 CPU 频率切换的技术（如 SpeedStep 或 PowerNow！）在校准和分析过程中应禁用。
如果系统性能发生变化或者使用与校准后的不同的 JDK 进行分析，则收集到的性能结果可能会出现偏差，并且需要重新校准分析器。遗憾的是，VisualVM 1.0 中没有可用于重新校准的 UI 操作，再次调用校准的唯一方法是手动删除
/.nbprofiler/machinedata.jdk1X 使用 VisualVM 进行分析，第 2 部分
本文介绍了 VisualVM 工具，使用户可以更好地控制分析会话和收集的数据。您可能还想阅读[使用 VisualVM 进行分析，第 1 部分](#使用 VisualVM 进行分析，第 1 部分) 文章，其中描述了 VisualVM 的基本分析功能。
默认情况下，VisualVM 中的 Profiler UI 不显示任何设置，初始配置可确保即使是没有经验的用户，只需单击 CPU 或内存按钮即可通过零配置获得一些有用的结果。但是，高级用户仍然可以微调设置并充分利用 NetBeans 分析器引擎的功能。
要显示设置区域，必须选中 Profiler 选项卡右上角的设置复选框。设置区域由两个选项卡组成：CPU 设置 和内存设置，其中包含每种分析模式的控件。
该区域底部还有一个恢复默认值按钮，可恢复初始配置。当值自定义不正确并且未收集分析数据时，这非常有用。
性能分析
对于性能分析，有两个重要的可用设置：分析根和检测过滤器。一般来说，分析根定义分析器何时开始收集数据，而检测过滤器定义应该/不应该收集数据的包/类。
从类开始分析文本框定义分析根。如果对所有方法进行检测，分析开销将是巨大的，并且分析最终将变得无法使用。这就是 NetBeans 分析器引入根方法概念的原因 - 一种仅分析感兴趣的代码而应用程序的其余部分全速运行的方法。
例如，典型的用例是分析通过单击按钮调用的操作的性能 - 如果将适当的
actionPerformed()方法设置为根方法，则一旦actionPerformed()方法设置为根方法，分析器就会开始检测和分析应用程序>actionPerformed() 方法被调用，并且仅分析从actionPerformed()调用的方法。这样，分析开销非常小，并且只收集相关的分析结果，这大大提高了它们的可读性。在 NetBeans 探查器中，选择根方法是非常自然的，因为它与编辑器紧密集成，但在 VisualVM 中，这可能有点棘手，而且不太用户友好。这就是 VisualVM 定义按类分析根的原因 - 这些类及其内部类中定义的所有方法都成为根方法。以类似的方式，包名称可以用作分析根。这就是默认分析根的定义方式：
.** 默认设置在大多数情况下都有效，但对于应用程序服务器等大型应用程序，调整分析根以指向感兴趣的具体代码可能会很有用。例如，在分析 Web 应用程序时，最好将 servlet 的包或类名设置为分析根，而不是分析整个服务器。
在 VisualVM 中输入分析根的格式如下：
org.mypackage中的所有方法和所有子包定义为根方法org.mypackage中的所有方法定义为根方法org.mypackage.MyClass 中的所有方法code> 及其内部类作为根方法为可以为单个分析会话定义多个分析根（由空格和/或逗号和/或换行符分隔）。
仅分析类 / 不分析类文本框定义检测过滤器。这与 NetBeans 分析器中的快速过滤选项完全相同。它要么定义要分析的唯一包/类，要么定义不分析的包/类。例如，如果仅应分析应用程序的代码，而无需对其他框架或 JDK 代码进行任何传出调用，则应将此选项设置为仅分析类，.。如果应分析除 java 和 javax 包中的 JDK 类之外的所有代码，则应将此选项设置为“不分析类、java.、javax.”。默认的检测过滤器是“不分析类”、java.、javax.、sun.、sunw.、com.sun. (+ com.apple. ，apple.awt.（Mac OS X 上）），它会过滤掉所有 JDK 代码。
输入检测过滤器的格式如下：
可以为单个分析会话定义多个过滤器值（由空格和/或逗号和/或换行符分隔）。
##分析内存
对于内存分析，可以使用三个重要设置：分析范围、跟踪对象的密度和记录分配堆栈跟踪。
分析范围由以下两个选项之一定义：对于分析对象分配选项，仅监视对象分配。这在评估应用程序分配了多少对象时非常有用。对于检查和识别内存泄漏，第二种选择更有用 - 分析对象分配和 GC。在这种模式下，分配的对象在整个生命周期内受到监视，从分配到垃圾回收。这允许轻松识别当前在某个点分配在堆上的活动对象。此外，在此模式下，“幸存一代”指标可用（有关更多信息，请参阅本文）。默认情况下，配置文件对象分配和 GC 选项处于选中状态。
跟踪每 N 个对象分配选项允许定义跟踪对象的密度。在大多数应用程序中，没有必要监视每个实例，当仅跟踪每个第 N 个对象时，总体分配行为是相同的。这种方法的优点是分析开销较低。要获取已分配或活动对象的准确数量，必须将此选项设置为 1。默认情况下，每第 10 个对象都会被跟踪。
第三个控件是记录分配堆栈跟踪复选框。选择此选项后，将在分配时为每个受监视对象进行堆栈跟踪。这允许识别已分配对象的具体方法（及其调用树）。默认情况下，禁用分配堆栈跟踪的收集以降低分析开销。
与 NetBeans Profiler 的比较
本节比较 NetBeans Profiler 和 VisualVM 中可用的分析设置。对于无法在 VisualVM 中自定义的设置，列出了预定义值。
CPU 分析设置：
内存分析设置：
进一步阅读
有关详细信息，请参阅 VisualVM文档，尤其是分析应用程序部分。
您还可以找到 NetBeans Profiler 5.5 文档 很有用，尤其是检测根方法，<一个href="https://web.archive.org/web/20090608135056/http://profiler.netbeans.org/docs/help/5.5/custom_cpuprofiling.html" rel="nofollow noreferrer">CPU 分析设置 或 内存分析设置 部分。
See Profiling With VisualVM, Part 1 and Profiling With VisualVM, Part 2 to find out how to set CPU settings.
Profiling With VisualVM, Part 1
Profiling With VisualVM, Part 1
By Jiri Sedlacek on Jul 28, 2008
This article describes the out-of-the-box profiling features of the VisualVM tool available without any additional configuration, just using the default settings.
Beside various monitoring features, the tool contains a built-in profiler based on the NetBeans profiler. While the profiler UI in VisualVM looks simple (especially when compared to the NetBeans profiler), the profiling capabilities are almost as powerful as in NetBeans. The main difference between these two tools is their workflow: whereas NetBeans profiler is project/sources-centered and is a great tool for iterative testing/improving performance during application development, VisualVM can be used as a standalone profiler which works with any running application without having any context of the source code.
The profiling UI is very simple, by default it shows just three buttons for analyzing performance (CPU button), memory usage (Memory button) and stopping the profiling session (Stop button). The other UI elements are Status area where the actual profiling status is shown and Profiling results section which displays live profiling data collected during the profiling session. For advanced profiling there's also a Settings section which is hidden by default. It allows to fine-tune the profiling settings, this is described in detail in [Profiling With VisualVM, Part 2 article](#Profiling With VisualVM, Part 2 article).
Profiling Performance
When the CPU button in Profiler tab is pressed, the profiler attaches to the application and starts profiling its performance. At the beginning the profiler needs to instrument some methods of the application, the actual number of instrumented methods is displayed in the Status area. Since the profiler uses dynamic instrumentation, the number of instrumented methods may change during the profiling session. After the profiler is attached and starts collecting the data, the view looks like on the screenshot:
You can see live profiling data for the application, for each profiled method number of invocations and total execution time is displayed. Note that not all methods are profiled, by default the profiler doesn't profile methods from java.*, javax.*, sun.*, sunw.*, com.sun.* (+ com.apple.*, apple.awt.* on Mac OS X) packages. Time spent in methods from these packages is added to execution time of profiled methods calling them, for example constructor execution time of a custom class (CustomClass.) includes execution time of super constructor etc.
The toolbar of Profiling results section contains the following actions (from the left):
The most important action is Take Snapshot of Collected Results (available also as Profiler Snapshot in context menu of profiled application in Applications tree). It takes a snapshot of collected profiling results (compatible with NetBeans profiler snapshot) and opens it in a separate tab. This snapshot provides several different views: Call Tree displaying methods call tree starting by threads, Hot Spots displaying a list of all profiled methods sorted by their execution time and Combined view showing both call tree and list of profiled methods. The last view Info displays basic snapshot information and detailed profiling configuration of the snapshot. There's one handy action available in context menu of each method, it's called Show Back Traces and displays all the places from where the method is being called.
Multiple profiler snapshots can be taken for a single profiling session for example to compare performance in various situations / loads / configurations of the application. All the profiler snapshots can be then saved into a single Application Snapshot (use Application Snapshot action in context menu of profiled application in Applications tree) to archive them in one file or to send them to application developers/quality engineers.
Profiling Memory
When Memory button in Profiler tab is pressed, the profiler attaches to the application and starts profiling its memory consumption. At the beginning the profiler needs to instrument all classes of the application, the actual number of instrumented classes is displayed in the Status area. Because all the application classes need to be instrumented, it takes some time until the profiler starts to collect the data. To lower the profiling overhead, each 10th object allocation is tracked by default (also displayed in Status area). Keep this in mind when evaluating the profiling results. After the profiler is attached and starts collecting the data, the view looks like on the screenshot:
You can see live profiling data for the application, for each class number of live instances and their size is displayed. The rightmost column shows Surviving Generations metrics which is very useful for detecting memory leaks. Detailed explanation of Surviving Generations is available in this article. You can also monitor allocations history of a particular class during time (History subtab at the bottom), to do this invoke the Log Class History action in context menu of the class.
The toolbar of memory profiling results is the same as for CPU profiling results. You can also save the collected results into a snapshot using the Take Snapshot of Collected Results action in Profiling results section toolbar or Profiler Snapshot context menu action. This is especially useful for detecting memory leaks, using the Compare Memory Snapshots action available in File menu you can visually display the difference between two comparable memory results and for example evaluate if/which objects remained on the heap after executing some action.
Profiler Calibration
When VisualVM is started for the first time, the profiler performs an initial calibration. During this process the overall system and actual JDK performance is being measured and these data are later used to subtract the profiling overhead from collected performance data. The profiler requires a "stable" performance of the system, this means that any technique for dynamic CPU frequency switching like SpeedStep or PowerNow! should be disabled during both the calibration and profiling.
If the system performance changes or a different JDK than the calibrated one is used for profiling, the collected performance results may become biased and the profiler needs to be re-calibrated. Unfortunately there's no UI action available for recalibration in VisualVM 1.0, the only way to invoke the calibration again is to manually delete calibration data file in
<user_directory>/.nbprofiler/machinedata.jdk1Xand restart the VisualVM.Profiling With VisualVM, Part 2
This article describes advanced profiling features of the VisualVM tool which give the user more control over the profiling session and collected data. You may also want to read the [Profiling With VisualVM, Part 1](#Profiling With VisualVM, Part 1) article describing the basic profiling features of VisualVM.
By default, the Profiler UI in VisualVM doesn't display any settings, the initial configuration ensures that even an unexperienced user will get some useful results with zero configuration by just clicking the CPU or Memory button. However, an advanced user still has the possibility to fine-tune the settings and fully utilize the power of the NetBeans profiler engine.
To display the settings area, Settings checkbox has to be selected in the topright corner of Profiler tab. The settings area consists of two tabs, CPU settings and Memory settings, containing controls for each profiling mode.
There's also a Restore Defaults button available at the bottom of the area which restores the initial configuration. This is useful when the values were customized incorrectly and no profiling data are being collected.
Profiling Performance
For performance profiling there are two important settings available: profiling roots and instrumentation filter. In general, profiling roots define when the profiler should start collecting the data whereas instrumentation filter defines packages/classes from which the data should/shouldn't be collected.
Start profiling from classes textbox defines the profiling roots. If all the methods were instrumented, the profiling overhead would be enormous and profiling would eventually become unusable. That's why the NetBeans profiler introduces a notion of Root Methods - a way to profile just the code of interest while the rest of the application runs at full speed.
A typical usecase is for example profiling performance of an action invoked by a button click - if the appropriate
actionPerformed()method is set as a root method, the profiler starts instrumenting and profiling the application once theactionPerformed()method is invoked and only profiles the methods called from theactionPerformed(). This way the profiling overhead is very small and only relevant profiling results are collected which greatly improves their readability.Whereas in NetBeans profiler selecting a root method is very natural because of its tight integration with the editor, in VisualVM this might be a bit tricky and not exactly user friendly. That's why VisualVM defines profiling roots by classes - all methods defined in these classes and their innerclasses become root methods. In the similar way, package names can be used as profiling roots. That's how the default profiling roots are defined:
<main_class_package>.**which means that all methods from<main_class_package>and subpackages are profiled.The default settings work in most cases, but for large applications like application servers it might be useful to tweak the profiling roots to point to a concrete code of interest. For example, when profiling a web application it's much better to set the servlet's package or classname as a profiling root instead of profiling the whole server.
The format for entering the profiling roots in VisualVM is following:
org.mypackageand all subpackages as root methodsorg.mypackageas root methodsorg.mypackage.MyClassand its innerclasses as root methodsMultiple profiling roots (separated by a space and/or comma and/or newline) can be defined for a single profiling session.
Profile only classes / Do not profile classes textbox defines the instrumentation filter. This is exactly the same option as Quick Filter in the NetBeans profiler. It either defines the only packages/classes to be profiled or packages/classes not to be profiled. For example, if only an application's code should be profiled without any outgoing calls to other frameworks or JDK code, this option should be set to Profile only classes, <application_package>.. If all the code except JDK classes from java and javax packages should be profiled, this option should be set to Do not profile classes, java., javax.. The default instrumentation filter is Do not profile classes, java., javax., sun., sunw., com.sun. (+ com.apple., apple.awt. on Mac OS X) which filters out all the JDK code.
The format for entering instrumentation filter is following:
Multiple filter values (separated by a space and/or comma and/or newline) can be defined for a single profiling session.
##Profiling Memory
For memory profiling there are three important settings available: profiling scope, density of tracked objects and recording allocations stack traces.
The profiling scope is defined by one of two choices: for the Profile object allocations option only object allocations are monitored. This is useful when evaluating how many objects are allocated by the application. For checking and identifying memory leaks the second choice is more useful - Profile object allocations and GC. In this mode the allocated objects are monitored during the whole lifecycle, from their allocation till garbage collection. This allows to easily identify live objects currently allocated on the heap at certain point. Also, in this mode the Surviving Generations metrics is available (see this article for more information). By default, Profile object allocations and GC option is selected.
The Track every Nth object allocations option allows to define density of tracked objects. In most applications it isn't necessary to monitor each single instance, the overall allocations behavior is the same when tracking just each Nth object. The advantage of this approach is lower profiling overhead. To get exact number of allocated or live objects, this option has to be set to 1. By default, each 10th object is tracked.
The third control is the Record allocations stack traces checkbox. When selected, a stack trace is taken for each monitored object when allocated. This allows to identify the concrete method (and its call tree) which has allocated the object. By default the collecting of allocation stack traces is disabled to lower the profiling overhead.
Comparison With The NetBeans Profiler
This section compares profiling settings available in the NetBeans profiler and VisualVM. For the settings which cannot be customized in VisualVM the predefined value is listed.
CPU profiling settings:
Memory profiling settings:
Further Reading
For more information see the VisualVM Documentation, especially the Profiling Applications section.
You may also find the NetBeans Profiler 5.5 documentation useful, especially the Instrumenting a Root Method, CPU Profiling settings or Memory Profiling Settings sections.
我注意到 Visual VM 报告了错误的方法调用样本计数（我相信这些意味着调用方法的次数）。
I noticed Visual VM reporting incorrect method call sample counts (I believe those mean the number of times a method was called).