ConcurrentHashMap实现原理--中

      本篇文章主要讲解关于JVM的内存模型的相关知识，为理解下篇文章ConcurrentHashMap做铺垫！ 

      ConcurrentHashMap是Java5中新增加的一个线程安全的Map集合，可以用来替代HashTable。对于         ConcurrentHashMap是如何提高其效率的，可能大多人只是知道它使用了多个锁代替HashTable中的单个锁，也就是锁分离技术。

       ConcurrentHashMap实现了ConcurrentMap接口，先看看 ConcurrentMap 接口的文档说明：
       提供其他原子putIfAbsent、remove、replace方法的 Map。
      内存一致性效果：当存在其他并发 collection 时，将对象放入 ConcurrentMap 之前的线程中的操作 happen-before 随后通过另一线程从ConcurrentMap中访问或移除该元素的操作。

      重点理解一下内存一致性效果中的“happens-before”是怎么回事。

• happens-before

      这个概念在《深入理解JAVA虚拟机》里出现过，首先看一段代码：

       上面的代码，当线程1执行foo方法的时候，线程2访问getA和getB会得到的结果可能有以下四种：
A：a=1, b=2  // 都未改变
B：a=3, b=4  // 都改变了
C：a=3, b=2  //  a改变了，b未改变
D：a=1, b=4  //  b改变了，a未改变
上面的A,B,C都好理解，但是D可能会出乎一些人的预料。
        如果不了解JVM的同学可能会问怎么可能 b=4语句会先于 a=3 执行？
        这是一个多线程之间内存可见性（Visibility）顺序不一致的问题。有两种可能会造成上面的D选项。

        1) Java编译器的重排序(Reording)操作有可能导致执行顺序和代码顺序不一致。

        简单的说：假设代码有两条语句，代码顺序是语句1先于语句2执行；那么只要语句2不依赖于语句1的结果，打乱它们的顺序对最终的结果没有影响的话，那么真正交给CPU去执行时，他们的顺序可以是没有限制的。可以允许语句2先于语句1被CPU执行，和代码中的顺序不一致。

        重排序是JVM针对现代CPU的一种优化，Reordering后的指令会在性能上有很大提升。

        2) 从线程工作内存写回主存时顺序无法保证。

        线程在修改一个变量时，先拷贝入线程工作内存中，在线程工作内存修改后再写回主存中。假设例子中Reording后顺序仍与代码中的顺序一致，而接下来线程1把变量写回Main Memery的过程对线程2的可见性顺序就无法保证了。

        正因为上面的那些问题，如何让多线程之间，对象的状态对于各线程的“可视性”是顺序一致的就成了大问题。
        它的解决方式就是 Happens-before 规则：Java内存模型为所有程序内部动作定义了一个偏序关系，叫做happens-before。要想保证执行动作B的线程看到动作A的结果（无论A和B是否发生在同一个线程中），A和B之间就必须满足happens-before关系。

         在《Java并发编程实践》“中定义了如下Happens-before”规则：
① 程序次序法则：线程中的每个动作A都happens-before于该线程中的每一个动作B，其中，在程序中，所有的动作B都能出现在A之后。
② 监视器锁法则：对一个监视器锁的解锁 happens-before于每一个后续对同一监视器锁的加锁。
③ volatile变量法则：对volatile域的写入操作happens-before于每一个后续对同一个域的读写操作。
④ 线程启动法则：在一个线程里，对Thread.start的调用会happens-before于每个启动线程的动作。
⑤ 线程终结法则：线程中的任何动作都happens-before于其他线程检测到这个线程已经终结、或者从Thread.join调用中成功返回，或Thread.isAlive返回false。
⑥ 中断法则：一个线程调用另一个线程的interrupt happens-before于被中断的线程发现中断。
⑦ 终结法则：一个对象的构造函数的结束happens-before于这个对象finalizer的开始。
⑧ 传递性：如果A happens-before于B，且B happens-before于C，则A happens-before于C
        我们重点关注的是②、③，这两条也是我们通常编程中常用的。
后续分析ConcurrenHashMap时也会看到使用到锁(ReentrantLock)，Volatile，final等手段来保证happens-before规则的。
       使用锁方式实现“Happens-before”是最简单，容易理解的。

       早期Java中的锁只有最基本的synchronized，它是一种互斥的实现方式。在Java5之后，增加了一些其它锁，比如ReentrantLock，它基本作用和synchronized相似，但提供了更多的操作方式，比如在获取锁时不必像synchronized那样只是傻等，可以设置定时，轮询，或者中断，这些方法使得它在获取多个锁的情况可以避免死锁操作。在ConcurrentHashMap中，每个hash区间使用的锁正是ReentrantLock。
        Volatile可以看做一种轻量级的锁，但又和锁有些不同。
       a) 它对于多线程，不是一种互斥关系。
       b) 用volatile修饰的变量，不能保证该变量状态的改变对于其他线程来说是一种“原子化操作”。
       在Java5之前，JMM对Volatile的定义是：保证读写volatile都直接发生在main memory中，线程的working memory不进行缓存。
      它只承诺了读和写过程的可见性，并没有对Reording做限制，所以旧的Volatile并不太可靠。
      在Java5之后，JMM对volatile的语义进行了增强。就是我们看到的③ volatile变量法则。

      接着说下不变模式，它是多线程安全里最简单的一种保障方式。因为你拿他没有办法，想改变它也没有机会。不变模式主要通过final关键字来限定的。
      在Java内存模型中final关键字还有特殊的语义。Final域使得确保初始化安全性成为可能，初始化安全性让不可变形对象不需要同步就能自由地被访问和共享。

      下面我们用Happens-Before规则理解一个经典问题：双重检测锁为什么在java中不适用：

       new 对象; 这个语句的执行过程：它不是一个原子操作，实际是由多个步骤，简单的认为它主要有2步操作好了：
       a） 在内存中分配空间，并将引用指向该内存空间。
       b） 执行对象的初始化的逻辑(和操作)，完成对象的构建。
       此时因为线程1和线程2没有用同步，他们之间不存在“Happens-Before”规则的约束，所以在线程1创建对象的 a),b)这两个步骤对于线程2来说会有可能出现a)可见，b)不可见，造成了线程2获取到了一个未创建完整的对象引用，为后边埋下隐患。