Java悲观锁和乐观锁

悲观的并发策略——Synchronized互斥锁

互斥锁是最常见的同步手段，在并发过程中，当多条线程对同一个共享数据竞争时，它保证共享数据同一时刻只能被一条线程使用，其他线程只有等到锁释放后才能重新进行竞争。

synchronized就是一个典型的互斥锁，同时它也是一个JVM级别的锁，它的实现细节全部封装在JVM中实现，对开发人员只提供了synchronized关键词。根据锁的颗粒度，可以用synchronized对一个变量、一个方法、一个对象和一个类等加锁。被synchronized修饰的程序块经过编译后，会在前后生成monitorenter和monitorexit两个字节码指令，其中涉及到锁定和解锁对象的确定，这就要根据synchronized来确定了，假如明确指定了所对象，例如synchronized(变量)、synchronized(this)等，说明加解锁对象为变量或运行时对象。假如没有明确指定对象，则根据synchronized修饰的方法去找对应的锁对象，如修饰一个非静态方法表示此方法对应的对象为锁对象，如修饰一个静态方法则表示此方法对应的类对象为锁对象。当一个对象被锁住时，对象里面所有用synchronized修饰的方法都将产生堵塞，而对象里非synchronized修饰的方法可正常被调用，不收锁影响。
Synchronized还有另外一个重要的特性——可重入性。这个特性主要是针对当前线程而言的，可重入即是自己可以再次获得自己的内部锁，在尝试获取对象锁时，如果当前线程已经拥有了此对象的锁，则把锁的计数器加一，在释放锁时则对应地减一，当锁计数器为0时表示锁完全被释放，此时其他线程可对其加锁。可重入特性是为了解决自己锁死自己的情况，如下面伪代码：

public class DeadLock{

public synchronized void method1(){}

public synchronized void method2(){

this.method1();

}

public static void main(String[] args){

DeadLock deadLock=new DeadLock();

deadLock.method2();

}

}

这种情况其实也并非不常见，一个类中的同步方法调用另一个同步方法，假如synchronized不支持重入，进入method2方法时当前线程将尝试获取deadLock对象的锁，而method2方法里面执行method1方法时，当前线程又要去尝试获取deadLock对象的锁，这时由于不支持重入，它要去等deadLock对象的锁释放，把自己阻塞了，这就是自己锁死自己的现象。所以重入机制的引入，杜绝了这种情况的发生。

synchronized实现的是一个非公平锁，非公平主要表现在获取锁的行为上，并非是按照申请锁的时间前后给等待线程分配锁的，每当锁被释放后，任何一个线程都有机会竞争到锁，这样做的目的是为了提高执行性能，当然也会产生线程饥饿现象。

synchronized最后一个特性（缺点）就是不可中断性，在所有等待的线程中，你们唯一能做的就是等，而实际情况可能是有些任务等了足够久了，我要取消此任务去干别的事情，此时synchronized是无法帮你实现的，它把所有实现机制都交给了JVM，提供了方便的同时也体现出了自己的局限性。

https://www.kancloud.cn/seaboat/java-concurrent/117869

乐观的并发策略——基于CAS的自旋

Synchronized互斥锁属于悲观锁，它有一个明显的缺点，它不管数据存不存在竞争都加锁，随着并发量增加，且如果锁的时间比较长，其性能开销将会变得很大。有没有办法解决这个问题？答案是基于冲突检测的乐观锁。这种模式下，已经没有所谓的锁概念了，每条线程都直接先去执行操作，计算完成后检测是否与其他线程存在共享数据竞争，如果没有则让此操作成功，如果存在共享数据竞争则可能不断地重新执行操作和检测，直到成功为止，可叫CAS自旋。

乐观锁的核心算法是CAS（Compareand Swap，比较并交换），它涉及到三个操作数：内存值、预期值、新值。当且仅当预期值和内存值相等时才将内存值修改为新值。这样处理的逻辑是，首先检查某块内存的值是否跟之前我读取时的一样，如不一样则表示期间此内存值已经被别的线程更改过，舍弃本次操作，否则说明期间没有其他线程对此内存值操作，可以把新值设置给此块内存。
CAS肯定是具有原子性的，不然就谈不上在并发中使用了，但这个原子性是由CPU硬件指令实现保证的，即使用JNI调用native方法调用由C++编写的硬件级别指令，jdk中提供了Unsafe类执行这些操作。另外，你可能想着CAS是通过互斥锁来实现原子性的，这样确实能实现，但用这种方式来保证原子性显示毫无意义。
CAS虽然很高效的解决原子操作，但是CAS仍然存在三大问题。ABA问题，循环时间长开销大和只能保证一个共享变量的原子操作
1. ABA问题。因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。
从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
关于ABA问题参考文档: http://blog.hesey.net/2011/09/resolve-aba-by-atomicstampedreference.html
2. 循环时间长开销大。自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

3. 只能保证一个共享变量的原子操作。当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

在研究AQS框架时，会发现这个类很多地方都使用了CAS操作，在并发实现中CAS操作必须具备原子性，而且是硬件级别的原子性，java被隔离在硬件之上，明显力不从心，这时为了能直接操作操作系统层面，肯定要通过用C++编写的native本地方法来扩展实现。JDK提供了一个类来满足CAS的要求，sun.misc.Unsafe，从名字上可以大概知道它用于执行低级别、不安全的操作，AQS就是使用此类完成硬件级别的原子操作。

Unsafe是一个很强大的类，它可以分配内存、释放内存、可以定位对象某字段的位置、可以修改对象的字段值、可以使线程挂起、使线程恢复、可进行硬件级别原子的CAS操作等等，但平时我们没有这么特殊的需求去使用它，而且必须在受信任代码（一般由JVM指定）中调用此类，例如直接Unsafe unsafe = Unsafe.getUnsafe();获取一个Unsafe实例是不会成功的，因为这个类的安全性很重要，设计者对其进行了如下判断，它会检测调用它的类是否由启动类加载器Bootstrap ClassLoader（它的类加载器为null）加载，由此保证此类只能由JVM指定的类使用。

public static Unsafe getUnsafe() {

Class cc = sun.reflect.Reflection.getCallerClass(2);

if (cc.getClassLoader() != null)

throw new SecurityException(“Unsafe”);

return theUnsafe;

}

https://www.kancloud.cn/seaboat/java-concurrent/117870

http://blog.csdn.net/tangyongzhe/article/details/42084297