如何使用 jprofiler 分析 gwt 客户端应用程序？

Posted 2023-03-06

【中文标题】如何使用 jprofiler 分析 gwt 客户端应用程序？

【英文标题】：How to profile a gwt client application with jprofiler?

【发布时间】：2014-10-06 13:51:12

【问题描述】：

我的 GWT 应用程序存在内存泄漏问题，我正在尝试使用 JProfiler 对其进行分析。

我无法获得相关结果，因为我在配置文件内存视图中看不到我的 java 类，我只看到 GWT lib 类。

我已添加参数以使用 JProfiler 分析远程应用程序（-agentpath:C:\PROGRA~1\JPROFI~1\bin\WINDOW~1\jprofilerti.dll=port=8849）。我通过 Eclipse IDE 以 superDevMode 启动项目。 JProfiler 向我展示了内存中的 GWT 类，但它没有展示我自己的 java 类。

在此视频 youtube.com/watch?v=zUJUSxXOOa4 中，我们可以看到 JProfiler 可以直接显示 java 类，这就是我搜索要做的事情

是否有任何选项可以在 JProfiler 中激活？欢迎在这件事上提供任何帮助。谢谢

【问题讨论】：

看看这个-> ***.com/a/1628863/3472757

gwt application logging, profiling, benchmarking的可能重复

【参考方案1】：

超级开发模式不适用于 Java 分析器。旧的 Dev 模式 通过一个特殊的插件在 JVM 中执行客户端代码。如今，开发模式浏览器插件不适用于现代浏览器。最后支持这些插件的浏览器是 Chrome 21.0.1180.89 和 Firefox 26。

截至目前，Firefox 24 ESR 仍受支持：

https://www.mozilla.org/en-US/firefox/organizations/all/

并且开发模式插件在该版本中工作。有关开发模式的更多信息，请参阅

http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html

【讨论】：

也就是说，在经典开发模式下将 JProfiler 与 GWT 代码一起使用并不是分析代码的速度或它在浏览器中使用的内存量，而是测量代码在开发模式下使用的内存量，这是不一样的。如果您想实际测量浏览器性能，请使用浏览器性能工具。

当然可以，但是如果某些东西真的很慢，那么总体特征基本相同。我发现 JProfiler 的 GWT 性能瓶颈不止一个，我很遗憾开发模式即将消失。

有时你是对的，但有时你会大错特错——如果 DOM 操作在 Dev 模式下很慢，它在 prod 中通常会很快，如果在 dev 模式下数学很快，它通常会慢慢来。任何 JSNI 在 dev 中都有巨大的性能开销，并且在 prod 等中是免费的。

非常感谢您提供这些链接。好的，那么你知道一个分析工具，它可以分析 gwt 生成的 js 代码并显示导致内存泄漏的 java 类（显示应用程序使用的实例数）？

@ColinAlworth DOM 操作仍然在浏览器中完成，它只是在代码服务器中执行的程序逻辑。该逻辑的执行方式有所不同，但由于瓶颈主要来自缓慢的 DOM 操作，因此这并不重要。以我的经验，在出现瓶颈的情况下，测量的性能特征从来没有大错特错。

【参考方案2】：

我不这么认为。 GWT 将你的类编译为 JS，因为这个 JProfiler 不起作用（我认为，但也许我错了）。也许您可以尝试使用堆转储的 MemoryAnalyzer。

【讨论】：

在这个视频youtube.com/watch?v=zUJUSxXOOa4我们可以看到JProfiler可以直接显示java类，这就是我搜索要做的事情

好的，抱歉。我不知道。

【参考方案3】：

Chrome 带有一些很棒的内置 CPU 和堆分析工具。 Firefox 现在有自己的内置 CPU 分析器，而 Firebug 有一个不同的。 IE（至少 10 个，我认为是 9 个）有一个内置的 CPU 分析器，尽管我已经很久没有深入研究了。

历史上，在浏览器中内存是一件很难追踪的事情，尤其是因为旧的 IE 版本不会死，而且只是因为看起来很有趣而泄漏。如果您面临这些内存泄漏之一，则需要不同的攻击计划。

但是，如果您怀疑自己的应用程序代码存在泄漏问题，Chrome 的开发工具可以提供帮助！在PRETTY（或DETAILED，如果您的屏幕非常宽）中编译，并在打开开发者工具的情况下在 Chrome 中打开您的应用。

在 Profiles 选项卡中，有三种要捕获的配置文件，两种是关于内存的。我通常更喜欢获取堆快照，并在“之前”和“之后”查看我认为会泄漏内存的任何操作，但记录堆分配视图将为您提供另一种考虑应用程序内存使用情况的方法。

首先选择一个所谓的“稳定”内存使用状态 - 打开应用程序，使用一段时间，确保所有各种单例等都已实例化，并可能执行您怀疑会导致问题的任何操作，一次。一旦您处于可以返回的位置（内存方面，至少在泄漏已修复的情况下），拍摄快照，执行泄漏行为，返回“稳定”状态，然后拍摄另一个快照。检查泄漏时只采取一步，稍后会详细介绍。

通过这两个快照，您可以比较分配和释放的对象 - 我们最感兴趣的是创建的对象多于删除的对象的情况，理想情况下删除的对象为零。如果你发现 N 个对象被删除但 N+1 个被创建，那么在挖掘之前确保 N 非常小 - 通常只能通过跟踪单个对象来修复泄漏，将它们追溯到它们的实际泄漏源，修复它，并再次测量。

一旦您有一个在一个步骤中创建的对象，但在该步骤结束时没有删除（但它应该已经删除），请使用“保留者”视图查看为什么它们仍然被保留。这将或多或少地向您显示保存它们的对象中的字段以及该保存对象的类型，一直到 window 或其他一些全局对象。

忽略 () 中的任何内容，例如 (compiled code)、(array)、(system)、(string) 等。我通常会忽略 dom 元素分配（假设您怀疑自己有应用程序代码中的泄漏，而不是 JSNI）。寻找泄漏的少数高级别对象，而不是许多低级别，这将使您更有可能更接近泄漏源。

PRETTY 中编译的构造函数和字段的名称​​通常与原始 Java 源非常接近。所有构造函数都将_X 附加到它们之后，其中X 是0、1 等——这是为了区别于类型本身。这为识别构造函数列中的 Java 类型提供了一种简单的方法，因为它们的名称末尾都有_s。