关于ConcurrentHashMap高并发性的实现机制的探讨

Java内存模型中的相关部分

1. 内存可见性

按照维基百科对于Java内存模型的说法，Java虚拟机在线程中需要遵循as-if-serial语义，但是这个语义不会阻止不同的线程访问同一个数据时具有多个场景。也就是说另一个线程可能不会立即看到一个线程对数据操作后的结果。

2. happens-before指令

happens-before指令归入程序指令。在程序指令中，如果一个动作在其他动作之前发生，那么他将比其他指令先进入到happens-before指令中。此外，释放和随后获取锁会形成happens-before图的边。一个读线程会被允许返回一个写线程的值，如果这个写线程对值进行了最后一次写操作。也就是说一旦满足happens-before，写线程的动作结果是读线程可见的。

其实维基百科上专门有对Java内存模型的介绍，附上链接：
https://en.wikipedia.org/wiki/Javamemorymodel

volatile关键字

被volatile关键字修饰的变量会存储在主存而不是CPU缓存中。那么被volatile关键字修饰的变量对于操作它的所有线程都是透明的。而且这些被修饰的变量在操作中不会被重排序。

这样做就表明经过volatile关键字修饰的变量应该在多线程中不会出现意外，但是实际上，就算是经过volatile修饰的变量也不一定就能在多线程中不出现意外

public class Entity {

    volatile int a = 0;

    volatile int b = 0;

    private static final Object OBJECT = new Object();

    private Entity() {}

    public void change(int i) {
        b = i;
    }

    public void increase() {
        a++;
    }

    public static Entity instance() {
        synchronized (OBJECT) {
            return new Entity();
        }
    }
}

那么对于change方法，对b的操作是原子性的。对于increase方法，对a的操作是非原子性的。

public class MyThread implements Runnable {

    private int var;

    private Entity e;

    public MyThread(int var, Entity e) {
        this.var = var;
        this.e = e;
    }

    @Override
    public void run() {
        e.change(var);
    }
}

public class ThreadDemo {

    public static void main(String[] args) {

        Entity e = Entity.instance();

        for(int i = 0;i<100;i++) {
            new Thread(() -> {
                e.increase();
            }).start();

            new Thread(new MyThread(i, e)).start();
        }

        System.out.println(e.a);
        System.out.println(e.b);
    }
}

其实结果应该能猜到，结果不一定是99。所以无关乎是否进行了原子性操作，最后都不一定能正常执行。因为在oracle的Java SE文档中的原子许可部分里专门说到

Using volatile variables reduces the risk of memory consistency errors,…

也就是说，经过volatile关键字修饰的变量只能减少发生在内存一致性错误的风险，并不能完全消除。

附上随机进行两次的截图：

synchronized关键字

Oracle Java的官方文档里面有专门对synchronized方法的介绍。我就不再完整翻译了
附上链接：https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html

• 首先, 对于同一对象上的两个同步方法调用是不可能交错的。当一个线程正在执行对象的同步方法时, 为同一对象块 (挂起执行) 调用同步方法的所有其他线程, 直到第一个线程完成对象为止。
• ‎第二, 当同步方法退出时, 它会自动建立一个happens-before与对同一对象的同步方法的‎‎任何后续调用‎‎的关系。这保证对对象状态的更改对所有线程都可见。‎

synchronized方法启用了一种简单策略来防止线程干扰和内存一致性错误，但这种策略也会带来并发活动性问题，比如死锁，饿死和活锁

也就是说如果在上面的Entity类的两个方法前用synchronized修饰，应该能得到两个99。

如果我还在写，那就证明不是。大家可以自己多试几次。

所以其实volatile和synchronized都不能保证在高并发场景下不发生内存一致性错误

那么ConcurrentHashMap是如何设计在并发场景的使用的？

ConcurrentHashMap的结构(Java version:1.8.0_162)

1. Java8和Java7中的ConcurrentHashMap源码有很大不同。Java8中删除了HashEntry类的存在，改用Node类代替。大量删除了Segment中的代码，选择直接在ConcurrentHashMap中用方法实现。

2. ConcurrentHashMap中存在一个内部类Node<K, V>，Node实现了单向链表结构

3. 一个Node数组table，当然，使用volatile关键字修饰了

   transient volatile Node<K,V>[] table;

4. 重新分配时需要进行辅助的Node数组next

   transient volatile Node<K,V>[] next;

5. ConcurrentHashMap通过维护一个Node链表数组进行数据的存放，根据每个键值对计算出的hashcode值找到数组对应的位置。那么当出现hashcode相同的键值对，新的键值对将放在原来的键值对的位置，而原来的键值对将作为新键值对的下一个值存放在这个链表中

了解了这些，也就知道了对于一个ConcurrentHashMap对象中数据的增删改查也就是对table的增删改查

既然volatile修饰过的变量不能保证不出现内存一致性错误，为什么table还是选择用volatile进行修饰？

上源码：

public V put(K key, V value) {
    return putVal(key, value, false);
}

/** Implementation for put and putIfAbsent */
final V putVal(K key, V value, boolean onlyIfAbsent) {
    if (key == null || value == null) throw new NullPointerException();
    int hash = spread(key.hashCode());
    int binCount = 0;
    for (Node<K,V>[] tab = table;;) {
        Node<K,V> f; int n, i, fh;
        if (tab == null || (n = tab.length) == 0)
            tab = initTable();
        else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) {
            if (casTabAt(tab, i, null,
                         new Node<K,V>(hash, key, value, null)))
                break;                   // no lock when adding to empty bin
        }
        else if ((fh = f.hash) == MOVED)
            tab = helpTransfer(tab, f);
        else {
            V oldVal = null;
            synchronized (f) {
                if (tabAt(tab, i) == f) {
                    if (fh >= 0) {
                        binCount = 1;
                        for (Node<K,V> e = f;; ++binCount) {
                            K ek;
                            if (e.hash == hash &&
                                ((ek = e.key) == key ||
                                 (ek != null && key.equals(ek)))) {
                                oldVal = e.val;
                                if (!onlyIfAbsent)
                                    e.val = value;
                                break;
                            }
                            Node<K,V> pred = e;
                            if ((e = e.next) == null) {
                                pred.next = new Node<K,V>(hash, key,
                                                          value, null);
                                break;
                            }
                        }
                    }
                    else if (f instanceof TreeBin) {
                        Node<K,V> p;
                        binCount = 2;
                        if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key,
                                                       value)) != null) {
                            oldVal = p.val;
                            if (!onlyIfAbsent)
                                p.val = value;
                        }
                    }
                }
            }
            if (binCount != 0) {
                if (binCount >= TREEIFY_THRESHOLD)
                    treeifyBin(tab, i);
                if (oldVal != null)
                    return oldVal;
                break;
            }
        }
    }
    addCount(1L, binCount);
    return null;
}

put方法其实是对putVal的一种封装，而在putVal方法中，对于添加数据的过程上了锁。

但其实之前就说过了，synchronized也不管用

所以要看上面代码中调用了一个非常关键的方法：tabAt和casTabAt，他们统称为Volatile许可方法，还有一个setTabAt（这个方法在replace和remove方法中都被调用）

static final <K,V> Node<K,V> tabAt(Node<K,V>[] tab, int i) {
    return (Node<K,V>)U.getObjectVolatile(tab, ((long)i << ASHIFT) + ABASE);
}

static final <K,V> boolean casTabAt(Node<K,V>[] tab, int i,
                                    Node<K,V> c, Node<K,V> v) {
    return U.compareAndSwapObject(tab, ((long)i << ASHIFT) + ABASE, c, v);
}

static final <K,V> void setTabAt(Node<K,V>[] tab, int i, Node<K,V> v) {
    U.putObjectVolatile(tab, ((long)i << ASHIFT) + ABASE, v);
}

啊哈，好像有点眉目了。U其实是一个Unsafe对象。
继续看Unsafe的源码

public native Object getObjectVolatile(Object var1, long var2);

public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);

public native void putObjectVolatile(Object var1, long var2, Object var4);

终于到头了，看到native关键字，就知道这个方法不是Java写的。Java不能直接访问操作系统底层，而是通过本地方法来访问。所以那些用native修饰的方法是对底层操作的

那么Unsafe类提供了硬件级别的原子操作

也就是说这个对象可以直接对内存动刀子。所以这个对象的getObjectVolatile方法就一定可以获取到最新的table。所以无惧高并发带来的内存一致性错误的烦恼。

其他的同理可得

问题也就迎刃而解了

如果我说的不对，还请大家及时指出，谢谢。

ps:
至于Java10有没有删除Unsafe类，得等我看了源码才知道，或者有谁说一声
更详细的关于Unsafe类的介绍：http://www.importnew.com/14511.html