" 代码 “ 编译成 ” 可执行文件 “ , 执行该 可执行文件 时 , 二进制指令 的 ” 执行顺序 " , 与 源码 的指令顺序 并不是完全一致的 , 为了提高 " 可执行文件 " 的执行性能 , 会对程序中的 " 指令 " 进行优化 ;
如果要使用 " 内存屏障 " , 如 : 禁止 内核 抢占 " 方法保护临界区 " :
" 处理器内存屏障 “ 针对 ” CPU " 之间的内存访问乱序 和 CPU 访问外设乱序 问题 ;
我们都知道，带有优化的编译器，会尝试重新排序汇编指令，以提高程序的执行速度。但是，当在处理同步问题的时候，重新排序的指令应该被避免。因为重新排序可能会打乱我们之前想要的同步效果。其实，所有的同步原语都可以充当优化和内存屏障。
编译器优化乱序和CPU执行乱序的问题可以分别使用优化屏障 (Optimization Barrier)和内存屏障 (Memory Barrier)这两个机制来解决：
内存屏障 , 又称为 " 屏障指令 " , 用于保证 " 编译器 “ 或 ” CPU “ 访问内存时 , 保证 按照顺序执行 , 即 ” 内存屏障 之前 “ 的指令 与 ” 内存屏障 之后 " 的指令 不会犹豫 编译器 和 CPU 优化导致 顺序混乱 ;
导读：文章内容较多，也有不少代码，但是作者写的也很认真，对理解并发编程会有帮助，值得一读。 阅读完大约需要15分钟，如果对 linux 实在不太感冒，也可以选择性从 double-check 章节开始看起。
写屏障是指，在改变特定内存的值（实际上也就是写入内存）的时候额外执行的一些动作。在大多数的垃圾回收算法中，都利用到了写屏障。写屏障通常用于在运行时探测并记录回收相关指针(interesting pointer)，在回收器只回收堆中部分区域的时候，任何来自该区域外的指针都需要被写屏障捕获，这些指针将会在垃圾回收的时候作为标记开始的根。JAVA使用的其余的分代的垃圾回收器，都有写屏障。举例来说，每一次将一个老年代对象的引用修改为指向年轻代对象，都会被写屏障捕获，并且记录下来。因此在年轻代回收的时候，就可以避免扫描整个老年代来查找根。
然后看看标准C++基金会（https://isocpp.org）怎么说的（官方链接）：
由以下博客的分析可以知道，内核的kfifo使用了很多技巧以实现其高效性。比如，通过限定写入的数据不能溢出和内存屏障实现在单线程写单线程读的情况下不使用锁。因为锁是使用在共享资源可能存在冲突的情况下。还用设置buffer缓冲区的大小为2的幂次方，以简化求模运算，这样求模运算就演变为 (fifo->in & (fifo->size – 1))。通过使用unsigned int为kfifo的下标，可以不用考虑每次下标超过size时对下表进行取模运算赋值，这里使用到了无符号整数的溢出回零的特性。由于指示读写指针的下标一直在增加，没有进行取模运算，知道其溢出，在这种情况下写满和读完就是不一样的标志，写满是两者指针之差为fifo->size，读完的标志是两者指针相等。后面有一篇博客还介绍了VxWorks下的环形缓冲区的实现机制点击打开链接，从而可以看出linux下的fifo的灵巧性和高效性。
对于基础类型操作，使用原子变量就可以做到线程安全，那原子操作是如何保证线程安全的呢？linux中的原子变量如下：
Disruptor的RingBuffer, 之所以可以做到完全无锁，也是因为"单线程写"，这是所有"前提的前提"，离了这个前提条件，没有任何技术可以做到完全无锁。Redis、Netty等等高性能技术框架的设计都是这个核心思想。
在《DllMain中不当操作导致死锁问题的分析--死锁介绍》一文中，我们介绍了死锁产生的原因。一般来说，如果我们对线程同步技术掌握不牢，或者同步方案混乱，极容易导致死锁。本文我们将介绍如何使用valgrind排查死锁问题。（转载请指明出于breaksoftware的csdn博客）
在Linux设备驱动中，我们必须要解决的一个问题是：多个进程对共享资源的并发访问，并发的访问会导致竞态。
zgc只支持64位系统，然后最大支持4T的堆内存，64位指针只需要使用42位就可以寻址4TB的空间，这意味着有多余的22位可以利用。zgc利用了4位，分别用来表示：是否已经finalize，重映射（remap），mark0，mark1。 mark0与mark1表示是否被标记，在gc周期性更换，这样可以不要重复去复原（就像以前survivor的复制回收算法，也就是这次用mark0表示，下次就用mark1，在用mark1标记时顺便把mark0复原，在用mark0标记时顺便把mark1复原）。
一切互斥操作的依赖是 自旋锁（spin_lock），互斥量（semaphore）等其他需要队列的实现均需要自选锁保证临界区互斥访问。
本文讲述了Linux中RCU（Read-Copy-Update）机制在内存管理中的重要作用，以及如何在Linux内核中实现和管理RCU。在Linux内核中，RCU用于在多个进程共享相同内存空间时，保证这些进程之间的数据一致性。本文首先介绍了RCU的基本原理，然后逐步深入介绍了Linux内核中RCU的实现细节。最后，通过一个具体的例子，展示了如何在Linux内核中实现一个简单的RCU。
这似乎毫无疑问。但是了解编译、链接原理的“底层”知识，则不会轻易下定论。特别是在用到多线程涉及到内存共享没有加锁的时候，也会暴露这个问题。
最近Rust For Linux的项目，随着Rust的火爆也开始逐渐升温，但是谷歌的强烈支持以及rCore OS、Redox等各种Rust操作系统项目的经验积累，Rust想进入到Linux的真正核心，也还是有很长的路要走，之前笔者已经撰文对于Rust在汇编支持、panic和alloc等系统操作等方面的问题进行过简要说明了。这里再对于Rust进入到Linux内核的最大拦路虎-也就是内存模型方面的问题，做一下介绍。
现在大多数现代计算机为了提高性能而采取乱序执行，这可能会导致程序运行不符合我们预期，内存屏障就是一类同步屏障指令，是CPU或者编译器在对内存随机访问的操作中的一个同步点，只有在此点之前的所有读写操作都执行后才可以执行此点之后的操作。
1、 内存访问操作/指令执行操作的乱序：假设每个CPU都分别运行着一个会触发内存访问操作的程序。那么对于这样一个CPU，其内存访问顺序是非常松散的，在保证程序上下文逻辑关系的前提下，CPU可能乱序执行内存操作。此外，编译器也可以将它输出的指令安排成任何它喜欢的顺序，只要保证不影响程序表面的执行逻辑。这里就涉及到了两次可能发生指令重排的情况：一个是编译的时候，由编译原理的知识知道，编译器会对代码进行优化，这一步就涉及到指令重排，当然，编译完成之后的目标代码中指令的顺序就是确定的，不同线程执行该代码的顺序是一样的；另一个就是CPU在执行具体的指令的时候，也会因为计算机当前的状态（比如寄存器的占用情况、ALU的使用情况，cup缓存层的存在等原因）的不同导致指令最终的执行顺序发生变化(实际上，cpu本身并不会对指令进行重排，它本身是按照编译后的顺序来执行指令的，只是由于执行不同的指令需要的时间长短不同，以及缓存层的存在，再加上CPU执行指令的流水线并不是串行化等因素，那么就有可能出现排在靠前位置的指令还没执行完，而排在靠后的指令已经执行完了的情况，这一情况就是所谓的CPU执行指令的乱序，具体原因后面会更详细地解释)，尽管这个变化可能不影响最终结果的正确性。
本文作者：yifhao，腾讯PCG NOW直播 后台工程师 介绍 本文基于 2019.02 发布的 go 1.12 linux amd64 版本, 主要介绍了 Runtime 实现的一点原理和细节, 对大家容易错或者网络上很多错误的地方做一些梳理: Golang Runtime 是个什么 Golang Runtime 的发展历程, 每个版本的改进 Go 调度: 协程结构体, 上下文切换, 调度队列, 大致调度流程, 同步执行流又不阻塞线程的网络实现等 Go 内存: 内存结构, mspan 结构, 全
如今大数据，云计算，分布式系统等对算力要求高的方向如火如荼。提升计算机算力的一个低成本方法是增加CPU核心，而不是提高单个硬件工作效率。
特殊的是StoreLoad，会使该屏障之前的所有内存访问指令(装载和存储指令)完成之后，才执行该屏障之后的内存访问指令；是一个”全能型”的屏障，它同时具有其他三个屏障的效果
线程启动之后，进入main()方法，在main()方法中进行线程的一些初始化，初始化工作完成之后，会调用Looper.loop()进行消息监听，而loop()方法是一个死循环，从而保证线程不会立即退出：
相信很多 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 抽象的理解有所帮助。但是，还是强调一点，内存模型的设计，出发点是让大家可以不用关心底层而抽象出来的一些设计，涉及的东西很多，我的水平有限，可能理解的也不到位，我会尽量把每一个论点的论据以及参考都摆出来，请大家不要完全相信这里的所有观点，如果有任何异议欢迎带着具体的实例反驳并留言。
init 函数在包初始化时自动执行，这意味着它在程序开始执行前，由于 init 函数是由 Go 运行时自动调用的，并且在程序生命周期中只会被调用一次，它可以被用来初始化单例。
事情是这样的，一位读者看了我的一篇文章，不认同我文章里面的观点，于是有了下面的交流。
ZGC（Z Garbage Collector）是一款由Oracle公司研发的，以低延迟为首要目标的一款垃圾收集器。它是基于动态Region内存布局，（暂时）不设年龄分代，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的收集器。在JDK 11新加入，还在实验阶段，主要特点是：回收TB级内存（最大4T），停顿时间不超过10ms。
对volitile变量的写入操作之后要保证不能和读之后的读操作重排序。这是内存重排序的一种解决方案happenbeforr中规定的底层通过刚开始讲的内存屏障保证不会重排序。
ZGC是一款在JDK11中新加入的具有实验性质的低延迟垃圾收集器，目前仅支持Linux/x86-64。ZGC收集器是一款基于Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低延迟为首要目标的一款垃圾收集器。
cmpxchg是X86比较交换指令，这个指令在各大底层系统实现的原子操作和各种同步原语中都有广泛的使用，比如linux内核，JVM,GCC编译器等,cmpxchg就是比较交换指令，了解cmpxchg之前先了解原子操作。
如果下面的一些概念有些不清楚的可以先看深入理解JVM - 垃圾收集器和深入理解JVM - Shenandoah垃圾收集器。
垃圾回收机制最早诞生于Lisp编程语言，但Lisp的作者McCathy在第一次现场演示Lisp时却因中途耗尽全部32KB内存以及一些其他原因只能草草收场。60年后的今天，垃圾回收技术再也不是一个笑话，它俨然成为诸如Java、C#、Python、Erlang、Golang编程语言的核心组件。
那在众多的单例实现方式中呢，双重检查单例（Double Check Lock）又是比较常用的一种实现方案，简称DCL；
if_icmpge: if,integer,compare,great equal
内存屏障（也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性，但volatile无法保证原子性。
在看java原子类时里有很多方法都调用了Unsafe类方法，Unsafe类方法在jdk里没找到源码，然后下载open jdk找到了源码，在/src/share/classes/sun/misc 目录下。定义如下：
既然是锁CPU，那就都是针对多核处理器或多CPU处理器。单核的话，只有发生中断会使任务被抢占，那么可以进入临界区之前先关中断，但是对多核CPU光关中断就不够了，因为对当前CPU关了中断只能使得当前CPU不会运行其它要进入临界区的程序，但其它CPU还是可能执行进入临界区的程序。
什么是ZGC ZGC收集器(Z Garbage Collector)由Oracle公司研发.2018年提交了JEP 333将ZGC提交给了OpenJDK,推动进入OpenJDK11的发布清单中。ZGC收集器是基于Region内存布局，暂时不设分代,使用读屏障,着色指针和内存多重映射等技术来实现并发的标记整理算法,以低延迟为目标的一款收集器。 目标 在对吞吐量影响不大的情况下,对任意大小堆收集停顿时间都控制在10ms以内的低延迟。 ZGC堆内存布局 与G1一样,ZGC也采用基于Region的堆内存布局 ZGC
CPU在摩尔定律的指导下以每18个月翻一番的速度在发展，然而内存和硬盘的发展速度远远不及CPU。这就造成了高性能能的内存和硬盘价格及其昂贵。然而CPU的高度运算需要高速的数据。为了解决这个问题，CPU厂商在CPU中内置了少量的高速缓存以解决I\O速度和CPU运算速度之间的不匹配问题。
在分析说明 volatile 和 CAS 的实现原理前，我们需要先了解一些预备知识，这将是对 volatile 和 CAS 有深入理解的基石。 预备知识 缓存 现代处理器为了提高访问数据的效率，在每个CPU核心上都会有多级容量小，速度快的缓存（分别称之为L1 cache，L2 cache，多核心共享L3 cache等），用于缓存常用的数据。 缓存系统中是以缓存行(cache line)为单位存储的。缓存行是 2 的整数幂个连续字节，一般为 32-256 个字节。最常见的缓存行大小是 64个字节。 因此当CP
RCU（Read-Copy Update）是数据同步的一种方式，在当前的Linux内核中发挥着重要的作用。RCU主要针对的数据对象是链表，目的是提高遍历读取数据的效率，为了达到目的使用RCU机制读取数据的时候不对链表进行耗时的加锁操作。这样在同一时间可以有多个线程同时读取该链表，并且允许一个线程对链表进行修改（修改的时候，需要加锁）。RCU适用于需要频繁的读取数据，而相应修改数据并不多的情景，例如在文件系统中，经常需要查找定位目录，而对目录的修改相对来说并不多，这就是RCU发挥作用的最佳场景。 Linux内核源码当中,关于RCU的文档比较齐全，你可以在 /Documentation/RCU/ 目录下找到这些文件。Paul E. McKenney 是内核中RCU源码的主要实现者，他也写了很多RCU方面的文章。他把这些文章和一些关于RCU的论文的链接整理到了一起。http://www2.rdrop.com/users/paulmck/RCU/ 在RCU的实现过程中，我们主要解决以下问题： 1，在读取过程中，另外一个线程删除了一个节点。删除线程可以把这个节点从链表中移除，但它不能直接销毁这个节点，必须等到所有的读取线程读取完成以后，才进行销毁操作。RCU中把这个过程称为宽限期（Grace period）。 2，在读取过程中，另外一个线程插入了一个新节点，而读线程读到了这个节点，那么需要保证读到的这个节点是完整的。这里涉及到了发布-订阅机制（Publish-Subscribe Mechanism）。 3， 保证读取链表的完整性。新增或者删除一个节点，不至于导致遍历一个链表从中间断开。但是RCU并不保证一定能读到新增的节点或者不读到要被删除的节点。 宽限期
ZGC有人称它为Zero GC，其实「Z」并非什么专业名词的缩写，这款收集器的名字就叫作Z Garbage Collector。
作为 Android 开发者，相信对于 Handler 的使用早已烂熟于心。Handler 对于 Android 非常重要，可以说，没有它，Android App 就是一堆“破铜烂铁”，它就像 Android 的血液，穿梭在 App 的各个角落，输送养分。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
