4 楼正解。正好前段时间我也深入研究了这个问题，并且整理成了一篇博客: https://blog.fanscore.cn/p/34/ 楼主可以参考下，或许对你有帮助😄

@xuletter2021 确实结果一样，不过关闭优化前后打印汇编结果还是有区别的，虽然关闭优化后的 go 出来的函数中还是没有 x++对应的汇编代码（不太能理解的...）。

下面是我的猜测：

在 1.14 之前协程调度是出让式而非抢占式的，如果这段代码在单核机器上运行，就有可能陷入到 for {...}的死循环中而主协程中的代码得不到调度执行，而你 for 循环中加入了 fmt.Pxxx 类的代码就能够使子协程出让执行权。

另外这段代码还有可见性问题，子协程对全局变量的修改，主协程可能是看不到的。

基于上面两个问题的考虑，编译器做出了“错误”优化，导致了你所看到的结果。

你关闭优化跑一遍看看是不是出来了？😂

7 楼回复应该是个很常见的设计，我司 redis 就分为缓存(不需要持久化，所有 key 都有过期时间)与持久化数据两种实例，楼主可以做个参考。如果麻烦的话，可以考虑该场景能否使用 bitmap 来做过滤

@yzbythesea 感谢提醒，突然意识到了

@yzbythesea CPU 操作 L3 cache 上同一个 cacheline 同一位置数据，不加 Lock 就不是原子的，这样理解吗？如果不加 Lock 也是原子的，那 CPU 没必要锁吧

@Jooooooooo lock 与寄存器无关

@ob 好像是会换了，忘记了😄

用 golang 快写完了突然发现还不如用 java 写，方便在安卓上跑😏。