@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 函数的源码，发现确实有能主动触发调度的操作吗？还是根据现象推断的？

@lesismal #22 我在 15 层的回复也解释过是设置为下一个要唤醒的 goroutine 。同时我认为你在 12 楼的解释将其认为是 printf 造成的调度我不认可，你也没有给出论证。我还是认为 chan 本身的特性所导致的，这个特性就是 chan 的等待队列可直接传值的操作。

@lesismal #20 如果考虑到其他调度的话是超出讨论范围了，我只是思考了为什么会有连续两个输出而不是交替输出的问题。我的代码中也屏蔽了其他任何可能调度的影响。

其实在真正的使用中是要避免依赖这种 runtime 的执行顺序，Go 文档中也不会提及内部的实现是有接收器 /发送器队列的。

@lesismal #16
以 recv 举例，for 因为阻塞被断开了：
第一次执行 0.5，阻塞。
回来后继续执行 0.5 （输出），然后执行完整的 1 个 for （输出），然后再次执行 0.5，阻塞。

虽然 call recv 函数的次数是 2，但因为阻塞，for 中的整体逻辑被分割了。

@lesismal #16 你可以看下我的输出日志，连续两个的 print 中，第一个永远是上一次 for 的继续执行，而不是这一次 for 的两次执行中的打印，所以我说“但输出和访问 send 和 recv 函数的顺序是不一样的，因为存在阻塞”，因为两次中的后一次，要等待阻塞结束后来后才能输出。只是表现形式是连续两次。

这里只要 runtime.GOMAXPROCS 设置为 1，那么除了第一次和最后一次（如果存在的话）外，其他的输出绝对是连续两次的，这与 goroutine 的调度没有关系，因为只有一个 p 在运行。
也与抢占式调度没有关系，因为每次都是依靠 chan 进行手动调度。

@cmdOptionKana #7 如果要用玩游戏对比，应该是有新游戏的出现，需要高性能，提高了显卡的价格。这是我认为价值的基点，有市场，有需求，那些人买显卡是为了玩到新游戏。虽然我不是专业的经济学研究者，但这符合我的逻辑。

可是虚拟货币在我看来更像是郁金香泡沫，把比特币换成郁金香，显卡换成适合培育郁金香的土，也没有什么区别。

玩游戏买显卡是为了用，而不是为了买到后想着提高价格再卖出去。

对于我而言，我厌恶的是矿工们将算力用于无意义的行为上。这可能是由于我不了解虚拟货币共识的价值，不明白为什么基于共识而不是基于现实就能产生价值...

这主要是由于 channel 的内部实现机制，channel 的 send 或 recv 操作在发现有等待中的接收器（ chan.recvq ）或发送器（ chan.sendq ）时，会直接把值交给它，并向其设置为下一个要唤醒的 goroutine 。然后在循环中再次的操作，才会阻塞，阻塞时自己也会在相应的等待队列中。所以每次的 send 或 recv 操作，都会执行两次，输出的形式也是连着输出，但输出和访问 send 和 recv 函数的顺序是不一样的，因为存在阻塞。

这个是比较直观一些的代码，因为调度不一致，所以我用 runtime.Gosched() 方法保证一定是 recv 的 goroutine 先运行。
https://play.golang.org/p/wmU0fpTt5uf

这里是带有 Go Channel 源码部分的一些打印：

------------- call unbuffered channel recv ---------------- # 接收器先启动，调用 recv 时阻塞并将自己放入队列
------------- call unbuffered channel send ---------------- # 发送器启动，调用 send，并尝试获取
------------- unbuffered channel send ---------------- # 发现队列中有可用的接收器，尝试直接发送
------------- unbuffered channel sent ---------------- # 成功
written0 #继续向下执行，打印 witten
------------- call unbuffered channel send ---------------- # for 执行到第二次，调用 send，阻塞了
received # 发送器在发送时，直接修改了接收器的执行栈，所以接收器不需要从阻塞那里再次运行，而是得到值，并继续向下执行，也就是打印
------------- call unbuffered channel recv ---------------- # for 执行到第二次，调用 recv
------------- unbuffered channel receive ---------------- # 发现队列中有可用的发送器，所以直接取值
------------- unbuffered channel received ---------------- # 成功
received # 继续向下执行，打印 received
------------- call unbuffered channel recv ---------------- # 再次调用 recv，但此时队列已经空了，所以阻塞
written1 # 此处的打印是上面被阻塞的 send 的向下执行，同样发送器也不需要在阻塞处继续执行，而是向下执行，所以直接打印第二次循环的输出
------------- call unbuffered channel send ---------------- # 下面就不用详细讲了，都是一样的流程
------------- unbuffered channel send ----------------
------------- unbuffered channel sent ----------------
written2
------------- call unbuffered channel send ----------------
received
------------- call unbuffered channel recv ----------------
------------- unbuffered channel receive ----------------
------------- unbuffered channel received ----------------
received
------------- call unbuffered channel recv ----------------
written3
------------- call unbuffered channel send ----------------
------------- unbuffered channel send ----------------
------------- unbuffered channel sent ----------------
written4
received
------------- call unbuffered channel recv ----------------

如果想看源码来调试或了解，推荐看这里： https://golang.design/under-the-hood/zh-cn/part1basic/ch03lang/chan/

看过你的博客文章《译：做一家不开会，不设置 deadline，甚至没有全职员工的公司》，想请问下进展如何，这样真的有可行性吗

DDD 的副标题就是：软件核心复杂性应对之道。很多时候软件的复杂性不在于软件技术的使用，而是业务的复杂性，所以 DDD 就聚焦于业务逻辑，通过各种方法来为业务建模，来保证不会因为业务的巨大复杂性而陷入困境。
我一直认为我没学会 DDD 的原因之一就是还没遇到过于复杂的业务逻辑......

@aboat365 #79 是的，现在 JWT 使用场景更多了，但也不能说 JWT 替代了 session，哪怕是 OIDC 中也不是用 JWT 格式作为 accesstoken 。服务端在有相应的场景下，该存的状态还是没少，其实是等同于 session 机制，只不过是原来 session + cookie 被现在的流行的认证格式取代了。

想起了我几年前的提问帖子......《请教各位一个问题, 为什么 session 机制没有被 JWT 所取代?》

现在 JWT 有了更多的使用场景，其实已经有很大的发展了。