调试/运行go程序冻结windows计算机

Question

我正面临一个奇怪的问题，我正在努力找到原因。我有一个go程序，它迭代了许多EC2实例，并为它们获取CPU利用率指标，然后迭代到平均值并打印出一个报告。外部端点有几个循环和几个呼叫（Prometheus，Influx，Cloudwatch，AWS API等）。

我面临的问题是，当我在Visual Studio Code中调试应用程序时，有时会随机地导致我的整个计算机冻结。随机=我无法关联任何似乎导致问题或删除问题的特定更改或触发点。冻结=完全冻结机器（没有鼠标操作，没有键盘，除了强制循环之外不能做任何事情）。

我认为它源于我的golang代码，原因如下： 现在冻结已经发生了大约7次，并且只有在我运行代码时才会发生。 2.当我尝试通过调试器运行代码时（每次重启后），冻结一致地重现

然而，相反，单步执行导致冻结的代码，根本不会重现冻结。

最后，我在Visual Studio环境之外运行代码（post build，作为exe）。经过几次没有任何事故，我遇到了一种改进的冻结形式。在这种情况下，我的电脑没有完全冻结。鼠标指针仍然响应，但其他一切都冻结了（没有键盘，没有ctrl-alt-del），我仍然不得不强制重启。

我记录了我的代码，并且在冻结发生时我发现了一个重复的模式。我的日志模式是这样的4行的重复模式（其中i的值表示迭代计数）：

2017/05/09 17:31:28 Computing avg & normalized util for i=506, s=0, i-s=506, i-beg=506, len(avgs)=4049, len(ut.Values)=3278, pre time-point avg: 0.000000, pre overall avg: 0.111194, metricValue: 0.084000
2017/05/09 17:31:28 
Running avg for time-point raw avg:0.084000, normalized avg:5.376000
Overall running avg=> raw:0.111140, normalized:7.112963 2017/05/09

现在，在这种情况下，当冻结发生时，日志的最后一个条目包括这个未完成的片段，后面跟着一大串NUL字符，就像这样（截断的NUL数量）：

17:31:28 Computing avg & normalized util for i=507, s=0, i-s=507, i-beg=507, len(avgs)=4049, len(ut.Values)=3278, pre time-point avg: 0.000000, pre overall avg: 0.111140, metricValue: 0.104000 
2017/05/09 17:31:28
Running avg for time-point raw avg:0.104000, normalized avg:6.656000 Overall running avg=> raw:0.111126, normalNULNULNULNULNUL

在这种特殊情况下，它发生在第507次迭代中。在之前的运行中，当冻结发生时，NUL以不同的迭代打印。并且，代码已经成功处理了之前的5000次迭代。

因为冻结，冻结了我，我无法最终调试代码。我在Windows 7 Pro 64位上使用go 1.7.4运行它，而我的笔记本电脑是一台功能相当强大的机器，具有16GB RAM和Intel i7。当冻结重复时我没有打开很多程序（就像今天我必须给我的机器重启3次），因此在随后的冻结期间的资源使用量将是最小的。

我将非常感谢您对我如何调试此问题的任何帮助或指示。

- 编辑05/10 / 2017--
发布此问题后，我又冻结了一些。一些新的观察：
1.作为二进制文件运行（与使用Visual Studio代码进行调试一样）也会产生完全冻结 2.有时冻结是瞬间的（一切似乎一直在移动，然后突然一切都冻结），而在其他时候冻结发展缓慢（首先命令窗口中的光标冻结，然后工具提示冻结，然后窗户不能切换，鼠标冻结，最后任务管理器冻结 3.我现在能够重现冻结（运行某些工作负载总是导致冻结，尽管在不同的时间点/代码）。产生冻结的所有工作负载都具有比其他工作负载更多的迭代。我的逻辑处理一个容器集合，其中每个容器本身是一个实例集合，每个实例都有一组指标，这些工作负载都有更多的顶级集合。

上述观察结果很可能成为与资源相关的问题。机器冻结后，我能够得到一些任务管理器的照片。并且，任务管理器和资源管理器不指示任何不利的资源利用率。