java多线程（锁机制）

1、乐观锁与悲观锁

悲观锁
老是假设最坏的状况，每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了不少这种锁机制，好比行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁
老是假设最好的状况，每次去拿数据的时候都认为别人不会修改，因此不会上锁，可是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库提供的相似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景
从上面对两种锁的介绍，咱们知道两种锁各有优缺点，不可认为一种好于另外一种，像乐观锁适用于写比较少的状况下（多读场景），即冲突真的不多发生的时候，这样能够省去了锁的开销，加大了系统的整个吞吐量。但若是是多写的状况，通常会常常产生冲突，这就会致使上层应用会不断的进行retry，这样反却是下降了性能，因此通常多写的场景下用悲观锁就比较合适。

乐观锁通常会使用版本号机制或CAS算法实现。

1. 版本号机制
通常是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，不然重试更新操做，直到更新成功。

举一个简单的例子：
假设数据库中账户信息表中有一个 version 字段，当前值为 1 ；而当前账户余额字段（ balance ）为 $100 。

操做员 A 此时将其读出（ version=1 ），并从其账户余额中扣除 50（50（100-$50 ）。
在操做员 A 操做的过程当中，操做员B 也读入此用户信息（ version=1 ），并从其账户余额中扣除 20（20（100-$20 ）。
操做员 A 完成了修改工做，将数据版本号加一（ version=2 ），连同账户扣除后余额（ balance=$50 ），提交至数据库更新，此时因为提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操做员 B 完成了操做，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操做员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不知足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，所以，操做员 B 的提交被驳回。
这样，就避免了操做员 B 用基于 version=1 的旧数据修改的结果覆盖操做员A 的操做结果的可能。

2. CAS算法
即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的状况下实现多线程之间的变量同步，也就是在没有线程被阻塞的状况下实现变量的同步，因此也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操做数

须要读写的内存值 V
进行比较的值 A
拟写入的新值 B
当且仅当 V 的值等于 A时，CAS经过原子方式用新值B来更新V的值，不然不会执行任何操做（比较和替换是一个原子操做）。通常状况下是一个自旋操做，即不断的重试。

举例：

多线程状况下如何实现count++?
使用悲观锁可使用synchronized对变量进行加锁；

CAS的操做流程以下：
1.读取内存数据j=count;

2.CAS(j,j++);即比较内存中count数据是否还为j,若是是才进行修改；整个操做具备原子性

3.若是成功，返回；失败则从新执行第一步直到成功，也称之为自旋。

因为第二步成功的几率很大，因此采用CAS的代价很小；当高并发状况下因为CAS采用自旋的方式对CPU会有较大的操做负担，因此可能会损耗部分CPU资源。

 

乐观锁的缺点

1 ABA 问题
若是一个变量V初次读取的时候是A值，而且在准备赋值的时候检查到它仍然是A值，那咱们就能说明它的值没有被其余线程修改过了吗？很明显是不能的，由于在这段时间它的值可能被改成其余值，而后又改回A，那CAS操做就会误认为它历来没有被修改过。这个问题被称为CAS操做的 “ABA”问题。

JDK 1.5 之后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，而且当前标志是否等于预期标志，若是所有相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

2 循环时间长开销大
自旋CAS（也就是不成功就一直循环执行直到成功）若是长时间不成功，会给CPU带来很是大的执行开销。 若是JVM能支持处理器提供的pause指令那么效率会有必定的提高，pause指令有两个做用，第一它能够延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它能够避免在退出循环的时候因内存顺序冲突（memory order violation）而引发CPU流水线被清空（CPU pipeline flush），从而提升CPU的执行效率。

3 只能保证一个共享变量的原子操做
CAS 只对单个共享变量有效，当操做涉及跨多个共享变量时 CAS 无效。可是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你能够把多个变量放在一个对象里来进行 CAS 操做.因此咱们可使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操做。

参考https://blog.csdn.net/qq_34337272/article/details/81072874

https://blog.csdn.net/u010904188/article/details/87712060

2、锁机制

有些业务逻辑在执行过程当中要求对数据进行排他性的访问，因而须要经过一些机制保证在此过程当中数据被锁住不会被外界修改，这就是所谓的锁机制。

CAS是Compare And Set的缩写，是以一种无锁的方式实现并发控制。在实际状况下，同时操做同一个对象的几率很是小，因此多数加锁操做作的是无用功，CAS以一种乐观锁的方式实现并发控制。CAS的具体实现就是给定内存中的指望值和修改后的目标值，若是实际内存中的值等于指望值，则内存值替换为目标值，不然操做失败。该操做具备原子性。

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了不少这种锁机制，好比行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，因此不会上锁，可是在更新的时候会判断一下在此期间别人有没有去更新这个数

重入锁（ReentrantLock）是一种递归无阻塞的同步机制。重入锁，也叫作递归锁，指的是同一线程 外层函数得到锁以后 ，内层递归函数仍然有获取该锁的代码，但不受影响。在JAVA环境下 ReentrantLock 和synchronized 都是 可重入锁。

自旋锁，因为自旋锁使用者通常保持锁时间很是短，所以选择自旋而不是睡眠是很是必要的，自旋锁的效率远高于互斥锁。如何旋转呢？何为自旋锁，就是若是发现锁定了，不是睡眠等待，而是采用让当前线程不停地的在循环体内执行实现的，当循环的条件被其余线程改变时 才能进入临界区。

偏向锁(Biased Locking)是Java6引入的一项多线程优化，它会偏向于第一个访问锁的线程，若是在运行过程当中，同步锁只有一个线程访问，不存在多线程争用的状况，则线程是不须要触发同步的，这种状况下，就会给线程加一个偏向锁。 若是在运行过程当中，遇到了其余线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。

轻量级锁是由偏向所升级来的，偏向锁运行在一个线程进入同步块的状况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。

公平锁，就是很公平，在并发环境中，每一个线程在获取锁时会先查看此锁维护的等待队列，若是为空，或者当前线程线程是等待队列的第一个，就占有锁，不然就会加入到等待队列中，之后会按照FIFO的规则从队列中取到本身

非公平锁比较粗鲁，上来就直接尝试占有锁，若是尝试失败，就再采用相似公平锁那种方式。

据，可使用版本号等机制。乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库若是提供相似于write_condition机制的其实都是提供的乐观锁。

方法锁（synchronized修饰方法时）经过在方法声明中加入 synchronized关键字来声明 synchronized 方法。synchronized 方法控制对类成员变量的访问： 每一个类实例对应一把锁，每一个 synchronized 方法都必须得到调用该方法的类实例的锁方能执行，不然所属线程阻塞，方法一旦执行，就独占该锁，直到从该方法返回时才将锁释放，此后被阻塞的线程方能得到该锁，从新进入可执行状态。这种机制确保了同一时刻对于每个类实例，其全部声明为 synchronized 的成员函数中至多只有一个处于可执行状态，从而有效避免了类成员变量的访问冲突。

对象锁（synchronized修饰方法或代码块）当一个对象中有synchronized method或synchronized block的时候调用此对象的同步方法或进入其同步区域时，就必须先得到对象锁。若是此对象的对象锁已被其余调用者占用，则须要等待此锁被释放。（方法锁也是对象锁）。java的全部对象都含有1个互斥锁，这个锁由JVM自动获取和释放。线程进入synchronized方法的时候获取该对象的锁，固然若是已经有线程获取了这个对象的锁，那么当前线程会等待；synchronized方法正常返回或者抛异常而终止，JVM会自动释放对象锁。这里也体现了用synchronized来加锁的1个好处，方法抛异常的时候，锁仍然能够由JVM来自动释放。　

类锁(synchronized修饰静态的方法或代码块)，因为一个class不论被实例化多少次，其中的静态方法和静态变量在内存中都只有一份。因此，一旦一个静态的方法被申明为synchronized。此类全部的实例化对象在调用此方法，共用同一把锁，咱们称之为类锁。对象锁是用来控制实例方法之间的同步，类锁是用来控制静态方法（或静态变量互斥体）之间的同步。类锁只是一个概念上的东西，并非真实存在的，它只是用来帮助咱们理解锁定实例方法和静态方法的区别的。java类可能会有不少个对象，可是只有1个Class对象，也就是说类的不一样实例之间共享该类的Class对象。Class对象其实也仅仅是1个java对象，只不过有点特殊而已。因为每一个java对象都有1个互斥锁，而类的静态方法是须要Class对象。因此所谓的类锁，不过是Class对象的锁而已。获取类的Class对象有好几种，最简单的就是［类名.class］的方式。

死锁：是指两个或两个以上的进程（或线程）在执行过程当中，因争夺资源而形成的一种互相等待的现象，若无外力做用，它们都将没法推动下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

死锁发生的四个条件

• 互斥条件：线程对资源的访问是排他性的，若是一个线程对占用了某资源，那么其余线程必须处于等待状态，直到资源被释放。
• 请求和保持条件：线程T1至少已经保持了一个资源R1占用,但又提出对另外一个资源R2请求，而此时，资源R2被其余线程T2占用，因而该线程T1也必须等待，但又对本身保持的资源R1不释放。
• 不剥夺条件：线程已得到的资源，在未使用完以前，不能被其余线程剥夺，只能在使用完之后由本身释放。
• 环路等待条件：在死锁发生时，必然存在一个“进程-资源环形链”，即：{p0,p1,p2,...pn},进程p0（或线程）等待p1占用的资源，p1等待p2占用的资源，pn等待p0占用的资源。（最直观的理解是，p0等待p1占用的资源，而p1而在等待p0占用的资源，因而两个进程就相互等待）

预防死锁，预先破坏产生死锁的四个条件。互斥不可能破坏，因此有以下3种方法：

• 破坏，请求和保持条件。进程等全部要请求的资源都空闲时才能申请资源，这种方法会使资源严重浪费（有些资源可能仅在运行初期或结束时才使用，甚至根本不使用）。容许进程获取初期所需资源后，便开始运行，运行过程当中再逐步释放本身占有的资源。好比有一个进程的任务是把数据复制到磁盘中再打印，前期只须要得到磁盘资源而不须要得到打印机资源，待复制完毕后再释放掉磁盘资源。这种方法比上一种好，会使资源利用率上升。
• 破坏，不可抢占条件。这种方法代价大，实现复杂
• 破坏，循坏等待条件。对各进程请求资源的顺序作一个规定，避免相互等待。这种方法对资源的利用率比前两种都高，可是前期要为设备指定序号，新设备加入会有一个问题，其次对用户编程也有限制

活锁：是指线程1可使用资源，但它很礼貌，让其余线程先使用资源，线程2也可使用资源，但它很绅士，也让其余线程先使用资源。这样你让我，我让你，最后两个线程都没法使用资源。

死锁与饥饿的区别

相同点：两者都是因为竞争资源而引发的。

不一样点：

• 从进程状态考虑，死锁进程都处于等待状态，忙等待(处于运行或就绪状态)的进程并不是处于等待状态，但却可能被饿死；
• 死锁进程等待永远不会被释放的资源，饿死进程等待会被释放但却不会分配给本身的资源，表现为等待时限没有上界(排队等待或忙式等待)；
• 死锁必定发生了循环等待，而饿死则否则。这也代表经过资源分配图能够检测死锁存在与否，但却不能检测是否有进程饿死；
• 死锁必定涉及多个进程，而饥饿或被饿死的进程可能只有一个。
• 在饥饿的情形下，系统中有至少一个进程能正常运行，只是饥饿进程得不到执行机会。而死锁则可能会最终使整个系统陷入死锁并崩溃

怎么检测一个线程是否拥有锁

java.lang.Thread中有一个方法叫holdsLock()，它返回true若是当且仅当当前线程拥有某个具体对象的锁

3、何时应该使用可重入锁？

场景1：若是已加锁，则再也不重复加锁。a、忽略重复加锁。b、用在界面交互时点击执行较长时间请求操做时，防止屡次点击致使后台重复执行（忽略重复触发）。以上两种状况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操做等）

场景2：若是发现该操做已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）这种其实属于场景2的改进，等待得到锁的操做有一个时间的限制，若是超时则放弃执行。用来防止因为资源处理不当长时间占用致使死锁状况（你们都在等待资源，致使线程队列溢出）。

场景3：若是发现该操做已经加锁，则等待一个一个加锁（同步执行，相似synchronized）这种比较常见你们也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操做可使用该资源。但与synchronized的明显区别是性能优点（伴随jvm的优化这个差距在减少）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。这种状况主要用于对资源的争抢（如：文件操做，同步消息发送，有状态的操做等）

场景4：可中断锁。synchronized与Lock在默认状况下是不会响应中断(interrupt)操做，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景3的另外一种改进，没有超时，只能等待中断或执行完毕）这种状况主要用于取消某些操做对资源的占用。如：（取消正在同步运行的操做，来防止不正常操做长时间占用形成的阻塞）

4、如何实现分布式锁

基于数据库实现分布式锁

基于缓存（redis，memcached，tair）实现分布式锁

基于Zookeeper实现分布式锁

参考http://www.javashuo.com/article/p-dzxeriyg-kg.html

http://www.hollischuang.com/archives/1716