乐观锁与悲观锁

悲观锁：每次访问数据线程都是处于阻塞的状态，这样提高安全性，像读锁，写锁都是用到了悲观锁，以及synchronize关键字（独占锁）；
缺点：

1. 可能会导致优先级高的线程等待优先级低的线程导致优先级倒序；
2. 加锁，放锁次数过多，引起性能问题

乐观锁：每次访问数据线程都是运行状态，这样可以提高数据吞吐量。就假定不会发生并发冲突，最后通过比较数据来查看是否真的发生了冲突，并交由用户来决定。最典型的实现方式是CAS（compare and swap）
像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
问题：
1. ABA 问题：JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
2. 只能保证一个共享变量的原子操作：CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。

    原来乐观锁与悲观锁并不是特指某个锁，而是在并发情况下保证数据完整性的不同策略。悲观锁指的就是我们平常使用的加锁机制，它假设我们总是处于最坏的情况下，如果不加锁数据完整性就会被破坏。而乐观锁指是一种基于冲突检测的方法，检测到冲突时操作就会失败。

ReentrantLock

• lock()获得锁
• lockInterruptibly()获得锁，但优先响应中断
• tryLock()尝试获得锁，成功返回true,否则false，该方法不等待，立即返回
• tryLock(long time,TimeUnit unit)在给定时间内尝试获得锁
• unlock()释放锁
• ReentrantLock.lockInterruptibly允许在等待时由其它线程调用等待线程的Thread.interrupt方法来中断等待线程的等待而直接返回，这时不用获取锁，而会抛出一个InterruptedException。 ReentrantLock.lock方法不允许Thread.interrupt中断,即使检测到Thread.isInterrupted,一样会继续尝试获取锁，失败则继续休眠。只是在最后获取锁成功后再把当前线程置为interrupted状态,然后再中断线程。

Condition

• Condition：await()、signal()方法分别对应之前的Object的wait()和notify()
• 和重入锁一起使用
• await()是当前线程等待同时释放锁
• awaitUninterruptibly()不会在等待过程中响应中断
• signal()用于唤醒一个在等待的线程，还有对应的singalAll()方法
  ReentrantLock和Synchronize区别：
  锁的实现：
      Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的，有什么区别，说白了就类似于操作系统来控制实现和用户自己敲代码实现的区别。前者的实现是比较难见到的，后者有直接的源码可供阅读。
  便利性：
      很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
  ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。
  共同点：
      都是可重入锁，所谓可重入，意味着线程可以进入它已经拥有的锁的同步代码块儿。

乐观锁一般会使用版本号机制或CAS（Compare-and-Swap，即比较并替换）算法实现。
    版本号机制一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
    CAS（Compare And Swap）是一种常见的“乐观锁”，大部分的CPU都有对应的汇编指令，它有三个操作数：内存地址V，旧值A，新值B。只有当前内存地址V上的值是A，B才会被写到V上，否则操作失败。
接下来看一个使用CAS实现线程安全的计数器的例子。

public class CasCounter {
    private SimulatedCAS value;
    public int getValue() {
        return value.get();
    }
    public int increment() {
        int v;
        do {
            v = value.get();
        }
        while (v != value.compareAndSwap(v, v + 1));
        return v + 1;
    }   
}   
public class SimulatedCAS {
　　private int value;
　　public synchronized int get() { return value; }
　　public synchronized int compareAndSwap(int expectedValue, int newValue) {
　　　　int oldValue = value;
　　　　if (oldValue == expectedValue)
　　　　　　value = newValue;
　　　　return oldValue;
　　}
}

在并发数不是特别高的情况下，使用CAS的乐观锁在性能上要优于使用加锁方式的悲观锁，因为大部分情况下经过数次轮询后CAS操作都可以成功，而使用加锁机制则会造成线程的阻塞与调度，相对而言更耗时。

Java从5.0开始引入了对CAS的支持，与之对应的是 java.util.concurrent.atomic 包下的AtomicInteger、AtomicReference等类，它们提供了基于CAS的读写操作和并发环境下的内存可见性。

public class ConcurrentStack <E> {
    AtomicReference<Node<E>> top = new AtomicReference<>();
    public void push(E item) {
        Node<E> newHead = new Node<E>(item);
        Node<E> oldHead;
        do {
            oldHead = top.get();
            newHead.next = oldHead;
        } while (!top.compareAndSet(oldHead, newHead));
    }
    public E pop() {
        Node<E> oldHead;
        Node<E> newHead;
        do {
            oldHead = top.get();
            if (oldHead == null)
                return null;
            newHead = oldHead.next;
        } while (!top.compareAndSet(oldHead, newHead));
        return oldHead.item;
    }
}
public class Node <E> {
    public final E item;
    public Node<E> next;
    public Node(E item) {
        this.item = item;
    }
}

这个栈实际上是一个单链表结构，变量 top 代表头节点。当 push() 被调用后，首先新建一个节点 newHead ，它的后继节点应该为当前的头节点。然后使用CAS操作尝试将新节点赋值给 top ，如果 top 没有发生变化，CAS操作成功。如果 top 已改变（可能是某个线程加入或移除了元素），CAS操作失败，替换新节点的后继节点为当前的头节点，再次尝试。无论CAS操作是否成功，链表的结构都不会被破坏。