各种锁名词详解

重入锁

在并发中，无论是synchronized还是lock也好，内部都有重入的特性，而且特性的含义是一样的。

重入（re-entrant），同一个线程可以获取已持有的锁；

已知的有两种出现场景： 
1、加锁方法调用另外一个加锁方法； 
2、递归调用加锁方法；

归根结底，就是一个加锁方法调用了另外一个加锁方法；

如果没有重入的特性：

public class ReentrantTest {
    public static void main (String[] args) {
        new Thread(new TestRunnable()).start();
    }

   static class TestRunnable implements Runnable {
        @Override
        public void run () {
            Test.say();
        }
    }

    static class Test {
        public static synchronized void say() {
            dosomething();
        }
        public static synchronized void dosomething() {
        }
    }
}

如果synchronized 没有重入特性，执行say方法时线程获取到Test的锁，调用dosomething的时候，再次获取锁，因为没有重入锁特性，导致无法获取到锁，线程就会死锁，这样就会出错。

所以重入锁是为了解决重复获取锁的问题的，线程对象是当前持锁对象。

独占锁与共享锁

独占锁与共享锁，线程对象是多个线程； 
独占锁，从名字上就可以知道，一个线程获取了锁，其它线程就不能获取到锁，必须等锁释放了，才能可能获取到锁。

举个例子：

沙漠中有一杯水，有十个旅行者，都想喝水，但是同时只能一个人拿起水杯喝水，一个人喝完，第二个人才能喝水。

共享锁，是可以多个线程获取到锁，但是任何东西都不是无限制的，不是任何线程都可以共享锁。

举个例子：

图书馆里有一本书，各个楼层的书馆室内的电脑，都可以查到这个本书的信息，不是只能一台电脑查完，其它书馆室的电脑才能查询这本数的信息；但是也不是任何电脑都能查询这本数的信息，学生自己带到图书馆的电脑就不能查询书的信息。

后面有一个ReentrantReadWriteLock就是这种锁机制，后面详细学习的时候，再好好了解这个接口。

公平锁与非公平锁

公平锁与非公平锁，对象也是多个线程。

什么是公平？ 
简而言之，付出多的，应该得到回报，在日常购物排队中，因为排在前面的比排在后面的等的时间长（相邻两个人，前面一个相对与后面一个）， 最先结账的应该是排在最前面的。

公平锁，按照上面的逻辑来安排获取锁的话，应该先启动的先获取锁，后启动的后获取锁。

非公平锁，就是不排队，都去结账，谁抢到了位置（获取到锁），谁就去结账（执行代码）；

这些逻辑体现在代码上，就是当线程释放了锁，需要从等待线程队列中取出线程用来获取锁的逻辑，是取等待线程中最先启动的，还是都取出来，自由竞争。

乐观锁和悲观锁

首先我们理解下两种不同思路的锁，乐观锁和悲观锁。
这两种锁机制，是在多用户环境并发控制的两种所机制。下面看百度百科对乐观锁和悲观锁两种锁机制的定义：

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
悲观锁（Pessimistic Lock），正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

简而言之：
悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。[1]
乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。
Java中的乐观锁和悲观锁：我们都知道，cpu是时分复用的，也就是把cpu的时间片，分配给不同的thread/process轮流执行，时间片与时间片之间，需要进行cpu切换，也就是会发生进程的切换。切换涉及到清空寄存器，缓存数据。然后重新加载新的thread所需数据。当一个线程被挂起时，加入到阻塞队列，在一定的时间或条件下，在通过notify()，notifyAll()唤醒回来。在某个资源不可用的时候，就将cpu让出，把当前等待线程切换为阻塞状态。等到资源(比如一个共享数据）可用了，那么就将线程唤醒，让他进入runnable状态等待cpu调度。这就是典型的悲观锁的实现。独占锁是一种悲观锁，synchronized就是一种独占锁，它假设最坏的情况，并且只有在确保其它线程不会造成干扰的情况下执行，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。
但是，由于在进程挂起和恢复执行过程中存在着很大的开销。当一个线程正在等待锁时，它不能做任何事，所以悲观锁有很大的缺点。举个例子，如果一个线程需要某个资源，但是这个资源的占用时间很短，当线程第一次抢占这个资源时，可能这个资源被占用，如果此时挂起这个线程，可能立刻就发现资源可用，然后又需要花费很长的时间重新抢占锁，时间代价就会非常的高。
所以就有了乐观锁的概念，他的核心思路就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。在上面的例子中，某个线程可以不让出cpu,而是一直while循环，如果失败就重试，直到成功为止。所以，当数据争用不严重时，乐观锁效果更好。比如CAS就是一种乐观锁思想的应用。
JDK1.5中引入了底层的支持，在int、long和对象的引用等类型上都公开了CAS的操作，并且JVM把它们编译为底层硬件提供的最有效的方法，在运行CAS的平台上，运行时把它们编译为相应的机器指令。在java.util.concurrent.atomic包下面的所有的原子变量类型中，比如AtomicInteger，都使用了这些底层的JVM支持为数字类型的引用类型提供一种高效的CAS操作。
在CAS操作中，会出现ABA问题。就是如果V的值先由A变成B，再由B变成A，那么仍然认为是发生了变化，并需要重新执行算法中的步骤。有简单的解决方案：不是更新某个引用的值，而是更新两个值，包括一个引用和一个版本号，即使这个值由A变为B，然后为变为A，版本号也是不同的。AtomicStampedReference和AtomicMarkableReference支持在两个变量上执行原子的条件更新。AtomicStampedReference更新一个“对象-引用”二元组，通过在引用上加上“版本号”，从而避免ABA问题，AtomicMarkableReference将更新一个“对象引用-布尔值”的二元组。

总结

了解上面的概念之后，对学习相关的类有很大帮助，对面试也有很大帮助。