在Java VisualVM中看不到自己的应用程序方法
我正在尝试分析我的 java 应用程序，只是为了找出花费最多时间的方法。鉴于对 TPTP 的反应不佳，我想我应该尝试一下 Java VisualVM。
这一切看起来使用起来相当简单——除了我似乎无法从中得到任何一致或有用的东西。
我似乎看不到与我自己的代码相关的任何内容 - 我得到的只是一大堆对 java.* 方法之类的调用。
我尝试将检测限制为仅我自己的包，这似乎减少了检测的方法数量，但我似乎仍然没有看到我自己的包。
每次运行时，我都会检测到不同数量的方法，从 10 到 1000 个不等。 我尝试在应用程序启动时进入睡眠状态，以确保在应用程序开始执行任何有趣的操作之前启动并运行 VisualVM，以确保在有趣的内容运行时对其进行分析。
我需要做些什么来确保我的课程得到仪器仪表化吗？ 是否存在时间安排问题？ ..比如，必须等待类加载等？ 我还尝试运行代码的核心两次，以确保所有代码都得到执行...
我只是从 Eclipse 运行一个带有主程序的应用程序。我尝试过使用 Eclipse 集成，以便 VisualVM 在我启动应用程序时启动 - 结果是相同的。 我还尝试将应用程序导出为可运行的应用程序，并从命令行独立运行它，而不是通过 Eclipse - 相同的结果。
我的应用程序不是一个长时间运行的网络应用程序等 - 只是一个主程序，它调用我自己的其他一些类来进行一些处理，然后退出。
如果您对我可能做错的事情提出任何建议，我将不胜感激！ ：）
谢谢 ！
I'm trying to profile my java app, just to find out the methods in which most time is being spent. Given the poor reactions here to TPTP, I thought I'd give Java VisualVM a go.
It all seemed rather simple to use - except that I can't seem to get anything consistent or useful out of it.
I can't seem to see anything relating to MY OWN code - all I get is a whole bunch of calls to things like java.* methods.
I've tried restricting instrumentation to only my own packages, which seems to cut down the number of methods instrumented, but still I don't ever seem to see my own.
Each time I run, I get varying numbers of methods instrumented, ranging from 10's to 1000's.
I've tried putting in a sleep at the start of my app, to make sure I get VisualVM up and running before my app starts to do anything interesting, to make sure it's profiling when the interesting stuff is running.
Is there something I have to do to ensure my classes get instrumented ?
Are there timing issues ? ..like, have to wait for classes to be loaded etc ?
I've also tried running the guts of the code twice, to make sure all the code does get exercised...
I'm just running an app, with a main, from Eclipse. I've tried using the Eclipse integration so that VisualVM starts up when I start the app - results are the same.
I've also tried exporting the app as a runnable app, and running it standalone from the command line, rather than through Eclipse - same result.
My app is not a long running web app etc - just a main that calls some other of my own classes to do some processing, then quits.
I'd be grateful for any advice about what I might be doing wrong ! :)
Thanks !
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我也在与 VisualVM 作斗争，这很遗憾，因为它的用户界面非常棒，而它的分析输出却看起来很可怕。你可以在这里看看我的问题。
Java VisualVM 给出奇怪的结果CPU 分析 - 还有其他人遇到过这种情况吗？
我可以告诉您一些我了解到的有关 VisualVM 及其分析方式的奇怪事情。
VisualVM 似乎正在计算方法内花费的总时间（挂钟时间）。我的应用程序中有一个线程，它启动许多其他线程，然后立即阻塞等待队列上的消息。 VisualVM 不会在探查器中注册此方法，直到其他线程之一发送第一个线程正在等待的消息（当应用程序终止时）。突然间，阻塞方法调用在分析输出中占据主导地位，并被记录为占用了超过 80% 的应用程序时间。
其他探查器（例如 JProfiler 和 Azul 使用的探查器）不会将阻塞线程计为占用探查器时间。这意味着对于性能分析可能不感兴趣（取决于具体情况）的阻塞方法会模糊您对占用 CPU 时间的代码的看法。
当我运行我的分析时，我最终会得到
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run()
模糊我的分析，直到该消息返回到等待线程，然后这两个线程完全共享顶部位置不相关的方法，以及其他各种分析器中未出现的其他无趣的方法。
其次，我认为非常重要的是，方法过滤机制并没有像我预期的那样工作。这意味着我无法过滤掉我现在正在试图追踪的故事内容。
不是一个真正有用的答案。我现在看到的解决方案是付费购买 JProfiler - VisualVM 似乎不值得信赖来完成这项任务。
I too am struggling with VisualVM, which is a shame because its user interface is fantastic while its profiling output seems horrific. You can seem my question here.
Java VisualVM giving bizarre results for CPU profiling - Has anyone else run into this?
I can tell you a couple of odd things that I have learned about VisualVM and the way it seems to do its profiling.
VisualVM appears to be counting the total time spent inside a method (wall-clock time). I have a thread in my application which starts a number of other threads and then immediately blocks waiting for a message on a queue. VisualVM will not register this method in the profiler until one of the other threads sends the message the first thread was waiting for (when the application terminates). Suddenly the blocking method call dominates the profiling output and is recorded as taking up more than 80% of the application time.
Other profilers, such as JProfiler and the one used by Azul do not count a blocked thread as taking up time for the profiler. This means that blocking methods which probably aren't interesting (situation dependant) for performance profiling are obscuring your view of that code that is eating your CPU time.
When I am running my profiling I end up with
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run()
obscuring my profiling right up until that message comes back to the waiting thread and then the top spot is shared between these two totally irrelevant methods, as well as various other uninteresting methods which don't appear on other profilers.
Secondly and I think quite importantly the method filtering mechanism doesn't work as I would have expected. This means that I can't filter out the I am trying to track down what the story is with this right now.
Not a really helpful answer. The solution as I see it right now is to pay for JProfiler - VisualVM just doesn't seem trustworthy for this task.
您可以看看 Appdynamics lite ，它有一个很好的功能，例如业务事务发现，它可以对代码中特定方法的所有调用进行采样。
精简版有很多限制，例如最多 10 分钟采样和最多 30 个业务事务发现。
如果有一个可以做同样事情的免费工具就好了
you could take a look at Appdynamics lite , it's has a nice features such as business transaction discovery which can samples all call made to a specific method in your code.
The lite version has a lot of limitation such as 10min sampling max and 30 business transaction discovery max.
It's would be nice to have a free tools that do the same
我认为这不仅仅是一个学术问题 - 您想看看是否可以使应用程序运行得更快。我想你也不会介意一点“开箱即用”的想法。关于性能有许多流行的想法，但实际上非常模糊。
例如，您说您正在寻找“花费最多时间的方法”。如果你的意思是“自我时间”（实际上是方法中的程序计数器），那么可能很少，除非你有一些强烈的循环。方法通常花费时间调用其他方法，有时执行 I/O。
另一个模糊的想法是，测量方法时间或计算调用次数可以非常清楚地告诉您瓶颈在哪里。瓶颈是特定的代码行，而不是方法，因此即使您大致知道要查找的位置，您仍然在扮演侦探的角色。
这些是一些模糊的想法。 还有很多。让我建议一下应该如何 思考一下，以及这将如何带来结果。
当你最终修复某些问题时，它会减少一定百分比的执行时间，比如（选择一个数字）30%，对吧？ （否则你就没有修复任何东西。）好吧，在那 30% 的时间里，它做了一些事情，一些它不需要做的事情，因为后来你摆脱了它。因此，您不需要进行测量。您确实需要找出它当时在做什么，这样您就知道要摆脱什么。
一个非常简单的方法是随机“暂停”10（或一定次数）次。通过查看调用堆栈和可能的一些数据，了解它正在做什么以及为什么这样做。在其中大约 3 次中，您会看到它正在做一些您可以摆脱的事情。
通过查看显示它的样本百分比，您将知道大约它会节省多少。 近似值就足够了。通过在之前和之后进行秒表，您可以轻松准确地了解节省了多少时间。
那么，就不要停下来。您已经使应用程序变得更快了。再做一次，并且速度更快。迟早你会到达无法再加快速度的地步，但可能不止一步。
I assume this isn't just an academic question - you would like to see if you could make the app run faster. I assume you also wouldn't mind a little "out of the box" thinking. There are many popular ideas about performance that are actually pretty fuzzy.
For example, you say you're looking for "methods in which most time is being spent". If by that you mean "self time" (program counter actually in the method) there is probably very little, unless you've got some intense loops. Methods generally spend time by calling other methods, sometimes doing I/O.
Another fuzzy idea is that measuring method time or counting the number of calls can tell you very much about where bottlenecks are. Bottlenecks are specific lines of code, not methods, so even if you know approximately where to look, you're still playing detective.
So those are a few of the fuzzy ideas. Here is a bunch more. Let me suggest how one should think about it, and how that leads to results.
When you eventually fix something, it will reduce execution time by some percent, like (pick a number) 30%, right? (Otherwise you didn't fix anything.) OK, during that 30% it was doing something, something that it didn't need to do because later you got rid of it. So, you don't need to measure. You do need to find out what it is doing in that time, so you know what to get rid of.
A very simple way is to "pause" it 10 (or some number of) times at random. Understand what it is doing and why, by looking at the call stack and possibly some of the data. On about 3 of those times you will see it doing something you could get rid of.
You will know approximately how much it will save by seeing what percent of samples is showing it. Approximate is good enough. You can easily see exactly how much time is saved by stopwatching it before and after.
Then, don't stop. You've made the app faster. Do it again, and make it faster yet. Sooner or later you get to a point where you can't make it any faster, but it's probably in more than one step.