注：当时笔记收录有遗录，后三个函数回值都是原来的值。
 
volatil限定符告诉编译器不要对这个变量进行任何形式的优化，而是始终的从变量的内存中读取变量的值。
 该变量可能被应用程序以外 的代码所修改，比如操作系统、硬件、或者一个并发执行的线程对其的值进行修改，就要使这个限定符。
 volatil BOOL V1=NULL;
 如果有的时候不给BOOL（假如）加上volatil限定，编译器可能对c++代码进行优化。这个优化中，编译器把BOOL变量的值放入寄存器中，
 这个操作只需要进行一次。然后它重复对CPU寄存器的值进行测试。与每次都从变量所在内存空间中取地变量的值来说，这样有更好的性能。加上volatile限定可以确保每一个成员都是从内存地址中读取的。详细见 《windows核心编程》206页具体的解释和用法。 

研究ThreadPoolExecutor的时候，发现其中大量使用了volatile变量。 

 
不知为何，因此做了一番查找，研究： 

 

 
其中借鉴了很多网上资料。 

 

 
在了解volatile变量作用前，先需要明白一些概念： 

 

 
什么是原子操作？ 

 
所谓原子操作,就是"不可中断的一个或一系列操作" , 在确认一个操作是原子的情况下，多线程环境里面，我们可以避免仅仅为保护这个操作在外围加上性能昂贵的锁，甚至借助于原子操作，我们可以实现互斥锁。 

 
很多操作系统都为int类型提供了+-赋值的原子操作版本，比如 NT 提供了 InterlockedExchange 等API， Linux/UNIX也提供了atomic_set 等函数。 

 

 

 

 
关于java中的原子性？ 

 
原子性可以应用于除long和double之外的所有基本类型之上的“简单操作”。对于读取和写入出long和double之外的基本类型变量这样的操作，可以保证它们会被当作不可分（原子）的操作来操作。 

 
因为JVM的版本和其它的问题，其它的很多操作就不好说了，比如说++操作在C++中是原子操作，但在Java中就不好说了。 

 
另外，Java提供了AtomicInteger等原子类。再就是用原子性来控制并发比较麻烦，也容易出问题。 

 

 
volatile原理是什么? 

 
Java中volatile关键字原义是“不稳定、变化”的意思 

 
使用volatile和不使用volatile的区别在于JVM内存主存和线程工作内存的同步之上。volatile保证变量在线程工作内存和主存之间一致。 

 
其实是告诉处理器, 不要将我放入工作内存, 请直接在主存操作我. 

 

 
接下来是测试 ：(通过测试能更好的发现和分析问题) 

 
申明了几种整形的变量，开启100个线程同时对这些变量进行++操作，发现结果差异很大： 

 
>>Execute End: 

 
>>Atomic: 100000 

 
>>VInteger: 38790 

 
>>Integer: 68749 

 
>>Source i: 99205 

 
>>Source Vi: 99286 

 
也就是说除了Atomic，其他的都是错误的。 

 

 
我们通过一些疑问，来解释一下。 

 

 
1：为什么会产生错误的数据？ 

 
多线程引起的，因为对于多线程同时操作一个整型变量在大并发操作的情况下无法做到同步，而Atom提供了很多针对此类线程安全问题的解决方案，因此解决了同时读写操作的问题。 

 
2：为什么会造成同步问题？ 

 
Java多线程在对变量进行操作的时候，实际上是每个线程会单独分配一个针对i值的拷贝(独立内存区域)，但是申明的i值确是在主内存区域中，当对i值修改完毕后，线程会将自己内存区域块中的i值拷贝到主内存区域中，因此有可能每个线程拿到的i值是不一样的，从而出现了同步问题。 

 
3：为什么使用volatile修饰integer变量后，还是不行？ 

 
因为volatile仅仅只是解决了存储的问题，即i值只是保留在了一个内存区域中，但是i++这个操作，涉及到获取i值、修改i值、存储i值(i=i+1)，这里的volatile只是解决了存储i值得问题，至于获取和修改i值，确是没有做到同步。 

 
4：既然不能做到同步，那为什么还要用volatile这种修饰符？ 

 
主要的一个原因是方便，因为只需添加一个修饰符即可，而无需做对象加锁、解锁这么麻烦的操作。但是本人不推荐使用这种机制，因为比较容易出问题(脏数据)，而且也保证不了同步。 

 
5：那到底如何解决这样的问题？ 

 
第一种：采用同步synchronized解决，这样虽然解决了问题，但是也降低了系统的性能。 

 
第二种：采用原子性数据Atomic变量，这是从JDK1.5开始才存在的针对原子性的解决方案，这种方案也是目前比较好的解决方案了。 

 
6：Atomic的实现基本原理？ 

 
首先Atomic中的变量是申明为了volatile变量的，这样就保证的变量的存储和读取是一致的，都是来自同一个内存块，然后Atomic提供了getAndIncrement方法，该方法对变量的++操作进行了封装，并提供了compareAndSet方法，来完成对单个变量的加锁和解锁操作，方法中用到了一个UnSafe的对象，现在还不知道这个UnSafe的工作原理(似乎没有公开源代码)。Atomic虽然解决了同步的问题，但是性能上面还是会有所损失，不过影响不大，网上有针对这方面的测试，大概50million的操作对比是250ms : 850ms，对于大部分的高性能应用，应该还是够的了。 

 

 
 
 
 
  

   Java代码  
   
  
 
 
 
 
 package qflag.ucstar.test.thread;  
   
 import java.util.concurrent.atomic.AtomicInteger;  
   
 /** 
  * 测试原子性的同步 
  * @author polarbear 2009-3-14 
  * 
  */  
 public class TestAtomic {  
       
     public static AtomicInteger astom_i = new AtomicInteger();  
       
     public static volatile Integer v_integer_i = 0;  
       
     public static volatile int v_i = 0;  
       
     public static Integer integer_i = 0;  
       
     public static int i = 0;  
       
     public static int endThread = 0;  
       
     public static void main(String[] args) {  
         new TestAtomic().testAtomic();  
     }  
       
     public void testAtomic() {  
           
         for(int i=0; i<100; i++) {  
             new Thread(new IntegerTestThread()).start();  
         }  
           
         try {  
             for(;;) {  
                 Thread.sleep(500);  
                 if(TestAtomic.endThread == 100) {  
                     System.out.println(">>Execute End:");  
                     System.out.println(">>Atomic: \t"+TestAtomic.astom_i);  
                     System.out.println(">>VInteger: \t"+TestAtomic.v_integer_i);  
                     System.out.println(">>Integer: \t"+TestAtomic.integer_i);  
                     System.out.println(">>Source i: \t"+TestAtomic.i);  
                     System.out.println(">>Source Vi: \t"+TestAtomic.v_i);  
                     break;  
                 }  
             }  
               
         } catch (Exception e) {  
             e.printStackTrace();  
         }  
     }  
       
 }  
 class IntegerTestThread implements Runnable {  
     public void run() {  
         int x = 0;  
         while(x<1000) {  
             TestAtomic.astom_i.incrementAndGet();  
             TestAtomic.v_integer_i++;  
             TestAtomic.integer_i++;  
             TestAtomic.i++;  
             TestAtomic.v_i++;  
             x++;  
         }  
         ++TestAtomic.endThread;  
     }  
 }  
 

 CAS操作
 
     在nginx里面大量使用了原子操作。我们需要知道一个很重要的技术就是CAS操作——Compare & Set，或是 Compare & Swap，现在几乎所有的CPU指令都支持CAS的原子操作，X86下对应的是 CMPXCHG 汇编指令。有了这个原子操作，我们就可以用其来实现各种无锁（lock free）的数据结构。
 
 这个操作用C语言来描述就是下面这个样子：（代码来自Wikipedia的Compare And Swap词条）意思就是说，看一看内存*reg里的值是不是oldval，如果是的话，则对其赋值newval。
 
 
 
 
  
 
      

       1
      
 
      

       2
      
 
      

       3
      
 
      

       4
      
 
      

       5
      
 
      

       6
      
 
      

       7
      
 
 
      
 
       

        int 
        compare_and_swap (
        int
        * reg, 
        int 
         oldval, 
        int 
         newval)
       
 
       

        {
       
 
       

          
        int 
        old_reg_val = *reg;
       
 
       

          
        if 
        (old_reg_val == oldval)
       
 
       

             
        *reg = newval;
       
 
       

          
        return 
        old_reg_val;
       
 
       

        }
       
 
      
 
 
 
 
 
 这个操作可以变种为返回bool值的形式（返回 bool值的好处在于，可以调用者知道有没有更新成功）：
 
 
 
 
  
 
      

       1
      
 
      

       2
      
 
      

       3
      
 
      

       4
      
 
      

       5
      
 
      

       6
      
 
      

       7
      
 
      

       8
      
 
 
      
 
       

        bool 
        compare_and_swap (
        int 
        *accum, 
        int 
        *dest, 
        int 
        newval)
       
 
       

        {
       
 
       

          
        if 
        ( *accum == *dest ) {
       
 
       

              
        *dest = newval;
       
 
       

              
        return 
        true
        ;
       
 
       

          
        }
       
 
       

          
        return 
        false
        ;
       
 
       

        }
       
 
      
 
 
 
 
 
 与CAS相似的还有下面的原子操作：（这些东西大家自己看Wikipedia吧）
 
Fetch And Add，一般用来对变量做 +1 的原子操作
Test-and-set，写值到某个内存位置并传回其旧值。汇编指令BST
Test and Test-and-set，用来低低Test-and-Set的资源争夺情况
 
 注：在实际的C/C++程序中，CAS的各种实现版本如下：
 
 
 
 1）GCC的CAS
 
 GCC4.1+版本中支持CAS的原子操作（完整的原子操作可参看 GCC Atomic Builtins）
 
 
 
 
  
 
      

       1
      
 
      

       2
      
 
 
      
 
       

        bool 
        __sync_bool_compare_and_swap (type *ptr, type oldval type newval, ...)
       
 
       

        type __sync_val_compare_and_swap (type *ptr, type oldval type newval, ...)
       
 
      
 
 
 
 
 
 2）Windows的CAS
 
 在Windows下，你可以使用下面的Windows API来完成CAS：（完整的Windows原子操作可参看MSDN的InterLocked Functions）
 
 
 
 
  
 
      

       1
      
 
      

       2
      
 
      

       3
      
 
 
      
 
       

        InterlockedCompareExchange ( __inout 
        LONG 
         volatile 
        *Target,
       
 
       

                                        
        __in 
        LONG 
         Exchange,
       
 
       

                                        
        __in 
        LONG 
         Comperand);
       
 
      
 
 
 
 
 
 3) C++11中的CAS
 
 C++11中的STL中的atomic类的函数可以让你跨平台。（完整的C++11的原子操作可参看 Atomic Operation Library）
 
 
 
 
  
 
      

       1
      
 
      

       2
      
 
      

       3
      
 
      

       4
      
 
      

       5
      
 
      

       6
      
 
 
      
 
       

        template
        < 
        class 
         T >
       
 
       

        bool 
        atomic_compare_exchange_weak( std::atomic<T>* obj,
       
 
       

                                           
        T* expected, T desired );
       
 
       

        template
        < 
        class 
         T >
       
 
       

        bool 
        atomic_compare_exchange_weak( 
        volatile 
        std::atomic<T>* obj,
       
 
       

                                           
        T* expected, T desired );
       
 
      
 
 
 
 

锁的概念
 
对于某一块代码段，多个线程或者协程同时执行会产生一些不符合预期的结果，就需要使用信号量保护这一段代码区，只能由一个线程来占用和执行这段代码．这相当于是一个大型的原子操作，由软件层面来实现．下面是一段结果不符合预期的代码段：
 
var count =0
 func main()  {
    wg:=sync.WaitGroup{}
    wg.Add(2)
    go add(&wg)
    go add(&wg)
    wg.Wait()
    fmt.Println(count)
 }
 func add(wg *sync.WaitGroup){
    for i:=0;i<100000;i++{
       count++
    }
    wg.Done()
 }
结果大多数情况下，都不是20000，这和预期结果是不一样的．我们来分析一下为什么会和预期不一样:
 
count++操作编译成汇编指令操作时（cpu只认这种指令），会分成这几步，
 
1.cpu从内存中获取count值
 
2.执行count加1操作
 
3.将count值写到缓存（或者内存中）
 
每一步都是原子操作（不可中断操作并且在这个时间点会独占某个资源），这三步合在一块就不是原子操作了．可能会出现两个线程（在不同的cpu上）都执行了读取count操作，其中一个线程执行了加一操作并将count值写到内存中更新，另外一个线程对这一操作无感知，并继续操作自己的旧值，结果就和预期不一致了．
 
单处理器不会出现这种情况，只有多处理器才会出现和预期不符的结果．
 
这个时候就需要加锁（让count++操作变成软件层面的原子操作）或者使用atomic的add操作（硬件层面的原子操作），同一时间点只让一个cpu不可中断的执行这些指令．
 
原子操作的概念和实现
 
概念就是对于某个指令或者某个代码段或者某个资源，在同一时间内，有且仅有一个cpu可以执行，并且是不可中断的，即一旦开始执行就执行到代码段末尾．
 
硬件层面上，有两种实现方案，目前cpu架构多采用第二种方案．
 
1.对总线加锁．在x86 平台上，CPU提供了在指令执行期间对总线加锁的手段。对总线加锁以后，别的cpu就不能通过总线访问内存数据了．显而易见，这个加锁指令在性能上有些不尽人意，如果有其他cpu想访问别的资源，也是访问不了的，我认为锁的粒度实在太大，严重影响cpu执行效率．
 
2.使用缓存一致性协议，对缓存行加锁。当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。
 
软件层面，使用硬件层面的原子操作机制，获取临界区代码段的操作权，然后执行临界区代码段．大多数编程语言锁的实现都是借助于硬件层面实现的加锁机制，使用操作系统（借助硬件加锁）提供的一些基本原子操作（cas,add操作等等）完成对锁的实现，golang锁的实现也不例外．
 
mutex源码分析
 
对锁和原子操作有了基本认识以后，再阅读golang提供的锁源码就不费劲了．根据源码进行逐步解释，有些细节本人也没细看，只能说个大概意思．golang版本1.10.3
 
先讲一下mutex锁的两种模式，正常模式和饥饿模式
 
正常模式，协程在先进先出的队列里进行排队，前一个协程执行结束解锁时，会唤醒等待队列中的一个协程，唤醒的协程和刚来的协程（还没进入队列）竞争锁的所有权．刚进来的协程当前正在持有着cpu，资源也不需要重新调度，刚唤醒的协程大概率竞争不过新来的协程．当唤醒的协程沉睡超过1ms，会将锁置为饥饿模式．
 
饥饿模式，解锁的协程将锁的所有权移交给等待队列中的队首协程，新到来的协程不会尝试去获取锁的控制权（即时当前是可获取状态），也不会尝试去自旋，会直接加入到队尾等待被唤醒．
 
饥饿模式的解除，当前获取mutex所有权的协程是阻塞队列的最后一个协程或者该协程等待时间小于1ms，则将饥饿模式转换成正常模式．
 
正常模式和饥饿模式优劣，正常模式性能会更高一些，它倾向于新来的协程获取到mutex的所有权，减少了资源切换过程（唤醒老协程需要重新调度资源到cpu中）．饥饿模式是防止某个协程等待时间过久，导致预期之外的问题．
 
// mutex结构体
 type Mutex struct {
    state int32 //状态标识符
    sema  uint32
 }
const (
    mutexLocked = 1 << iota // 上锁标志位
    mutexWoken //协程有唤醒状态
    mutexStarving //mutex是否处于饥饿模式
    mutexWaiterShift = iota //当前等待mutex的协程数量偏移
 )
 // lock 获取锁的控制权，对部分和本文内容关联不高的代码做了删减
 func (m *Mutex) Lock() {
 // 使用cas操作，完成对mutex的抢占，抢占成功则获取到mutex的所有权，失败则去排队等待锁的释放
     if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked)
         return
    }
    var waitStartTime int64 //当前协程等待了多长时间
    starving := false //该协程是否要进入饥饿模式标识
    awoke := false //当前协程是否处于唤醒状态标识
    iter := 0 //自旋次数标识
    old := m.state
    for {
       //饥饿模式下协程不用自旋，新来的协程直接进入队列等待被唤醒，当自旋次数大于４时，也会停止自旋
       if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
          // 自旋协程尝试对mutexWoken标志位上锁，有唤醒协程的情况下，mutex持有协程解锁以后就不需要唤醒排队等待的协程
          if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
             atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
             awoke = true
          }
          runtime_doSpin()//自旋
          iter++
          old = m.state//更新到最新状态
          continue
       }
       new := old
       // 新来的协程在饥饿模式下是不能直接获取到mutex所有权的
       if old&mutexStarving == 0 {
          new |= mutexLocked
       }
      // 当mutex已被占有或者mutex处于饥饿模式，排队者数量＋1
       if old&(mutexLocked|mutexStarving) != 0 {
          new += 1 << mutexWaiterShift
      }
       // 当前协程将mutex切换成饥饿模式，如果当前处于解锁状态，则不需要切换成饥饿模式，切换起来没有意义
       if starving && old&mutexLocked != 0 {
          new |= mutexStarving
       }
       if awoke {
          // 当前协程处于唤醒状态有两种可能，１．被解锁的协程唤醒２．刚进来的协程在自旋中成功设置了唤醒标志位
      // 不管怎样，将woken标志位置零
          if new&mutexWoken == 0 {
             throw("sync: inconsistent mutex state")
          }
          new &^= mutexWoken
       }
         //cas操作，当前协程尝试去获取锁
       if atomic.CompareAndSwapInt32(&m.state, old, new) {
          if old&(mutexLocked|mutexStarving) == 0 {
             break //之前的mutex既没有被加锁也不是饥饿模式时，说明锁已经获取成功，当前协程直接返回，执行临界区代码
          }
          //判断之前是否排队等待过mutex
          queueLifo := waitStartTime != 0
          if waitStartTime == 0 {
             waitStartTime = runtime_nanotime()//初始化等待开始时间
          }
          runtime_SemacquireMutex(&m.sema, queueLifo)
          starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs//等待超过1ms,则标记当前已经饥饿，需要设置mutex为饥饿模式
          old = m.state
          if old&mutexStarving != 0 {
             // mutex处于是唤醒状态或者上锁状态，但是等待者数量为零，则报错抛出异常
             if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
                throw("sync: inconsistent mutex state")
             }
             delta := int32(mutexLocked - 1<<mutexWaiterShift)
             if !starving || old>>mutexWaiterShift == 1 {
                // 退出饥饿模式
                delta -= mutexStarving
             }
             atomic.AddInt32(&m.state, delta)
             break
          }
          awoke = true
          iter = 0//自旋次数置为零，进入新的循环，去尝试获取mutex的所有权
       } else {
          old = m.state  //进入新的循环，去尝试获取mutex的所有权
       }
    }
 }