我在工作桌面上运行了多个流程几天。今天早上，所有这些过程几乎都停止了工作。经过一些调试后，我发现执行time.Sleep之后，执行流只会卡在那儿而永不醒来。因此，当团队中的每个人都吓坏了时，我只是重新启动了Windows 10 PC，人们认为这是一次绝望的重新启动。幸运的是，我猜想问题在重启耸肩之后就消失了。
我想知道是否有人曾经历过此事，或者不知道可能是什么原因？我在另一篇文章中读到，time.Sleep基本上是通过计算操作系统中的绝对时间来计划执行恢复的时间，但是AFAIK的日期/时间设置从未更改。
我意识到这可能很难诊断，但是我从未在非Windows计算机上遇到过此问题。不用说我讨厌Windows并偏向Unix，但我承诺如果有人可以给我一些有关此错误的合理解释，我将给Windows一个机会。
答案 0 :(得分：2)
（出于以下原因，这不会是一个答案-而是一些提示。）
问题缺乏关键的背景。
桌面是否已进入睡眠状态（或处于休眠状态）并被唤醒-因此您希望该过程从中断的地方继续进行？
您确定相关的goroutine停留在time.Sleep中吗？
最感兴趣的是最后一个问题，但它仍然无法回答。
为此，您需要使用一些调试方法来武装长时间运行的进程。
最简单但可行的方法是，以一种有趣的方式杀死，从而粗暴地杀死您的进程：向其发送SIGQUIT信号，Go运行时将使该进程崩溃—将活动goroutine的堆栈跟踪信息转储到进程的stderr。
（当然，这意味着您没有在进程的代码中捕获此信号。）
Windows没有信号，但是 Ctrl -中断 should work类似于 Ctrl - \ 在Unix终端中，通常将SIGQUIT发送到前台进程。
可以通过调整GOTRACEBACK环境变量来增强此方法-引用the docs：
GOTRACEBACK变量控制在以下情况下生成的输出量： 由于无法恢复的恐慌或意外情况，Go程序失败 运行时条件。默认情况下，失败会为 当前的goroutine，消除了运行时系统内部的功能， 然后退出，并显示退出代码2。失败将显示堆栈跟踪信息 如果没有当前goroutine或失败是所有goroutine 在运行时内部。GOTRACEBACK=none省略了goroutine堆栈 完全跟踪。GOTRACEBACK=single（默认）的行为与描述的相同 以上。GOTRACEBACK=all为所有用户创建的堆栈添加跟踪 goroutines。GOTRACEBACK=system类似于“全部”，但为 运行时函数，并显示由内部创建的goroutine 运行。GOTRACEBACK=crash类似于“系统”，但在 特定于操作系统的方式，而不是退出。例如，在 在Unix系统上，崩溃引发SIGABRT以触发核心转储。对于 历史原因，GOTRACEBACK设置0、1和2是同义词 分别为无，全部和系统。runtime/debug软件包的SetTraceback功能可增加运行时的输出量 时间，但不能将其减少到低于 环境变量。看到 https://golang.org/pkg/runtime/debug/#SetTraceback。
因此，如果您要使用GOTRACEBACK=crash运行进程，则不仅可以收集堆栈跟踪信息，还可以收集转储文件（如今，在典型的基于Linux的系统上，这需要在{{ 1}}）。
不幸的是，在Windows上它几乎 在那里，但是not yet;还有一些值得关注的地方。
更硬性的方法是，当您使用自定义实现的方式要求进行处理时，使您的进程转储goroutine的堆栈-https://golang.org/pkg/runtime/和https://golang.org/pkg/runtime/debug包含执行此操作所需的所有内容。
您可能会看看https://golang.org/pkg/net/http/pprof/的实现方式和/或立即使用它。