多线程中的乐观锁、悲观锁

多线程中，共享变量存放于共享内存，各个线程会将其copy到自己的线程内存中，更改数据，最后把线程内存中的数据复制给共享内存。

应用于多线程的乐观锁
乐观的以为每次拿取数据时别人都不会更改数据，但在更新的时候也会以某种方法判断一下有没有人更新这个数据。乐观锁应用于多读少写的场景。
判断有没有人更新数据有两种方法：版本号控制 和 CAS（compare and swap）比较和交换

版本号控制
比如，给数据加一个版本字段，凡线程对其进行数据更新后，版本号+1，当另一个线程对其更新时，会比对一下，共享内存中该数据的版本号，和当前线程中的版本号是否一致，不一致则说明有其他线程对其进行了更新，之后他要重新从内存中获取数据，再进行后续操作。
这个套路也可以用于数据库中数据的更改。

CAS
CAS有三个参考值
V：变量在共享内存中的值
A：线程本地内存的值
B：线程模拟修改变量后的值
CAS机制在更新一个变量的时候，只有当变量在线程本地内存的值A和共享内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。它与版本号控制原理类似，只不过它比较的是值而不是版本号。CAS的开销很大，它的底层有一个自旋锁（其实就是一个while判断），如果V不等于A的时候，它会一直循环，直到V等于A。CAS不能保障代码块的原子性。

CAS会引起ABA问题
假设，三个线程，一个共享变量A，线程1、3会把A变成C，如果线程1执行完后，共享变量变为C，线程3发现共享内存的值C 与 我线程内存的值A 不相等，所以线程3就不会执行，但是这时出现了一个线程2，它在线程1之后、线程3之前，将C又变回了A，那么之后线程3在执行时，发现原本内存的值A又和线程3内存值A相等了，线程3又会执行了，它将A变成了C，但这个C不是通过线程1得到的C。

实际场景，假设有100元，我开启了两个线程，他们执行的内容是，当有100元时，减去50元，这样，理论上两个线程都执行完后，还剩下50元，也就是只扣了一个50元。如果执行当中恰巧有另一个线程乱入了，这个线程执行的内容是增加50元，这个线程刚好排在了那两个线程中间执行，那么，最后一个线程执行时，他发现，-50又+50，共享内存中是100，那他符合执行条件，V=A，它也会执行一遍，最终得到的结果却是，100元被扣了2次50元。

ABA问题 通常的解决办法是添加版本号或时间戳，每次修改操作时版本号加一，这样数据对比的时候就不会出现 ABA 的问题了。

CAS在JAVA中的应用：java.util.concurrent.atomic包
比如 i++ 在多线程中的操