互斥分析器记录了锁定路径上的争用情况，因此在分析中的所有堆栈跟踪都表现为 Unlock 调用，而不是更直观地预期的 Lock 调用[1]。
这可能会引起困惑。Here's 是一个关于堆栈溢出的问题，我今天亲自回答了一个关于这个问题的问题。
我们自己的 runtime/pprof 文档对此没有任何说明(事实上，我们为互斥分析器拥有的完整文档是“互斥锁 - 持有者的堆栈跟踪”)。这显然应该加以扩展。
在线的其他地方有一些文档。例如，@felixge 的阻塞分析文档提到了这个属性。
与 #14689 相关。
[1] 这也意味着不可能直接告诉哪些 Lock 调用最热。实际上，我怀疑这不是一个问题，因为典型的互斥锁使用具有每个唯一的 Unlock 调用的唯一 Lock 调用。如果这是一个问题，我们可以将记录的堆栈跟踪移动到 Lockhere (以牺牲在 sudog 中存储堆栈直到我们可以在 Unlock 中记录事件的空间)。
8条答案
按热度按时间pjngdqdw1#
cc @mknyszek
ukxgm1gy2#
我认为可以公平地说，所有内置的分析器都可以使用一些关于它们产生的数据类型、涉及的采样等的额外文档。我很乐意为这个问题提供补丁，但我目前仍然对最佳的文档位置有些不确定。许多分析器在不同的地方暴露了各种API和旋钮，所以并不总是有一个自然的地方放置这些信息。也许Diagnostics文档是正确的位置？我在想每个分析器可以使用那里的一个部分，然后所有的API文档都可以更新，引导人们走向正确的方向？
tkclm6bt3#
上述脚注[1]的逆操作是，在
Unlock中记录可能显示哪些锁持有者最成问题(即，他们持有锁的时间过长)。这可能是一个非常有用的属性。例如，考虑一个快速的“getter”方法，它只持有锁足够长的时间来读取单个字段，而不是一个更新方法，它持有锁的时间非常长。您可能有很高的访问“getters”的速率，而不会引起显著的争用，但对“update”的调用率较低会阻塞所有“getters”。在我看来，在这种情况下，更有可能看到在“update”中的Unlock的结果，而不是在“getters”上的Lock的结果。bd1hkmkf4#
@prattmic也很好地指出了解锁与锁定之间的权衡。我发现报告解锁非常不自然和令人困惑，但你提出了一个很好的观点，即它可能更好。
oyjwcjzk5#
关于如何放置这类文档的最佳位置，因为有几个相关的包，这是一个很好的问题。我最初认为
runtime/pprof是最自然的选择，但后来我甚至没有意识到 Diagnostics 页面的存在(发现性问题，有人吗？😄)。我看到的主要可能性有：
runtime文档：包含一些用于性能分析的控件，但不是主要界面，所以我认为这不太好。runtime/pprof文档：通常是性能分析的主要界面。我现在可能稍微倾向于 golang.org。无论最终结果如何，我认为我们应该：
其他人，如 @bcmills 和 @jayconrod 可能对这种文档的最佳位置有更多想法？
r3i60tvu6#
我认为将这个放在
https://golang.org/doc/下面，并从诊断页面和runtime/pprof包文档中链接到它是有意义的。它可以托管在https://github.com/golang/website/tree/master/_content/doc中。mdfafbf17#
cc @pjweinb
v6ylcynt8#
https://go.dev/cl/547057提到了这个问题：
runtime/pprof: document block and mutex profiles