乐观锁和悲观锁
悲观锁乐观锁 CAS
模拟CAS算法CAS中的ABA问题使用CAS会引发的问题 Synchronized锁优化
偏向锁轻量级锁重量级锁 乐观锁和悲观锁 悲观锁
总是假设最坏的情况，每次在去获取共享数据的时候都认为别人会修改，所以每次都在获取数据的时候加锁。传统的关系型数据库里就用到很多这种锁，比如行锁，表锁、读锁、写锁等都是在操作之前先上锁，比如java中Synchronized关键字的实现也是悲观锁。
悲观锁存在的问题：
在多线程竞争下，加锁，释放锁会导致比较多的上下文切换和调度延迟，引起性能问题
一个线程持有锁会导致其他需要此锁的线程挂起(阻塞)。
认为数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会对数据是否产生并发冲突进行检测，如果发现并发冲突，则返回错误信息，需要用户去决定如何操作。
乐观锁实现的典型是CAS（Compare and Swap）。
具有原子特性
CAS是乐观锁的实现技术，当多个线程尝试使用CAS同时更新同一个变量，只有一个线程能更新变量的值，而其他的线程都失败，失败的线程不会被挂起，而是被告知这次竞争失败了，并可以再次进行尝试
CAS操作中涉及三个操作数：
● 需要读写的内存位置（V）
● 需要比较的预期原值（A）
● 拟写入的新值（B）
如果内存位置V的值与预期原值A相匹配，那么处理器会自动的将该位置值更新为B，否则处理器不做任何处理。
第一步：获取位置V的值A。
第二步：将获取的值A和位置V的内容进行比较，
如果相等，认为没有其他线程修改该位置，即不存在并发竞争，就可以将新值B写入位置V。
如果不相等，说明存在其他的线程在对该位置进行并发操作。不能直接修改，继续跳转第一步，获取位置V的值，在进行比较，直至相等是修改为B。
public class CompareAndSwap { private int value; //获取内存值 public synchronized int getValue() { return value; } //比较并交换 public synchronized int compareAndSwap(int expectValue,int newV) { int oldV = value; //如果内存值和预期值一致，就替换 if (oldV == expectValue) this.value = newV; return oldV; } //设置 调用比较并交换， 看期望值和原来的值是否一致 public synchronized boolean compareAndSet(int expectValue,int newV){ return expectValue == compareAndSwap(expectValue, newV); }}public class TestCompareAndSwap { public static void main(String[] args) { CompareAndSwap cas = new CompareAndSwap(); for (int i = 0; i < 10; i++) { new Thread(new Runnable() { @Override public void run() { Random random = new Random(); int expectValue = cas.getValue(); int newV = random.nextInt(100); boolean compareAndSet = cas.compareAndSet(expectValue, newV); System.out.println(Thread.currentThread().getName()+ ",预期值："+expectValue+"，待写入值："+newV+"，操作结果："+compareAndSet); } }).start(); } }}
在JDK 1.5中新增了java.util.concurrent（J.U.C）建立在CAS之上，相对于Synchronized是一种线程阻塞处理，CAS是非阻塞的一种常见实现，及线程即使没有获取到变量，也不会进入到阻塞状态。就是在不使用锁的情况下来保证线程安全，在JUC下存在如AtomicInteger为例，其中一些++i操作是安全项操作，getAndIncrement方法。
CAS中的ABA问题 CAS会引起ABA的问题，假如存在如下执行序列：
1、线程1从内存中V取出A
2、线程2从内存中V取出A
3、线程2进行了一些操作，将B写入位置V。
4、线程2将A再次写入位置V
5、线程1进行CAS操作，发现位置V依然是A，进行修改操作并成功
6、尽管线程1的CAS操作成功，但不代表这个过程没有问题–对于线程1，线程2的修改已经丢失了。
一个链表ABA的问题：
1、现有一个单向链表实现的堆栈，栈顶为A。这时线程1已经指导A.next是B，希望通过CAS操作将栈顶替换为B，线程1执行compareAndSwap（A,B）
2、在线程1执行上面指令之前，线程2介入，将A、B出栈，在依次入栈D、C、A，而对象B次数处于游离状态。
3、此时线程1执行CAS操作，检测栈顶认为A，所以CAS成功，栈顶是B，但实际B.next为null,此时堆栈中只有一个B元素，C和D组成的链表就不存在在堆栈中，C、D被丢弃了。
ABA问题的解决方案
ABA问题的解决思路就是使用版本号，在变量上追加一个版本号，每次变量变更把版本号加1，那么A-B-A就会去编程1A-2B-3A。
使用CAS好处就是比使用锁的开销要小，但存在问题
1、ABA的问题
ABA的问题的解决方案是加版本号解决。
2、循环时间开销大
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
3、只能保证一个共享变量的原子操作
当堆一个共享变量执行操作是，可以使用循环CAS的方式保证原子操作，但对于多个共享变量，循环CAS就无法保证操作的原子性，这个时候就需要借助于锁来实现。
在JDK1.5之前，Synchronized的底层实现都是重量级的，也称之为Synchronized为重量级锁，在JDK1.5之后，对Synchronized进行了各种优化，实现的原理是锁升级的过程。偏向锁、轻量级锁和重量级锁。
Java对象的内存布局
Java的对象的内存布局如下：
在Java中，创建一个对象后，在JVM中，对象在内存中的存储布局，分为三块：
对象头区域：存放锁信息、对象年龄等信息。
实例数据区域：存储的是对象的真正有效的信息，比如对象中所有字段内容。
对齐填充区域：JVM规定对象的起始地址必须是8字节的整数倍，如果一个对象实际占用的内存大小不是8字节的整数倍，就“补位”到8字节的整数倍，对齐填充区域的大小不是固定的。
Synchronized用的锁是存在对象头里，如果对象是数组类型，对象头中还包含了数组长度。
如果是数组类型，则虚拟机使用3个字宽存储对象头，如果不是数组类型，则占用2个字宽存储对象头，在32位系统下，1字宽等于4字节即32bit位。
在Java对象头中Mark Word是默认存储对象的Hashcode，分代年龄和锁的标记为，32位JVM中Mark Word默认存储的结构如下图所示：
在Java SE1.6种，锁一共存在4中状态，级别从低到高一次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态随着竞争的情况逐渐升级，锁是可以升级的不能降级，意味着偏向锁升级成轻量级锁在升级为重量级锁，目的是为了获取锁和释放锁的效率。
偏向锁的操作是无序操作系统介入的，每个对象都有对象头，对象头中的Mark Word存储对象的锁信息。
该对象头先处于无锁状态，当有线程来访问，JVM使用CAS操作将线程ID记录到Mark Word中，修改偏向锁的标识位，当前线程就拥有了这把锁。
注意：将线程ID通过CAS记录，变更偏向锁标识为1。
JVM不用和操作系统协商设置monitor，只需要记录下线程ID，就表示当前线程拥有这把锁，不用操作系统介入。
获取锁的线程就可以进入到程序代码块中执行，当线程再次执行时，JVM通过锁对象的Mark Word判断，如果当前线程ID还存在，还持有着这个对象的锁，就直接进入临界区执行，这个就是偏向锁，在没有别的线程竞争的时候，一直偏向当前的线程可以一直执行。
优点：只有一个线程执行同步块时进一步提高性能，适用于一个线程反复获取同一个锁的情况，偏向锁可以提高带有同步但无竞争的程序的性能。
轻量级锁 如果在偏向锁中一个线程A一直执行过程中，此时又来了另一个线程B要进入代码块执行，但是锁对象保存的是线程A的线程ID，还是偏向锁就导致线程B无法执行，这个时候就需要对偏向锁进行升级，变成一个轻量级锁。
JVM把锁对象恢复成无锁状态，在当前的两个线程的栈帧中个分配一个空间，叫做Lock Record,把锁对象的Mark Word在两个线程的栈帧中各复制一份，叫做Displaced Mark Word,将当前线程A的Lock Record的地址使用CAS放到锁对象的Mark Word当中，并且将锁的标识设置为00，意味着当前线程A获取到轻量级锁，可以进入到临界区执行。
线程B没有获取到锁，但不阻塞，JVM会让他自旋几次，等待一会，当线程A退出了临界区释放锁的时候，需要将Displaced Mark Word使用CAS复制回去，接下来线程B就可以通过CAS复制信息。这个时候两个线程就可以交替进入临界区，执行代码。
偏向锁即使出现了竞争，想获取锁只要自旋几次，等待一会，锁就可以是释放，使用CAS和Lock Record就可以避免重量级锁的开销。
优点：绝大部分的锁在整个生命周期中都存在少量竞争，在多线程交替执行同步代码块是可以避免重量级锁引起的性能问题。
重量级锁 轻量级锁在运行时，线程A正在持有锁，另一个线程B自旋了好多次，线程A还没有释放锁，这个时候JVM考虑自旋次数太多浪费CPU，就需要将锁升级为重量级锁。
重量级锁需要操作系统的介入，依赖操作系统底层的mutex lock，JVM会创建一个monitor对象，把这个对象的地址信息更新到Mark Word中，并将锁标志置为10。
线程A还在持有锁运行，线程B直接挂起，线程进入阻塞，释放掉占用的CPU资源。