标签：Synchronized CAS unsafe 更新 线程 atomic 操作
Atomic使用了cas机制，避免了volatile修饰的成员变量不是原子性的，count++问题
**一、示例 **
1、多线程示例
2、添加synchronized同步锁
这段代码不是线程安全的，所以最终的自增结果可能会小于200
如果加上同步锁，代码如下：
加了同步锁之后，count自增的操作变成了原子性操作，所以最终的输出一定是count=200，代码实现了线程安全。
synchronized保证了线程安全，但在某些情况下，并不是一个最优选择，因为性能问题
synchronized关键字会让没有得到锁资源的线程进入blocked状态，而后得到锁之后，恢复为runnable状态，这个过程中涉及到操作系统用户模式和内核模式的转换，代价比较高
java1.6为synchronized做了优化，增加了从偏向锁，到轻量级锁，再到重量级锁的过度，但是在最终转变为重量级锁之后，性能仍然较低。
3、使用Atomic原子操作类
可以使用原子操作类代替synchronized同步锁
所谓原子操作类，指的是java.util.concurrent.atomic包下，一系列以Atomic开头的包装类。例如AtomicBoolean，AtomicInteger，AtomicLong。它们分别用于Boolean，Integer，Long类型的原子性操作。
使用AtomicInteger之后，最终的输出结果同样可以保证是200。并且在某些情况下，代码的性能会比Synchronized更好。
Atomic原子操作类底层使用的就是CAS机制
二、Cas机制
1、什么是CAS？
CAS是英文单词Compare And Swap的缩写，翻译过来就是比较并替换。
CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。
更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。
这样说或许有些抽象，我们来看一个例子：
1.在内存地址V当中，存储着值为10的变量
2.此时线程1想要把内存中变量的值增加1。对线程1来说，旧的预期值A=10，要修改的新值B=11
3.在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11
4.线程1开始提交更新，首先进行旧值A和地址V的实际值比较（Compare），发现旧值A不等于V的实际值，提交失败。
5.线程1重新获取内存地址V的当前值，并重新计算想要修改的新值。此时对线程1来说，此时，旧值A=11，新值B=12，内存中当前值V=11。这个重新尝试的过程被称为自旋。
6.这一次比较幸运，没有其他线程改变地址V的值。线程1进行Compare，发现旧值A和地址V的实际值是相等的。
7.线程1进行SWAP，把地址V的值替换为B，也就是12。
2、CPU指令对CAS的支持
或许我们可能会有这样的疑问，假设存在多个线程执行CAS操作并且CAS的步骤很多，有没有可能在判断V和E相同后，正要赋值时，切换了线程，更改了值。造成了数据不一致呢？
答案是否定的，因为CAS是一种系统原语，原语属于操作系统用语范畴，是由若干条指令组成的，用于完成某个功能的一个过程，并且原语的执行必须是连续的，在执行过程中不允许被中断，也就是说***CAS是一条CPU的原子指令，不会造成所谓的数据不一致问题
3、CAS和Synchronized的区别是什么
从思想上来说，Synchronized属于悲观锁，悲观地认为程序中的并发情况严重，所以严防死守。
CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去尝试更新。
4、适合什么样的场景？
CAS机制与synchronized同步锁没有绝对的好坏，关键是要看使用场景
在并发量非常高的情况下，反而使用同步锁更合适
CAS机制的使用场景
Atomic原子操作类，lock系列类的底层实现，java1.6版本以上中synchronized转变为重量级锁之前，也会使用CAS机制
5、有什么优缺点？
CAS机制的缺点：
1.CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。
这也是为什么在高并发情况下，建议使用synchronized同步锁
2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。
3.ABA问题
这是CAS机制最大的问题所在。
但怎么保证在比较之后，更新替换之前，这段时间的线程安全呢？
AtomicInteger 进行的CAS操作，底层调用了unsafe.compareAndSwapInt 方法，unsafe提供了硬件级别的原子操作。
进行A和地址V的实际值比较（Compare），发现A不等于V的实际值，提交失败。
如果发现相等，随即是不是就拿到锁，然后提交值呢？否则的话，比较完了之后提交之前这段时间如果被线程2抢先提交了呢？
CAS是没有锁的。像文中说的，比较和提交是利用了unsafe的方法，保证了原子性操作。
并发同时修改同一个变量还是太危险。个人倾向于用queue把更新操作串起来，一个一个顺序消费掉。
用队列也是一个不错的方法，某些秒杀活动的库存控制，就是用队列实现的
三、Java当中CAS的底层实现
CAS的底层是怎么实现的，比如AtomicInteger，是怎么做到原子性的比较和更新一个值的
AtomicInteger当中常用的自增方法 incrementAndGet，显示如下：
这段代码是一个无限循环，也就是CAS的自旋。循环体当中做了三件事：
1.获取当前值。
2.当前值+1，计算出目标值。
3.进行CAS操作，如果成功，则跳出循环，如果失败，则重复上述步骤。
这里需要注意的重点是 get 方法，这个方法的作用是获取变量的当前值。
如何保证获得的当前值是内存中的最新值呢？很简单，用volatile关键字来保证。有关volatile关键字的知识，我们之前有介绍过，这里就不详细阐述了。
compareAndSet方法的实现很简单，只有一行代码。这里涉及到两个重要的对象，一个是unsafe，一个是valueOffset。
1、什么是unsafe呢？
Java语言不像C，C++那样可以直接访问底层操作系统，但是JVM为我们提供了一个后门，这个后门就是unsafe。unsafe为我们提供了硬件级别的原子操作。
2、至于valueOffset对象，是通过unsafe.objectFieldOffset方法得到，所代表的是AtomicInteger对象value成员变量在内存中的偏移量
我们可以简单地把valueOffset理解为value变量的内存地址。
我们在上一期说过，CAS机制当中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。
而unsafe的compareAndSwapInt方法参数包括了这三个基本元素：
valueOffset参数代表了V，expect参数代表了A，update参数代表了B。
unsafe提供了硬件级别的原子操作
正是unsafe的compareAndSwapInt方法保证了Compare和Swap操作之间的原子性操作。
四、CAS的ABA问题和解决方法
1、什么是ABA问题
ABA问题，就是一个变量的值从A改成了B，又从B改成了A
1、什么是ABA呢？假设内存中有一个值为A的变量，存储在地址V当中。
2、此时，有三个线程想使用CAS的方式更新这个变量值，每个线程的执行时间有略微的偏差。线程1和线程2已经获得当前值，线程3还未获得当前值。
3、接下来，线程1先一步执行成功，把当前值成功从A更新为B；同时线程2因为某种原因被阻塞住，没有做更新操作；线程3在线程1更新之后，获得了当前值B。
4、再之后，线程2仍然处于阻塞状态，线程3继续执行，成功把当前值从B更新成了A。
5、最后，线程2终于恢复了运行状态，由于阻塞之前已经获得了“当前值”A，并且经过compare检测，内存地址V中的实际值也是A，所以成功把变量值A更新成了B
这个过程中，线程2获取到的变量值A是一个旧值，尽管和当前的实际值相同，但内存地址V中的变量已经经历了A->B->A的改变。
然后由线程2最终将A改为B
这个例子本来就是将A更新为B，表面上看起来没什么问题，但实际应用中就会存在问题
2、实际应用中存在问题
当我们举一个提款机的例子。
1、假设有一个遵循CAS原理的提款机，小灰有100元存款，要用这个提款机来提款50元。
2、由于提款机硬件出了点小问题，小灰的提款操作被同时提交两次，开启了两个线程，两个线程都是获取当前值100元，要更新成50元。
理想情况下，应该一个线程更新成功，另一个线程更新失败，小灰的存款只被扣一次。
3、线程1首先执行成功，把余额从100改成50。线程2因为某种原因阻塞了。这时候，小灰的妈妈刚好给小灰汇款50元。
4、线程2仍然是阻塞状态，线程3执行成功，把余额从50改成100。
5、线程2恢复运行，由于阻塞之前已经获得了“当前值”100，并且经过compare检测，此时存款实际值也是100，所以成功把变量值100更新成了50。
原本线程2应当提交失败，小灰的正确余额应该保持为100元，结果由于ABA问题提交成功了，余额变成了50，相当于进行了两次成功的扣除50的操作
3、如何解决ABA问题？
加一个版本号就可以了
什么意思呢？真正要做到严谨的CAS机制，我们在Compare阶段不仅要比较期望值A和地址V中的实际值，还要比较变量的版本号是否一致。
我们仍然以最初的例子来说明一下
1、假设地址V中存储着变量值A，当前版本号是01。线程1获得了当前值A和版本号01，想要更新为B，但是被阻塞了。
2、这时候，内存地址V中的变量发生了多次改变，版本号提升为03，但是变量值仍然是A
3、随后线程1恢复运行，进行Compare操作。经过比较，线程1所获得的值和地址V的实际值都是A，但是版本号不相等，所以这一次更新失败。
在Java当中，AtomicStampedReference类就实现了用版本号做比较的CAS机制。
五、ConcurrentHashMap在1.8为什么用CAS+Synchronized取代Segment+ReentrantLock了
首先,我假设你对CAS,Synchronized,ReentrantLock这些知识很了解,并且知道AQS,自旋锁,偏向锁,轻量级锁,重量级锁这些知识,也知道Synchronized和ReentrantLock在唤醒被挂起线程竞争的时候有什么区别
首先我们说下1.8以前的ConcurrentHashMap是怎么保证线程并发的,首先在初始化ConcurrentHashMap的时候,会初始化一个Segment数组,容量为16,而每个Segment呢,都继承了ReentrantLock类,也就是说每个Segment类本身就是一个锁,之后Segment内部又有一个table数组,而每个table数组里的索引数据呢,又对应着一个Node链表.
那么这样的好处是什么呢?我先从老版本的添加流程说起吧,由于电脑里没有JDK1.7及以下的版本我没法给你看代码,所以使用文字描述的方式,首先,当我们使用put方法的时候,是对我们的key进行hash拿到一个整型,然后将整型对16取模,拿到对应的Segment,之后调用Segment的put方法,然后上锁,请注意,这里lock()的时候其实是this.lock(),也就是说,每个Segment的锁是分开的
其中一个上锁不会影响另一个,此时也就代表了我可以有十六个线程进来,而ReentrantLock上锁的时候如果只有一个线程进来,是不会有线程挂起的操作的,也就是说只需要在AQS里使用CAS改变一个state的值为1,此时就能对代码进行操作,这样一来,我们等于将并发量/16了.
请注意Synchronized上锁的对象,请记住,Synchronized是靠对象的对象头和此对象对应的monitor来保证上锁的,也就是对象头里的重量级锁标志指向了monitor,而monitor呢,内部则保存了一个当前线程,也就是抢到了锁的线程.
那么这里的这个f是什么呢?f一定是链表的头结点，即该元素在Node数组中。所以这里锁住的是hash冲突那条链表。（
它是Node链表里的每一个Node,也就是说,Synchronized是将每一个Node对象作为了一个锁,这样做的好处是什么呢?将锁细化了,也就是说,除非两个线程同时操作一个Node,注意,是一个Node而不是一个Node链表哦,那么才会争抢同一把锁.）
如果使用ReentrantLock其实也可以将锁细化成这样的,只要让Node类继承ReentrantLock就行了,这样的话调用f.lock()就能做到和Synchronized(f)同样的效果,但为什么不这样做呢?
请大家试想一下,锁已经被细化到这种程度了,那么出现并发争抢的可能性还高吗?还有就是,哪怕出现争抢了,只要线程可以在30到50次自旋里拿到锁,那么Synchronized就不会升级为重量级锁,而等待的线程也就不用被挂起,我们也就少了挂起和唤醒这个上下文切换的过程开销.
但如果是ReentrantLock呢?它则只有在线程没有抢到锁,然后新建Node节点后再尝试一次而已,不会自旋,而是直接被挂起,这样一来,我们就很容易会多出线程上下文开销的代价.当然,你也可以使用tryLock(),但是这样又出现了一个问题,你怎么知道tryLock的时间呢?在时间范围里还好,假如超过了呢?
所以,在锁被细化到如此程度上,使用Synchronized是最好的选择了.这里再补充一句,Synchronized和ReentrantLock他们的开销差距是在释放锁时唤醒线程的数量,Synchronized是唤醒锁池里所有的线程+刚好来访问的线程,而ReentrantLock则是当前线程后进来的第一个线程+刚好来访问的线程.
如果是线程并发量不大的情况下,那么Synchronized因为自旋锁,偏向锁,轻量级锁的原因,不用将等待线程挂起,偏向锁甚至不用自旋,所以在这种情况下要比ReentrantLock高效
六、总结
-
Java语言CAS底层如何实现？
利用unsafe提供了原子性操作方法。 -
什么是ABA问题？怎么解决？
当一个值从A更新成B，又更新会A，普通CAS机制会误判通过检测。
利用版本号比较可以有效解决ABA问题。
标签：Synchronized,CAS,unsafe,更新,线程,atomic,操作 来源： https://www.cnblogs.com/askfb/p/15303693.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。