人们可以使用探查器，但为什么不停止程序呢？
如果某件事情正在做一个单线程程序，比如应该做10倍，那么你可以在其上运行一个分析器。 你也可以用一个“暂停”按钮停下来，你会看到它到底在做什么。
即使它只比应该慢10％，如果你停下更多次，不久你会看到它反复做不必要的事情。 通常这个问题是一个函数调用，在堆栈中间的某个地方并不是真正需要的。 这并不能衡量问题，但它确实能找到它。
编辑：反对意见主要假设你只需要1个样本。 如果你认真的话，就拿10分。任何造成一定百分比的代码的代码行，例如40％，都会平均出现在这部分样本的堆栈上。 瓶颈（单线程代码）无法隐藏它。
编辑：为了表明我的意思，许多反对意见的形式是“没有足够的样本，所以你看到的可能完全是虚假的” - 关于机会的模糊想法。 但是，如果有任何可识别的描述，不仅是例行活动或例行活动，在30％的时间内有效，那么在任何给定样本上看到它的概率是30％。
那么假设只有10个样本被采用。 在10个样本中将出现问题的次数遵循二项分布，并且看到它0次的概率是0.028。 看到它的概率是.121。 2次，概率为.233，3次为.267，之后下降。 由于看不到两次的概率是.028 + .121 = .139，这意味着看到它两次或更多次的概率是1 - .139 = .861。 一般的规则是，如果你看到可以修复两个或更多样本的东西，那么值得修复。
在这种情况下，在10个样本中看到它的机会是86％。 如果你有14％的人没有看到它，那么只需要更多的样本，直到你做到。 （如果样本数量增加到20个，那么看到它的次数增加到99％以上）。所以它没有被精确地测量，但它已被精确地找到，并且了解这一点很重要它可能很容易成为分析器实际找不到的东西，例如涉及数据状态的事情，而不是程序计数器。
在Java服务器上，在一行中执行2-3个快速Ctrl-Breakss并获得所有正在运行的线程的2-3个线程转储总是非常简单。 只需查看“所有”线程的位置，就可以非常快速地查明性能问题的位置。
这种技术可以在2分钟内揭示出比我所知道的任何其他技术更多的性能问题。
因为它有时会起作用，有时会给你完全错误的答案。 一个探查者找到正确答案的记录要好得多，而且通常会更快。
手动执行此操作不能称为“快速”或“有效”，但有几种自动执行此操作的分析工具; 也被称为统计分析。
链接地址: http://www.djcxy.com/p/86755.html上一篇: One could use a profiler, but why not just halt the program?