业务层也好理解，没有一种语言保证在多线程对一个变量a执行a++ 100次，最后结果一定是100。如果你理解内存屏障，适当位置插入读写屏障能保证最后结果是对的。而不是无脑的使用mutex或者atomic。
【 在 freyoneby 的大作中提到: 】
: 我是觉得像cpu之间的cache同步，不应该做业务的去关心，架构设计上应该保证，cpu切换读取相同内存的时候，能够自动让这部分cache先回写，大部分都是各自领域专业的软件开发，还要关心这种东西，说明目前架构设计，编译器设计都不完美
: 【 在 leving 的大作中提到: 】
: : 这个问题可以简化版理解一下：比如x86平台下的2核处理器。对于head++，假如cpu核a执行了head++，那cpu核b此时的head怎么才能看到这个正确值？x86平台使用的是mesi做cpu间数据同步，但是mesi做cpu间同步是有缺陷的。cpu的核a需要等待cpu核b的明确返回消息才能执行下一步，如果这个时候核b执行死循环，此时的cpu核a也在忙等同步消息返回。为了解决这种缺陷，引入了invalid queue和store buffer。cpu核a通知核b的信息，自己更改的head++放入store buffer，核心b的head失效信息放在invalid queue中。此时核a缓存中的head和核b中的值都不是正确的值，写屏障的意思是：核a把store buffer的值刷新到缓存中，这个时候取值才是正确的；读屏障的意思是：核b取head的值，会检查invalid queue，如果发现缓存失效，去内存中取正确的值。他们的表现都是cpu指令乱序执行，本质是硬件层面引入mesi导致硬件层面不能保证指令信息同步，需要软件层面的内存屏障来保证。

- 来自「最水木 for iPhone X」
--
FROM 183.192.23.*