java代码性能分析器工具
有很多提高代码质量的工具。但有时如果代码不符合代码质量规则，也需要获得性能。是否存在一些开源工具？ 谢谢。
There are many tools for code quality. But sometimes need gain performance also if code is not corresponds to rules of cod quality. Exists some open source tool for this?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
没有可用的工具，但您可以尝试 jVisualVM。
http://download.oracle.com/javase/6 /docs/technotes/tools/share/jvisualvm.html
它通常与您的 jdk 一起提供。 @ C:\Program Files\Java\jdk1.6.0_21\bin
There's no tool for that, but you can try out jVisualVM, however.
http://download.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html
It usually comes with your jdk. @
C:\Program Files\Java\jdk1.6.0_21\bin没有任何工具可以告诉您性能和质量。两者都很难衡量。
您当然可以使用 FindBugs 或 IntelliJ 的 Inspector 之类的工具来检查您的代码，但它们只会查找违反规则的情况。我不知道有什么工具可以在我编写的代码表现不佳时指出。 Java 代码检查器如何知道您的数据库没有索引？
No tool is going to tell you performance and quality. Both are hard to measure.
You can certainly use something like FindBugs or IntelliJ's Inspector to examine your code, but they'll just look for rule violations. I'm not aware of a tool that will point out when I've written code that performs badly. How will a Java code inspector know that your database has no indexes?
关于代码质量我无法回答你。其他人可以。但当你“需要获得性能”时，我宁愿告诉你如何去做，而不是告诉你使用什么工具。
工具是有的，但比工具更重要的是理解你在做什么。
最重要的是要明白，测量并不能告诉您要修复哪些问题才能获得更高的性能；而是告诉您要修复哪些问题。它仅告诉您您取得了多少进步。
提高绩效的方法是找到活动，无论它们是什么，占时间的很大一部分并且可以改进。
测量不是发现。
示例：
我可以手动 对 a 的状态进行采样程序，多次，并且大部分时间都在执行容器类操作，例如获取元素、测试结束条件等。
（这就是发现部分。）
这种情况可能发生在代码中的许多不同位置，因此似乎没有特定的例程会导致花费大量时间。
没有特别的热点或明显的瓶颈。
不存在人们所说的“糟糕的算法”或“缓慢的例程”。
尽管如此，我可以在这几个示例中看到它正在执行容器类操作，并且我可以准确地看到在哪里。
如果我可以用其他达到相同目的的东西替换这些容器类操作，我就可以节省时间。
需要多少时间？大约在我看到这些操作发生的一小部分时间内，这可能相当大。
这样做的真正回报是可能会出现多个问题。
假设问题 A 花费 40% 的时间，B 花费 20%，C 花费 10%，
总时间是 10 秒。
你去找A，最明显的一个。
修复此问题可将时间缩短至约 6 秒。 （加速比 10/6 = 1.67）。
那么问题 B 花费的时间比例更大 (2/6 = .33)，因此更容易通过样本查找。
修复此问题可将时间缩短至 4 秒（加速比 6/4 = 1.5）
那么C就是(1/4 = 25%)并且比以前更容易找到。
删除它会将时间缩短至 3 秒（加速比 4/3 = 1.33）。
总加速系数为 10/3 = 3.33。
您可以将其视为每个加速比的复合乘积：10/6 * 6/4 * 4/3 = 10/3。
现在我在这里处理数字，但这些都不必是本地化代码片段所花费的时间的度量。
它们只是通过描述程序正在执行的少量详细样本中所发生的情况而得出的粗略估计。
样本并不真正关心测量。
他们关心暴露问题。
I can't answer you regarding code quality. Others can. But when you "need gain performance", I would rather tell you how to do it than tell you what tools to use.
There are tools, but more important than tools is understanding what you're doing.
The most important is to understand that measuring doesn't tell you what to fix to get higher performance; it only tells you how much improvement you got.
The way to improve performance is to find activities, whatever they are, that account for a significant fraction of time and can be improved.
Measuring is not finding.
Example:
I can manually sample the state of a program, several times, and see it much of the time doing container class manipulations, like fetching elements, testing for end conditions, etc.
(That's the finding part.)
This can be happening in many different places in the code, so no particular routine appears to be causing a large fraction of time to be spent.
There is no particular hotspot or obvious bottleneck.
There is no "bad algorithm" or "slow routine", the kinds of thing people say they look for.
Nevertheless, I can see in those few samples that it is doing container class operations, and I can see exactly where.
If I can replace those container class operations with something else that accomplishes the same purpose, I can save time.
How much time? Up to roughly the fraction of time I saw those operations happening, and that can be quite large.
The real payoff for doing this is there can be multiple issues.
Suppose issue A costs 40% of the time, B costs 20%, and C costs 10%,
and the total time is, say, 10 seconds.
You go after A, the most obvious one.
Fixing it reduces time to about 6 seconds. (Speedup 10/6 = 1.67).
Then problem B takes a larger percent of time (2/6 = .33) so it is easier to find with samples.
Fixing it reduces time to 4 seconds (Speedup 6/4 = 1.5)
Then C is (1/4 = 25%) and is much easier to find than before.
Removing it reduces time to 3 seconds (Speedup 4/3 = 1.33).
The total speedup factor is 10/3 = 3.33.
You can look at it as the compounded product of each speedup: 10/6 * 6/4 * 4/3 = 10/3.
Now I'm dealing in numbers here, but none of these had to be measurements of time spent in localized pieces of code.
They were just rough estimates gotten from describing what was happening in a small number of detailed samples of what the program was doing.
The samples aren't really concerned with measuring.
They are concerned with exposing the problems.