@JZWen #7 感兴趣的话可以看看这本书的前两章，作者直接给出了软件架构是什么、以及软件架构的重要性。微信读书里就有。

我理想中的软件架构师应该是整洁架构之道中所描述的那样：
能够设计出优秀的软件架构，增加开发者的生产力。能够为了软件的可维护性与需求方或其他任何没有能力评估软件架构能力的团队进行抗争。
保证我作为一个开发者，能够始终在一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构中工作。

粗略看了一下，这是《 DevOps 实践指南》的读书笔记吧。有时间还是建议看原书，原书中有大量的理论来补充说明这些观点。

建议举报，国家反诈中心 app，直接选择那条短信就能举报

我最近膝盖也有些不舒服，水泥马路太硬了，各位还是要注意一下

如果还想看大夫，最好是去北京武警总医院挂李志强医生的号，北京的医院挂号有专门的网站，号不算太抢手，提前几天是能挂上的。

平时可以去《白白手拉手》这个论坛多看一看，也可以跟其他病友聊一聊。这个病是有一定概率治愈的，尤其是前期。https://www.bbsls.net/forum.php

我大概四五年前得过，然后用了半年治好了。

白癜风最主要的治疗手段是照 308 激光。有条件一定要照这个，这个机器很贵，大部分医院都没有。如果所在城市没有的话可能就要去省会城市的医院。

@lesismal #43 我明白你的意思，我现在已经不再认为我的示例代码中的顺序是一致的了，chan 也只是将接收器 /发送器标记为下一个要运行的 goroutine，但不能保证其一定是下一个运行的。哪怕是在我的示例代码中尽可能少的影响因素也是一样，因为还有抢占式调度。
我现在的结论也只是从 chan 的运行逻辑上解释两两输出的可能性，但 chan 不能必然导致两两输出。

其实结论已经不重要了，谢谢你帮我认识到我对于 go runtime 理解的不足。

@lesismal #39 抢占式调度我的理解之前确实有些问题，现在我也知道我的示例代码也会被抢占了。

我现在已经没有纠结对错了。只是我认为的是 chan 的队列机制导致的两两输出，然后你说 runtime 中可能会有其他可能对顺序造成影响，所以出现乱序。但我还是没明白为什么这就说明我的结论不能解释两两输出的现象了。

@lesismal #35 所以你也不是认为 print 影响的调度，而是说 print 前对 chan 操作并不能固定顺序，因为 runtime 有其他更多的可能性会对顺序造成影响。

我之前大部分的时间都是思考为什么两两输出，没有考虑到更多其他变量对顺序造成的影响。再加上我之前的表述可能也有问题。
所以我们的结论并不是矛盾的

@lesismal #33 我这里的代码确实有些问题，因为我要调试 chan 源码部分，所以尽量屏蔽了其他的调用，导致我没有发现乱序的存在，”绝对是连续两次“这个结论过于武断了。很抱歉。

不过去掉偶尔存在的乱序问题，连续两次的输出可以认为是 chan 等待队列机制的作用吗？

@lesismal #31 你好，我又调试研究了一下，我认为我们之间的主要在于调用的 print 函数不同。我在我的示例代码（ https://play.golang.org/p/wmU0fpTt5uf ）中尽量屏蔽了其他可能对输出顺序造成影响的函数，所以使用了 print 语句，而不是楼主原有的 fmt.Printf 函数。
结果还是连续两次的输出，而不是交替的输出，并且通过对 chan 源码的调试，能证明确实有连续两次的调用。这是否足以说明不是 print 的影响造成的连续两次输出。

关于抢占式调度是我原来理解错误，我原来想当然的认为在 goroutine 能够主动出让调度的情况下，sysmon 并不会抢占。然而阻塞并不会刷新 goroutine 的运行时间，还是会被抢占。
不过我认为这并不会影响我上面的结论。

ps: 我在我的示例代码中也使用 fmt.Print 函数后，发现确实经常输出乱序的结果，这应该是其内部机制造成的，但我没有仔细研究。

@lesismal #28 接受批评，我有时间会再去学习研究 printf 是否会影响顺序，以及抢占式调度是否会发生的问题。

肌肉酸疼没什么问题，膝盖关节疼就有问题了，需要注意一下

@lesismal #25 #19 的日志与楼主贴出的连续执行两次的日志没有关系，楼主也没有问为什么在多次连续的操作中会有一次乱序。你引入了这个结果，又没有自己说明。或者说你认为这个结果是 fmt.Printf 函数导致，但这跟我说的有什么冲突吗？我为什么要解释这个问题，我给出的示例代码没有出现乱序的现象。

你的论证是什么？你看了 fmt.Printf 函数的源码，发现确实有能主动触发调度的操作吗？还是根据现象推断的？