问题描述
如果某件事使单线程程序需要花费 10 倍的时间，那么您可以在其上运行分析器.您也可以使用暂停"按钮停止它，然后您就会确切地看到它在做什么.
If something is making a single-thread program take, say, 10 times as long as it should, you could run a profiler on it. You could also just halt it with a "pause" button, and you'll see exactly what it's doing.
即使它只比应有的速度慢 10%，如果您多次停止它，不久您就会看到它反复做不必要的事情.通常问题是堆栈中间某处的函数调用并不是真正需要的.这并不能衡量问题，但它确实可以找到问题.
Even if it's only 10% slower than it should be, if you halt it more times, before long you'll see it repeatedly doing the unnecessary thing. Usually the problem is a function call somewhere in the middle of the stack that isn't really needed. This doesn't measure the problem, but it sure does find it.
反对意见主要假设您只取了 1 个样本.如果您是认真的，请选择 10.平均而言，任何导致一定百分比浪费(例如 40%)的代码行都会出现在该部分样本的堆栈中.瓶颈(在单线程代码中)无法隐藏.
The objections mostly assume that you only take 1 sample. If you're serious, take 10. Any line of code causing some percentage of wastage, like 40%, will appear on the stack on that fraction of samples, on average. Bottlenecks (in single-thread code) can't hide from it.
为了表明我的意思，许多反对意见的形式都是样本不足，所以你看到的可能完全是虚假的"——关于机会的模糊想法.但是如果任何可识别的描述，而不仅仅是在例行程序中或例行程序处于活动状态，在 30% 的时间内有效，那么在任何给定样本上看到它的概率是 30%.
To show what I mean, many objections are of the form "there aren't enough samples, so what you see could be entirely spurious" - vague ideas about chance. But if something of any recognizable description, not just being in a routine or the routine being active, is in effect for 30% of the time, then the probability of seeing it on any given sample is 30%.
然后假设只采集了 10 个样本.问题在 10 个样本中出现的次数遵循二项分布，以及看到它 0 次是 0.028.看到它 1 次的概率是 0.121.2 次，概率是 0.233，3 次是 0.267，之后就下降了.由于看到它少于两次的概率是 .028 + .121 = .139，这意味着看到它两次或更多次的概率是 1 - .139 = .861.一般规则是，如果您看到可以在两个或更多样本上修复的内容，则值得修复.
Then suppose only 10 samples are taken. The number of times the problem will be seen in 10 samples follows a binomial distribution, and the probability of seeing it 0 times is .028. The probability of seeing it 1 time is .121. For 2 times, the probability is .233, and for 3 times it is .267, after which it falls off. Since the probability of seeing it less than two times is .028 + .121 = .139, that means the probability of seeing it two or more times is 1 - .139 = .861. The general rule is if you see something you could fix on two or more samples, it is worth fixing.
在这种情况下，在 10 个样本中看到它的几率是 86%.如果您属于 14% 的人没有看到它，请多取一些样本，直到您看到为止.(如果样本数量增加到 20，看到它两次或更多次的机会增加到 99% 以上.)所以它没有被精确测量，但它已经被精确发现，重要的是要明白它很容易是分析器实际上无法找到的东西，例如涉及数据状态的东西，而不是程序计数器.
In this case, the chance of seeing it in 10 samples is 86%. If you're in the 14% who don't see it, just take more samples until you do. (If the number of samples is increased to 20, the chance of seeing it two or more times increases to more than 99%.) So it hasn't been precisely measured, but it has been precisely found, and it's important to understand that it could easily be something that a profiler could not actually find, such as something involving the state of the data, not the program counter.
推荐答案
在 Java 服务器上，快速执行 2-3 次 - 一直是一个巧妙的技巧连续获取所有正在运行的线程的 2-3 个线程转储.只需查看所有线程在哪里"就可以非常快速地确定您的性能问题所在.
On Java servers it's always been a neat trick to do 2-3 quick -s in a row and get 2-3 threaddumps of all running threads. Simply looking at where all the threads "are" may extremely quickly pinpoint where your performance problems are.
与我所知道的任何其他技术相比，这种技术可以在 2 分钟内揭示更多的性能问题.
This technique can reveal more performance problems in 2 minutes than any other technique I know of.
这篇关于可以使用分析器，但为什么不停止程序呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！