在使用锁时，线程获取锁是一种悲观锁策略，即假设每一次执行临界区代码都会产生冲突，所以当前线程获取到锁的时候同时也会阻塞其他线程获取该锁。而CAS操作是一种乐观锁策略，它假设所有线程访问共享资源的时候不会出现冲突，既然不会出现冲突自然而然就不会阻塞其他线程的操作。因此，线程就不会出现阻塞停顿的状态，那么这种情况下出现冲突了怎么办？无锁操作是使用CAS（compare and swap）又叫做比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操作直到没有冲突为止。

CAS可以通俗的理解为CAS（V,O,N）其中包含三个值分别是 V：内存地址中实际存放的值； O：预期的值； N：更新后的值。

  当V==O相同时，也就是说预期值和内存中实际的值相同，表明该值没有被其他线程更改过，即预期值O就是目前来说最新的值了，可以将N赋给V。   当V!=O不相同，表明V值已经被其他线程改过了，即预期值0不是最新值了，所以不能将新值N赋给V，返回V值，将O值改为V。

  当多个线程使用CAS操作一个变量时，只有一个线程会成功并成功更新，其余会失败，失败的线程会重新尝试（自旋），当然也可以选择挂起线程（阻塞）。

未优化的synchronized最主要的问题是：   在存在线程竞争的情况下会出现线程阻塞和唤醒锁带来的性能问题，这是一种互斥同步（阻塞同步）   而CAS并不是武断的将线程挂起，当CAS操作失败后会进行一定的尝试，而非进行耗时的挂起唤醒的操作，因此也叫做非阻塞同步。

  线程1准备用CAS将变量的值由A替换为B，在此之前，线程2将变量的值由A替换为C，又由C替换为A，然后线程1执行CAS时发现变量的值仍然为A，所以CAS成功。但实际上这时的现场已经和最初不同了。   例如一个单向链表： 解决方案：   atomic包中提供了AtomicStampedReference来解决ABA问题相当于添加了版本号

  与线程阻塞相比，自旋会浪费大量的处理器资源。这是因为当前线程仍处于运行状况，只不过跑的是无用指令。它期望在运行无用指令的过程中，锁能够被释放出来。

  例如：阻塞相当于熄火停车，自旋状态相当于怠速停车。在十字路口，如果红绿灯等待的时间非常长，那么熄火相对省油一些；如果红绿灯的等待时间非常短，怠速停车更合适。   然而，对于JVM来说，它并不能看到红灯的剩余时间，也就没法根据等待时间的长短来选择是自旋还是阻塞，JVM给出的方案是自适应自旋，根据以往自旋等待时能否获取锁，来动态调整自旋的时间。即就是如果在自旋的时候获取到锁，则会增加下一次自旋的时间，否则就稍微减小下一次自旋时长，对于我们的例子就是：如果之前不熄火等待了绿灯，那么这次不熄火的时间就长一点；如果之前不熄火没等待绿灯，那么这次不熄火的时间就短一点。

  自旋状态还带来另外一个副作用，不公平的锁机制。处于阻塞状态的线程，无法立刻竞争被释放的锁。然而处于自旋状态的线程，则很有可能优先获得这把锁。内建锁无法实现公平机制 Lock锁可以

  同步的时候是获取对象的monitor，即获取到对象的锁，对象的锁无非就是类似对对象的一个标志，这个标志就是存在Java对象的对象头中。Java对象头里的Mark Word里（markword是java对象数据结构中的一部分）默认存放是的对象的Hashcode，分代年龄和锁标记位。32位JVM对象头中 Mark Word默认存储结构为：

  Java SE 1.6中，锁一共有四种状态，级别从低到高依次是：无锁状态（0 01），偏向锁状态（1 01），轻量级锁状态（00）和重量级锁状态（10），这几个状态会随着竞争情况逐渐升级，锁可以升级但是不可以降级（为了提高获得锁和释放锁的效率）

  大多数情况下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。JDK1.6之后 偏向锁默认开启 偏向锁是锁状态中最乐观的一种锁：从始至终只有一个线程请求同一把锁 偏向锁对象头的Mark Word：

偏向锁的获取过程：   当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后在该线程进入和退出同步块时不需要CAS操作来加锁和解锁，只需要简单的测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标志是否设置成1，如果没有设置，使用CAS竞争锁，如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁的撤销过程：   偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。

  多个线程在不同时刻请求同一把锁，也就是不存在锁竞争的情况。针对这种状况，JVM采用了轻量级锁来避免线程的阻塞与唤醒 轻量级锁的Mark Word：

  线程在执行同步块之前，JVM会先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获取到锁。如果失败，表示其他线程竞争锁。

  轻量级锁解锁时，会使用原子的CAS操作将Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁(多个线程在相同时刻竞争同一把锁)。

偏向锁   偏向锁只会在第一次请求锁时使用CAS操作，并在锁对象的标记字段中记录当前线程ID。在此后的运行过程中，持有偏向锁的线程无需加锁操作。针对的是锁仅会被同一线程持有的状况。 轻量级锁   轻量级锁采用CAS操作，将对象头中的Mark Word替换为指向锁记录的指针。针对的是多个线程在不同时间段申请同一把锁的情况。 重量级锁   重量级锁会阻塞、唤醒请求加锁的线程。针对的是多个线程同时竞争同一把锁的情况。JVM采用自适应自旋，来避免在面对非常小的同步代码块时，仍会被阻塞和唤醒的状况。

  锁粗化就是将多次连接在一起的加锁、解锁操作合并为一次操作。将多个联系的锁扩展为一个范围更大的锁。

每次调用StringBuffer的append方法都需要加锁和解锁，如果虚拟机检测到有一系列连串的对同一对象加锁和解锁操作，就会在在第一次append方法时进行加锁，在最后一次append方法结束后进行解锁。

  删除不必要的加锁操作，如果判断一段代码中，堆上的数据不会逃逸出当前线程，则认为此代码是线程安全的，无需加锁

此时虽然append是同步方法，但是这段程序中StringBuffer属于一个局部变量，即每个线程进入此方法都会拥有一个StringBuffer的变量，互不影响，线程安全