在Go团队宣布GC暂停时间少于100微秒后,我很快就调查了这个延迟问题。 我看到的漫长的停顿时间，go tool trace的结果看起来很奇怪，特别是可以看到它们(暂停)是在收集器的并发阶段发生的。 我在go-nuts 邮件列表中提到了这个问题，似乎与这个问题有关，现在已经在Go 1.8中修复了。 我的基准测试又出现了另一个GC暂停问题，这在写本文时依然会出现。 如果没有go tool trace这一工具，我是无法完成调查工作的。
诊断并行问题
假设您已经编写了一个程序，您希望使用所有的CPU，但运行速度比预期的要慢。 这可能是因为您的程序不像您所期望的那样并行运行。 这可能是由于在很多关键路径上串行运行太多，而很多代码原本是可以异步（并行）运行的。
假设我们有一个pub/sub消息总线，我们希望在单个goroutine中运行，以便它可以安全地修改没有加互斥锁的用户map。 请求处理程序将消息写入消息总线队列。 总线从队列中读取消息，在map中查找订阅者，并将消息写入其套接字。 让我们看看单个消息的go tool trace中的内容：
最初的绿色事件是http处理程序读取发布的消息并将其写入消息总线事件队列。 之后，消息总线以单个线程运行 - 第二个绿色事件 - 将消息写给订阅者。
红线显示消息写入订户的套接字的位置。 写入所有订阅者的过程需要多长时间？
问题是四分之一的线程正在闲置。 有没有办法利用它们？ 答案是肯定的 我们不需要同步写入每个用户; 写入可以在单独的goroutine中同时运行。 让我们看看如果我们作出这个变化，会发生什么：
正如你所看到的，写给订阅者消息的过程正在许多goroutines的上同步进行。
但它是否更快？
有趣的是，鉴于我们使用4X的CPU，加速是适合的。 这是因为并行运行代码有更多的开销：启动和停止goroutines; 共享内存以及单独的缓存。 加速的理论上限使得我们无法实现4倍延迟降低：阿姆达尔定律。
实际上，并行运行代码往往效率较低; 特别是在goroutine是非常短暂的，或者他们之间有很多的竞争的情况下。 这是使用此工具的另一个原因：尝试这两种方法，并检查哪种工作最适合您的用例。
什么时候go tool trace不合适？
当然，go tool trace不能解决一切问题。 如果您想跟踪运行缓慢的函数，或者找到大部分CPU时间花费在哪里，这个工具就是不合适的。 为此，您应该使用go tool pprof，它可以显示在每个函数中花费的CPU时间的百分比。 go tool trace更适合于找出程序在一段时间内正在做什么，而不是总体上的开销。 此外，还有“view trace”链接提供的其他可视化功能，这些对于诊断争用问题特别有用。 了解您的程序在理论上的表现（使用老式Big-O分析）也是无可替代的。
结论
希望这篇文章可以让您了解如何使用go tool trace诊断问题。 即使您没有解决具体问题，可视化您的程序是检查程序运行时特性的好方法。 我在这篇文章中使用的例子很简单，但更复杂的程序中的症状应该与此惊人的相似。
附录
这个博客文章给了你一个使用go tool trace的介绍，但你可能希望更深入地深入了解该工具。 目前正在进行的官方go tool trace文档相当稀少。 有一个Google文档更详细。 除此之外，我发现参考源代码是很有用，可以找出go tool trace如何工作：
-
go tool trace 源代码
-
二进制跟踪解析器的源代码
-
trace 源代码
- go tool trace的Web界面来自Catapult项目的跟踪查看器。 该查看器可以从许多跟踪格式生成可视化。 go工具跟踪使用基于JSON的跟踪事件格式。
本文来自：51CTO博客
感谢作者：mob604756f0bbf4
查看原文：Go调优神器trace介绍
相关阅读 >>
更多相关阅读请进入《Go》频道 >>
Go语言101
一个与时俱进的Go编程知识库。
