在Java VisualVM中看不到我自己的应用程序方法
我正在尝试描述我的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对于这项任务似乎不值得信任。
你可以看一下Appdynamics lite，它有一个很好的function，比如商业交易发现，它可以对你代码中特定方法的所有调用进行采样。
Lite版本有很多限制，例如最大10分钟采样和最多30个业务事务发现。
拥有同样的免费工具会很高兴
我认为这不仅仅是一个学术问题 – 你想看看你是否可以让应用程序运行得更快。 我想你也不会介意一点“开箱即用”的想法。 关于性能的许多流行观点实际上非常模糊。
例如，你说你正在寻找“花费大部分时间的方法”。 如果你的意思是“自我时间”（程序计数器实际上在方法中）可能很少，除非你有一些强烈的循环。 方法通常通过调用其他方法来花费时间，有时会进行I / O.
另一个模糊的想法是，测量方法时间或计算呼叫次数可以告诉您非常关注瓶颈的位置。 瓶颈是特定的代码行，而不是方法，所以即使你知道在哪里看，你仍然在扮演侦探。
所以这些是一些模糊的想法。 这是一堆更多。 让我建议一个人应该如何思考它，以及它如何导致结果。
当你最终修复某些东西时，它会将执行时间减少几个百分点，比如（选择一个数字）30％，对吧？ （否则你没有修理任何东西。）好的，在那30％的时候它正在做一些事情，它不需要做，因为后来你摆脱它。 所以，你不需要衡量。 你确实需要知道它在那个时候做了什么 ，所以你知道要摆脱什么。
一种非常简单的方法是随机“暂停”10次（或几次）。 通过查看调用堆栈和可能的一些数据，了解它正在做什么以及为什么。 在大约3次中，你会看到它做了你可以摆脱的事情。
通过查看显示百分比的样品，您将了解它将节省多少。 近似值已经足够了。 您可以通过之前和之后的秒表来轻松查看确切节省了多少时间。
然后，不要停止。 你已经让应用程序更快了。 再做一次，让它更快。 迟早你会达到不能让它变得更快的程度，但它可能不止一步。