concurrentHashMap源码解析带来的一系列问题（CAS，volatile ，current包，atomic包）

想看下concurrentHashMap的源码，但是马上就遇到一堆问题，比如CAS是什么，比如volatile的作用。然后各种查，终于理解了个大概，希望对大家有所帮助。

因为在面试中总被问道concurrentHashMap 这个类，回答其能解决并发问题，总觉的很LOW，遂想深入研究。

遇到第一问题：乐观锁与悲观锁区别

答：在大神的博客中找到了比较好理解的答案

1、悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。悲观锁的实现，往往依靠底层提供的锁机制；悲观锁会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。

2、乐观锁：假设不会发生并发冲突，每次不加锁而是假设没有冲突而去完成某项操作，只在提交操作时检查是否违反数据完整性。如果因为冲突失败就重试，直到成功为止。乐观锁大多是基于数据版本记录机制实现。为数据增加一个版本标识，比如在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

乐观锁的缺点是不能解决脏读的问题。

在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.

锁机制存在以下问题：

（1）在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
（2）一个线程持有锁会导致其它所有需要此锁的线程挂起。
（3）如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

扫描二维码关注公众号，回复： 46898 查看本文章

遇到第二问题：为什么concurrentHashMap 这个类这个类里大多数变量都用volatile这个关键字修饰

答：在大神的博客中找到了答案

volatile关键字修饰的特性：

①使得变量更新变得具有可见性，只要被volatile修饰的变量的赋值一旦变化就会通知到其他线程，如果其他线程的工作内存中存在这个同一个变量拷贝副本，那么其他线程会放弃这个副本中变量的值，重新去主内存中获取

②产生了内存屏障，防止指令进行了重排序，关于这点的解释，请看下面一段代码：

package com.brickworkers;

public class VolatileTest {

    int a = 0;                 //1
    int b = 1;                 //2
    volatile int c = 2;        //3
    int d = 3;                 //4
    int e = 4;                 //5

}

在如上的代码中，因为c变量是用volatile进行修饰，那么就会对该段代码产生一个内存屏障，用以保证在执行语句3的时候语句1和语句2是绝对执行完毕的，而且在执行语句3的时候，语句4和语句5肯定没有执行。同时说明一下，在上述代码中虽然保证了语句3的执行顺序不可变换，但是语句1和语句2，语句4和语句5可能发生指令重排序哦。

遇到第三个问题：什么是CAS

答：自己总结下

CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做

Java中是如何保证CAS操作的呢，此时又引出了atomic包,我们以AtomicInteger类举例：

public class AtomicInteger extends Number implements java.io.Serializable {  
      
    private volatile int value;  

    public final int get() {  
        return value;  
    }  
      
    public final int getAndIncrement() {  
        for (;;) {  
            int current = get();  
            int next = current + 1;  
            if (compareAndSet(current, next))  
                return current;  
        }  
    }  
      
    public final boolean compareAndSet(int expect, int update) {  
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  
    }

上面代码中compareAndSet()方法就是CAS的具体操作，利用CPU的CAS指令，同时借助JNI来完成Java的非阻塞算法

此时又引出一个问题（大神博客中提到的）ABA问题：

因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。

解决方法就是atomic包下的这两个类：AtomicStampedReference/AtomicMarkableReference

AtomicMarkableReference 类描述的一个<Object,Boolean>的对，可以原子的修改Object或者Boolean的值，这种数据结构在一些缓存或者状态描述中比较有用。这种结构在单个或者同时修改Object/Boolean的时候能够有效的提高吞吐量。

AtomicStampedReference 类维护带有整数“标志”的对象引用，可以用原子方式对其进行更新。对比AtomicMarkableReference 类的<Object,Boolean>，AtomicStampedReference 维护的是一种类似<Object,int>的数据结构，其实就是对对象（引用）的一个并发计数（标记版本戳stamp）。但是与AtomicInteger 不同的是，此数据结构可以携带一个对象引用（Object），并且能够对此对象和计数同时进行原子操作。

这些问题都解决了就有利于我们阅读ConcurrentHashMap的源码了

②产生了内存屏障，防止指令进行了重排序，关于这点的解释，请看下面一段代码：

concurrentHashMap源码解析带来的一系列问题（CAS，volatile ，current包，atomic包）

猜你喜欢