我的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中激活？欢迎任何有关此事的帮助。谢谢
答案 0 :(得分：0)
我不这么认为。 GWT将你的类编译成JS，因为这个JProfiler不会工作（我想，但也许我错了）。也许你可以尝试使用堆转储来对MemoryAnalyzer进行尝试。
答案 1 :(得分：0)
超级开发模式不适用于Java分析器。旧的开发模式通过一个特殊的插件在JVM中执行客户端代码。目前，Dev模式浏览器插件不适用于现代浏览器。最后支持这些插件的浏览器是Chrome 21.0.1180.89和Firefox 26.
截至目前，仍然支持Firefox 24 ESR：
https://www.mozilla.org/en-US/firefox/organizations/all/
并且Dev模式插件适用于该版本。有关开发模式的更多信息，请参阅
http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html
答案 2 :(得分：0)
Chrome附带了一些非常棒的内置CPU和堆分析工具。 Firefox现在有自己的内置CPU分析器，Firebug有不同的。 IE（至少10，我认为9）有一个内置的CPU分析器，虽然我已经很长时间没有挖到那里了。
在浏览器中，内存在历史上是一件难以追踪的事情，尤其是因为旧的IE版本不会死亡，只是看着它们有趣而泄漏。如果您遇到那些内存泄漏之一，则需要采用不同的攻击计划。
但是，如果您怀疑自己正在处理自己的应用程序代码中的泄漏，Chrome的开发工具可以提供帮助！如果您的屏幕非常宽，请在PRETTY（或DETAILED）中进行编译，并在打开开发人员工具的情况下在Chrome中打开您的应用。
在“配置文件”选项卡中，有三种要捕获的配置文件，两种关于内存的配置文件。我通常更喜欢Take Heap Snapshot，并在“之前”和“之后”查看我认为泄漏内存的任何操作，但Record Heap Allocations视图将为您提供另一种方法来考虑应用程序的内存使用情况。
首先选择一个所谓的“稳定”状态的内存使用情况 - 打开应用程序，使用它一点，确保所有各种单例等都被实例化，并且可能做你怀疑导致问题的任何动作，一旦。一旦您处于可以返回的位置（内存方面，至少在泄漏修复后），请拍摄快照，执行泄漏行为，返回“稳定”状态，然后拍摄另一个快照。检查泄漏时只需采取一个步骤，稍后会对此进行更多介绍。
使用这两个快照，您可以比较分配和释放的对象 - 我们最感兴趣的是创建了比删除更多对象的情况，理想情况下删除了零。如果您发现N个对象被删除但是N + 1被创建，那么在挖掘之前确保N很小 - 通常只能通过追踪单个对象，追踪它们回到它们实际泄漏的源来修复泄漏，修复它，并再次测量。
一旦你有一个在一个步骤中创建但在该步骤结束时没有被删除的对象（但它应该已经被删除），请使用“Retainers”视图来查看它们仍然保留的原因。这或多或少会向您显示保存它们的对象中的字段以及该保持对象的类型，一直到window或其他一些全局对象。
忽略（）中的任何内容，例如(compiled code)，(array)，(system)，(string)等。我通常忽略dom元素分配（假设您怀疑应用程序代码泄漏，而不是JSNI）。寻找泄漏的少量高级物体，而不是许多低等级的物体，它会使你更接近泄漏源。
PRETTY 中已编译的构造函数和字段的名称通常与原始Java源代码非常接近。所有构造函数都会附加_X，其中X为0,1，等等 - 这是为了区分类型本身。这使得在Constructor列中识别Java类型变得简单，因为它们的名称末尾都有_个。