欢迎大家来到IT世界,在知识的湖畔探索吧!

在面试过程时，经常会被问到各种各样的锁，如乐观锁、读写锁等等，非常繁多，锁在Java中是一个非常重要的概念，Java提供了种类丰富的锁，每种锁因其特性的不同，在适当的场景下能够展现出非常高的效率，在当今的互联网时代，尤其在各种高并发的情况下，我们更加离不开锁。那么到底什么是锁呢？在计算机中，锁(lock)或者互斥(mutex)是一种同步机制，用于在有许多执行线程的环境中强制对资源的访问限制。锁可以强制实施排他互斥、并发控制策略。

1、乐观锁/悲观锁

乐观锁与悲观锁并不是特指某两种类型的锁，是人们定义出来的概念或思想，主要是指看待并发同步的角度。

乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS(Compare and Swap 比较并交换)实现的。

　 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。比如Java里面的同步原语synchronized关键字的实现就是悲观锁。

悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。

悲观锁在Java中的使用，就是利用各种锁。

乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。

CAS操作

CAS（Compare and Swap 比较并交换），当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。

CAS操作中包含三个操作数——需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B，否则处理器不做任何操作。

2、独享锁/共享锁

独享锁是指该锁一次只能被一个线程所持有。

共享锁是指该锁可被多个线程所持有。

对于Java ReentrantLock而言，其是独享锁。但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。

读锁的共享锁可保证并发读是非常高效的，读写，写读，写写的过程是互斥的。

独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

对于Synchronized而言，当然是独享锁。

3、互斥锁/读写锁

上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。

互斥锁在Java中的具体实现就是ReentrantLock。

读写锁在Java中的具体实现就是ReadWriteLock。

4、可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。

对于Java ReetrantLock而言，从名字就可以看出是一个重入锁，其名字是Re entrant Lock 重新进入锁。

对于Synchronized而言，也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。

synchronized void setA() throws Exception{Thread.sleep(1000);setB();}synchronized void setB() throws Exception{Thread.sleep(1000);}

欢迎大家来到IT世界,在知识的湖畔探索吧!

上面的代码就是一个可重入锁的一个特点。如果不是可重入锁的话，setB可能不会被当前线程执行，可能造成死锁。

5. 公平锁/非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。

对于Java ReetrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。

对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

6.分段锁

分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。

我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7和JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock）。

当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在哪一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。

但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。

分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。

7.偏向锁/轻量级锁/重量级锁

这三种锁是指锁的状态，并且是针对Synchronized。在Java 5通过引入锁升级的机制来实现高效Synchronized。这三种锁的状态是通过对象监视器在对象头中的字段来表明的。

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。

轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。

重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让他申请的线程进入阻塞，性能降低。

8.自旋锁

在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。

锁的使用

举一个生活中的例子，大家都去超市买东西，如果我们带了包的话，要放到储物柜。我们再把这个例子极端一下，假如柜子只有一个，那么此时同时来了三个人A、B、C都要往这个柜子里放东西。那么这个场景就是一个多线程，多线程自然也就离不开锁。

简单示意图如下

A、B、C都要往柜子里面放东西，可是柜子只能存放一个东西，那么怎么处理？这个时候我们就引出了锁的概念，三个人中谁先抢到了柜子的锁，谁就可以使用这个柜子，其他的人只能等待。比如C抢到了锁，C就可以使用这个柜子，A和B只能等待，等到C使用完毕之后，释放了锁，AB再进行抢锁，谁先抢到了，谁就有使用柜子的权利

抽象成代码

我们其实可以将以上场景抽象程相关的代码模型，我们来看一下以下代码的例子。

柜子中存储的是数字。

然后我们把3个用户抽象成一个类，如下代码

在用户的构造方法中，需要传入两个参数，一个是要使用的柜子，另一个是要存储的数字。以上我们把柜子和用户都已经抽象完毕，接下来我们再来写一个启动类，模拟一下3个用户使用柜子的场景。

我们仔细的看一下这个main函数的过程

首先创建一个柜子的实例，由于场景中只有一个柜子，所以我们只创建了一个柜子实例。

然后我们新建了一个线程池，线程池中一共有三个线程，每个线程执行一个用户的操作。

再来看看每个线程具体的执行过程，新建用户实例，传入的是用户使用的柜子，我们这里只有一个柜子，所以传入这个柜子的实例，然后传入这个用户所需要存储的数字，分别是1,2,3，也分别对应了用户1,2,3。

再调用使用柜子的操作，也就是想柜子中放入要存储的数字，然后立刻从柜子中取出数字，并打印出来。

我们运行一下main函数，看看得到的打印结果是什么？

我是用户1,我存储的数字是：3

我是用户3,我存储的数字是：3

我是用户2,我存储的数字是：2

从结果中，我们可以看出三个用户在存储数字的时候两个都是3，一个是2。这是为什么呢？我们期待的应该是每个人都能获取不同的数字才对。其实问题就是出在”user.useCabinet();”这个方法上，这是因为柜子这个实例没有加锁的原因，三个用户并行执行，向柜子中存储他们的数字，虽然3个用户并行同时操作，但是在具体赋值的时候，也是有顺序的，因为变量storeNumber只有一块内存，storeNumber只存储一个值，存储最后的线程所设置的值。至于哪个线程排在最后，则完全不确定，赋值语句执行完成之后，进入打印语句，打印语句取storeNumber的值并打印，这时storeNumber存储的是最后一个线程锁所设置的值，3个线程取到的值有两个是相同的，就像上面打印的结果一样。

那么如何才能解决这个问题？这就需要我们用到锁。我们再赋值语句上加锁，这样当多个线程（此处表示用户）同时赋值的时候，谁能优先抢到这把锁，谁才能够赋值，这样保证同一个时刻只能有一个线程进行赋值操作，避免了之前的混乱的情况。

那么在程序中，我们如何加锁呢？

下面我们介绍一下Java中的一个关键字synchronized。关于这个关键字，其实有两种用法。

synchronized方法，顾名思义就是把synchronize的关键字写在方法上，它表示这个方法是加了锁的，当多个线程同时调用这个方法的时候，只有获得锁的线程才能够执行，具体如下：

以上我们可以看到getTicket（）方法加了锁，当多个线程并发执行的时候，只有获得锁的线程才可以执行，其他的线程只能够等待。

synchronized代码块。如下：

synchronized (对象锁){

……

}

我们将需要加锁的语句都写在代码块中，而在对象锁的位置，需要填写加锁的对象，它的含义是，当多个线程并发执行的时候，只有获得你写的这个对象的锁，才能够执行后面的语句，其他的线程只能等待。synchronized块通常的写法是synchronized（this），这个this是当前类的实例，也就是说获得当前这个类的对象的锁，才能够执行这个方法，此写法等同于synchronized方法。

回到刚才的例子中，我们又是如何解决storeNumber混乱的问题呢？咱们试着在方法上加上锁，这样保证同时只有一个线程能调用这个方法，具体如下。

我们运行一下代码，结果如下

我是用户2,我存储的数字是：2

我是用户3,我存储的数字是：2

我是用户1,我存储的数字是：1

我们发现结果还是混乱的，并没有解决问题。我们检查一下代码

我们可以看到在useCabinet和打印的方法是两个语句，并没有保持原子性，虽然在set方法上加了锁，但是在打印的时候又存在了并发，打印语句是有锁的，但是不能确定哪个线程去执行。所以这里，我们要保证useCabinet和打印的方法的原子性，我们使用synchronized块，但是synchronized块里的对象我们使用谁的？这又是一个问题，user还是cabinet?回答当然是cabinet，因为每个线程都初始化了user，总共有3个User对象，而cabinet对象只有一个，所以synchronized要用cabine对象，具体代码如下

此时我们再去运行一下：

我是用户3,我存储的数字是：3

我是用户2,我存储的数字是：2

我是用户1,我存储的数字是：1

由于我们加了synchronized块，保证了存储和取出的原子性，这样用户存储的数字和取出的数字就对应上了，不会造成混乱，最后我们用图来表示一下上面例子的整体情况。

如上图所示，线程A，线程B，线程C同时调用Cabinet类的setStoreNumber方法，线程B获得了锁，所以线程B可以执行setStore的方法，线程A和线程C只能等待。

总结

通过上面的场景以及例子，我们可以了解多线程情况下，造成的变量值前后不一致的问题，以及锁的作用，在使用了锁以后，可以避免这种混乱的现象。