我正在尝试描述我的java应用程序,只是为了找出花费大部分时间的方法.鉴于TPTP的反应不佳,我以为我会给Java VisualVM一个机会.
这一切似乎都很简单 - 除了我似乎无法从中得到任何一致或有用的东西.
我似乎无法看到任何与我自己的代码有关的内容 - 我得到的是对java.*方法等一大堆调用.
我已经尝试将检测限制在我自己的包中,这似乎减少了检测方法的数量,但我似乎还没有看到自己的方法.
每次运行时,我都会获得不同数量的方法,范围从10到1000.我已经尝试在我的应用程序启动时进入睡眠状态,以确保在应用程序开始执行任何有趣操作之前启动并运行VisualVM,以确保在有趣的内容运行时进行分析.
我有什么必须做的,以确保我的课程得到检验吗？有时间问题吗？.. like,必须等待类加载等？我也尝试过两次运行代码的内核,以确保所有代码都得到了运行...
我刚刚从Eclipse运行一个带有main的应用程序.我尝试使用Eclipse集成,以便在启动应用程序时VisualVM启动 - 结果是相同的.我也尝试将应用程序导出为可运行的应用程序,并从命令行独立运行它,而不是通过Eclipse运行 - 结果相同.
我的应用程序不是一个长期运行的Web应用程序等 - 只是一个主要调用我自己的其他类来进行一些处理,然后退出.
对于我可能做错的任何建议,我将不胜感激!:)
谢谢 !
我也在与VisualVM挣扎,这是一个耻辱,因为它的用户界面非常棒,而其分析输出似乎很可怕.你可以在这里看到我的问题.
Java VisualVM为CPU分析提供了奇怪的结果 - 还有其他人遇到过这种情况吗？
我可以告诉你一些关于VisualVM的奇怪的事情以及它看起来如何进行分析.
VisualVM似乎在计算方法内的总时间(挂钟时间).我的应用程序中有一个线程,它启动了许多其他线程,然后立即阻塞等待队列中的消息.VisualVM不会在探查器中注册此方法,直到其他线程之一发送第一个线程正在等待的消息(当应用程序终止时).突然,阻塞方法调用占据了分析输出,并被记录为占用应用程序时间的80%以上.
其他分析器,例如JProfiler和Azul使用的分析器不会将阻塞的线程计为占用分析器的时间.这意味着对性能分析可能不感兴趣(依赖于情境)的阻塞方法会掩盖您对占用CPU时间的代码的看法.
当我运行我的分析时,我最终得到了
sun.rmi.transport.tcp.TCPTransport $ ConnectionHandler.run()
模糊我的分析直到该消息回到等待的线程,然后在这两个完全不相关的方法之间共享顶部位置,以及在其他分析器上不出现的各种其他无趣的方法.
其次,我认为非常重要的是方法过滤机制不能像我预期的那样工作.这意味着我无法过滤掉我现在试图追踪故事的内容.
不是一个非常有用的答案.我现在看到的解决方案是支付JProfiler - VisualVM对于这项任务似乎不值得信任.
我认为这不仅仅是一个学术问题 - 您想看看是否可以使应用程序运行得更快。我想你也不会介意一点“开箱即用”的想法。关于性能有许多流行的想法，但实际上非常模糊。
例如，您说您正在寻找“花费最多时间的方法”。如果你的意思是“自时间”（实际上是方法中的程序计数器），那么可能很少，除非你有一些强烈的循环。方法通常花费时间调用其他方法，有时执行 I/O。
另一个模糊的想法是，测量方法时间或计算调用次数可以非常清楚地告诉您瓶颈在哪里。瓶颈是特定的代码行，而不是方法，因此即使您大致知道要查找的位置，您仍然在扮演侦探的角色。
这些是一些模糊的想法。这里还有更多。让我建议人们应该如何思考它，以及如何产生结果。
当你最终修复某些问题时，它会减少一定百分比的执行时间，比如（选择一个数字）30%，对吧？（否则你就没有修复任何东西。）好吧，在那 30% 的时间里，它做了一些事情，一些它不需要做的事情，因为后来你摆脱了它。所以，你不需要测量。你确实需要找出它当时在做什么，这样你就知道要摆脱什么。
一个非常简单的方法是随机“暂停”10（或一定次数）次。通过查看调用堆栈和可能的一些数据，了解它正在做什么以及为什么这样做。大约有 3 次你会看到它在做一些你可以摆脱的事情。
通过查看显示它的样本百分比，您将大致了解它会节省多少费用。近似值就足够了。通过在之前和之后进行秒表，您可以轻松准确地了解节省了多少时间。
那么，不要停下来。您已经使应用程序变得更快了。再做一次，并且速度更快。迟早你会到达无法再加快速度的地步，但可能不止一步。
| 归档时间： |
|
| 查看次数： |
4429 次 |
| 最近记录： |