然后看看标准C++基金会（https://isocpp.org）怎么说的（官方链接）：
由以下博客的分析可以知道，内核的kfifo使用了很多技巧以实现其高效性。比如，通过限定写入的数据不能溢出和内存屏障实现在单线程写单线程读的情况下不使用锁。因为锁是使用在共享资源可能存在冲突的情况下。还用设置buffer缓冲区的大小为2的幂次方，以简化求模运算，这样求模运算就演变为 (fifo->in & (fifo->size – 1))。通过使用unsigned int为kfifo的下标，可以不用考虑每次下标超过size时对下表进行取模运算赋值，这里使用到了无符号整数的溢出回零的特性。由于指示读写指针的下标一直在增加，没有进行取模运算，知道其溢出，在这种情况下写满和读完就是不一样的标志，写满是两者指针之差为fifo->size，读完的标志是两者指针相等。后面有一篇博客还介绍了VxWorks下的环形缓冲区的实现机制点击打开链接，从而可以看出linux下的fifo的灵巧性和高效性。
" 处理器内存屏障 “ 针对 ” CPU " 之间的内存访问乱序 和 CPU 访问外设乱序 问题 ;
我们都知道，带有优化的编译器，会尝试重新排序汇编指令，以提高程序的执行速度。但是，当在处理同步问题的时候，重新排序的指令应该被避免。因为重新排序可能会打乱我们之前想要的同步效果。其实，所有的同步原语都可以充当优化和内存屏障。
本文讲述了Linux中RCU（Read-Copy-Update）机制在内存管理中的重要作用，以及如何在Linux内核中实现和管理RCU。在Linux内核中，RCU用于在多个进程共享相同内存空间时，保证这些进程之间的数据一致性。本文首先介绍了RCU的基本原理，然后逐步深入介绍了Linux内核中RCU的实现细节。最后，通过一个具体的例子，展示了如何在Linux内核中实现一个简单的RCU。
内存屏障 , 又称为 " 屏障指令 " , 用于保证 " 编译器 “ 或 ” CPU “ 访问内存时 , 保证 按照顺序执行 , 即 ” 内存屏障 之前 “ 的指令 与 ” 内存屏障 之后 " 的指令 不会犹豫 编译器 和 CPU 优化导致 顺序混乱 ;
应用程序中存在多个线程会带来有关从多个执行线程安全访问资源的潜在问题。修改同一资源的两个线程可能会以意想不到的方式相互干扰。例如，一个线程可能会覆盖另一个线程的更改或将应用程序置于未知且可能无效的状态。如果幸运的话，损坏的资源可能会导致明显的性能问题或崩溃，这些问题相对容易追踪和修复。但是，如果您不走运，损坏可能会导致微妙的错误，这些错误直到很久以后才会显现出来，或者这些错误可能需要对您的基本编码假设进行重大检查。
现在大多数现代计算机为了提高性能而采取乱序执行，这可能会导致程序运行不符合我们预期，内存屏障就是一类同步屏障指令，是CPU或者编译器在对内存随机访问的操作中的一个同步点，只有在此点之前的所有读写操作都执行后才可以执行此点之后的操作。
编译器优化乱序和CPU执行乱序的问题可以分别使用优化屏障 (Optimization Barrier)和内存屏障 (Memory Barrier)这两个机制来解决：
相信很多 Java 开发，都使用了 Java 的各种并发同步机制，例如 volatile，synchronized 以及 Lock 等等。也有很多人读过 JSR 第十七章 Threads and Locks（地址：https://docs.oracle.com/javase/specs/jls/se17/html/jls-17.html），其中包括同步、Wait/Notify、Sleep & Yield 以及内存模型等等做了很多规范讲解。但是也相信大多数人和我一样，第一次读的时候，感觉就是在看热闹，看完了只是知道他是这么规定的，但是为啥要这么规定，不这么规定会怎么样，并没有很清晰的认识。同时，结合 Hotspot 的实现，以及针对 Hotspot 的源码的解读，我们甚至还会发现，由于 javac 的静态代码编译优化以及 C1、C2 的 JIT 编译优化，导致最后代码的表现与我们的从规范上理解出代码可能的表现是不太一致的。并且，这种不一致，导致我们在学习 Java 内存模型（JMM，Java Memory Model），理解 Java 内存模型设计的时候，如果想通过实际的代码去试，结果是与自己本来可能正确的理解被带偏了，导致误解。 我本人也是不断地尝试理解 Java 内存模型，重读 JLS 以及各路大神的分析。这个系列，会梳理我个人在阅读这些规范以及分析还有通过 jcstress 做的一些实验而得出的一些理解，希望对于大家对 Java 9 之后的 Java 内存模型以及 API 抽象的理解有所帮助。但是，还是强调一点，内存模型的设计，出发点是让大家可以不用关心底层而抽象出来的一些设计，涉及的东西很多，我的水平有限，可能理解的也不到位，我会尽量把每一个论点的论据以及参考都摆出来，请大家不要完全相信这里的所有观点，如果有任何异议欢迎带着具体的实例反驳并留言。
特殊的是StoreLoad，会使该屏障之前的所有内存访问指令(装载和存储指令)完成之后，才执行该屏障之后的内存访问指令；是一个”全能型”的屏障，它同时具有其他三个屏障的效果
导读：文章内容较多，也有不少代码，但是作者写的也很认真，对理解并发编程会有帮助，值得一读。 阅读完大约需要15分钟，如果对 linux 实在不太感冒，也可以选择性从 double-check 章节开始看起。
如果要使用 " 内存屏障 " , 如 : 禁止 内核 抢占 " 方法保护临界区 " :
init 函数在包初始化时自动执行，这意味着它在程序开始执行前，由于 init 函数是由 Go 运行时自动调用的，并且在程序生命周期中只会被调用一次，它可以被用来初始化单例。
在Java中，volatile用于标记变量，而内存屏障又是volatile的底层实现。它们是Java中最基础也是最简单的两个概念，它们的出现使得开发者在多线程环境下能够保证更好的数据一致性和程序执行的正确性。volatile简单、轻量，相比于其他方式，如synchronized或直接加锁，有着更好的性能。能让开发者少些对锁的忧虑，多一些对实际问题的关注。
1、 内存访问操作/指令执行操作的乱序：假设每个CPU都分别运行着一个会触发内存访问操作的程序。那么对于这样一个CPU，其内存访问顺序是非常松散的，在保证程序上下文逻辑关系的前提下，CPU可能乱序执行内存操作。此外，编译器也可以将它输出的指令安排成任何它喜欢的顺序，只要保证不影响程序表面的执行逻辑。这里就涉及到了两次可能发生指令重排的情况：一个是编译的时候，由编译原理的知识知道，编译器会对代码进行优化，这一步就涉及到指令重排，当然，编译完成之后的目标代码中指令的顺序就是确定的，不同线程执行该代码的顺序是一样的；另一个就是CPU在执行具体的指令的时候，也会因为计算机当前的状态（比如寄存器的占用情况、ALU的使用情况，cup缓存层的存在等原因）的不同导致指令最终的执行顺序发生变化(实际上，cpu本身并不会对指令进行重排，它本身是按照编译后的顺序来执行指令的，只是由于执行不同的指令需要的时间长短不同，以及缓存层的存在，再加上CPU执行指令的流水线并不是串行化等因素，那么就有可能出现排在靠前位置的指令还没执行完，而排在靠后的指令已经执行完了的情况，这一情况就是所谓的CPU执行指令的乱序，具体原因后面会更详细地解释)，尽管这个变化可能不影响最终结果的正确性。
对于基础类型操作，使用原子变量就可以做到线程安全，那原子操作是如何保证线程安全的呢？linux中的原子变量如下：
既然是锁CPU，那就都是针对多核处理器或多CPU处理器。单核的话，只有发生中断会使任务被抢占，那么可以进入临界区之前先关中断，但是对多核CPU光关中断就不够了，因为对当前CPU关了中断只能使得当前CPU不会运行其它要进入临界区的程序，但其它CPU还是可能执行进入临界区的程序。
被volatile修饰的变量在编译成字节码文件时会多个lock指令，该指令在执行过程中会生成相应的内存屏障，以此来解决可见性跟重排序的问题。
这是根据我同时使用C++和Java工作超过20年所学到的，其实使用Java比C++还要早几年： 1、根据我的经验，当你把优化过的C++代码转换成Java代码，代码的速度会慢大约三倍。 2、根据我的经验，把Java代码转换成C++的代码，速度同样也会慢三倍。首先，这种比较根本没有意义，除非你能意识到用Java的方式去写Java代码，而不是像C++开发者那样去组织C++代码。 3、对于并发的数据结构使用Java往往更有效率。当数据结构不是并发使用时，JVM会消除内存屏障和同步，并倾向使用基于运行时性能分析的并发
在Linux设备驱动中，我们必须要解决的一个问题是：多个进程对共享资源的并发访问，并发的访问会导致竞态。
Disruptor的RingBuffer, 之所以可以做到完全无锁，也是因为"单线程写"，这是所有"前提的前提"，离了这个前提条件，没有任何技术可以做到完全无锁。Redis、Netty等等高性能技术框架的设计都是这个核心思想。
内存屏障（也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性，但volatile无法保证原子性。
小陈：老王，上一篇你引出了volatile底层是通过内存屏障来解决可见性和有序性问题的。首先我想问一下什么是内存屏障？
事情是这样的，一位读者看了我的一篇文章，不认同我文章里面的观点，于是有了下面的交流。
在前文中已经讲解到volatile的使用以及原子性的问题,volatile修饰的变量可以实现线程对变量的写操作能够让其他线程“看到”当前最新的变量数据值,从内存语义上而言,相当于告诉线程读取当前变量要从主内存中读取,对此,现将继续前文的volatile继续深入原理分析.
内存屏障，也称内存栅栏，内存栅障，屏障指令等， 是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作。---百度百科
使用final修饰的数据在字节码中显示带有ACC_FINAL的访问标识符,对应访问标示符号的值为0x1000
volatile关键字在多线程编程中非常重要，它保证了多个线程之间变量的可见性和有序性。
令重排序:java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果 与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的 重排序。
在分析说明 volatile 和 CAS 的实现原理前，我们需要先了解一些预备知识，这将是对 volatile 和 CAS 有深入理解的基石。 预备知识 缓存 现代处理器为了提高访问数据的效率，在每个CPU核心上都会有多级容量小，速度快的缓存（分别称之为L1 cache，L2 cache，多核心共享L3 cache等），用于缓存常用的数据。 缓存系统中是以缓存行(cache line)为单位存储的。缓存行是 2 的整数幂个连续字节，一般为 32-256 个字节。最常见的缓存行大小是 64个字节。 因此当CP
本文隶属于专栏《100个问题搞定Java虚拟机》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
速度快的存储硬件成本高、容量小，速度慢的成本低、容量大。为了权衡成本和速度，计算机存储分了很多层次，扬长避短，有寄存器、L1 cache、L2 cache、L3 cache、主存（内存）和硬盘等。图1 展示了现代存储体系结构。
volatile 关键字可以说是 Java 虚拟机提供的最轻量级的同步机制，但是它并不容易被正确、完整地理解，以至于许多程序员都习惯去避免使用它，遇到需要处理多线程数据竞争问题的时候一律使用 synchronized 来进行同步。了解 volatile 变量的语义对理解多线程操作的其他特性很有意义。
对volitile变量的写入操作之后要保证不能和读之后的读操作重排序。这是内存重排序的一种解决方案happenbeforr中规定的底层通过刚开始讲的内存屏障保证不会重排序。
最近爆肝了这系列文章 全网最硬核 Java 新内存模型解析与实验，从底层硬件，往上全面解析了 Java 内存模型设计，并给每个结论都配有了相关的参考的论文以及验证程序，我发现多年来对于 Java 内存模型有很多误解，并且我发现很多很多人都存在这样的误解，所以这次通过不断优化一个经典的 DCL （Double Check Locking）程序实例来帮助大家消除这个误解。
可以看到CPU是最快的，但是最窄，也就是说它虽然快，但存储量不大。CPU又可以分为三层，从上至下分别为：
if_icmpge: if,integer,compare,great equal
一旦一个共享变量（类的成员变量、 类的静态成员变量） 被 volatile 修饰之后， 那么就具备了两层语义：
在之前文章聊聊JMM，说到了内存屏障，内存屏障在Java语言实现一致性内存模型上起到了重要的作用，本文我们一起聊一聊内存屏障
写完后 立即刷新回主内存并及时发出通知，大家可以去主内存拿最新版，前面的修改对后面所有线程可见
程序在运行时内存实际的访问顺序和程序代码编写的访问顺序不一定一致，这就是内存乱序访问。内存乱序访问行为出现的理由是为了提升程序运行时的性能。这种内存乱序问题主要是由两种原因引起的：
本文主要来学习内存屏障和 CPU 缓存知识，以便于我们去了解 CPU 对程序性能优化做了哪些努力。
volatile通常被比喻成“轻量级的synchronized”，也是Java并发编程中比较重要的一个关键字。和synchronized不同，volatile是一个变量修饰符，只能用来修饰变量，无法修饰方法或代码块等。
Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。它有两条特性：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
