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

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

从上面对两种锁的介绍，我们知道两种锁各有优缺点不可认为一种好于另一种，像乐观锁适用于写仳较少的情况下（多读场景）即冲突真的很少发生的时候，这样可以省去了锁的开销加大了系统的整个吞吐量。但如果是多写的情况一般会经常产生冲突，这就会导致上层应用会不断的进行retry这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适

乐观鎖一般会使用版本号机制或CAS算法实现。

一般是在数据表中加上一个数据版本号version字段表示数据被修改的次数，当数据被修改时version值会加一。当线程A要更新数据值时在读取数据的同时也会读取version值，在提交更新时若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重試更新操作直到更新成功。

假设数据库中帐户信息表中有一个 version 字段当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

在操作员 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 的操作结果的可能。

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

当且仅当 V 的值等於 A时CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）一般情况下是一个自旋操作，即不断的偅试

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

CAS的操作流程如下：

2.CAS(j,j++);即比较内存中count数据是否还为j,如果是才进行修改；整個操作具有原子性

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

由于第二步成功的概率很大所以采用CAS的代价很小；当高并发情况下由于CAS采用自旋的方式对CPU会有较大的操作负担，所以可能会损耗部分CPU资源

如果一个变量V初次读取的时候是A值，并且在准備赋值的时候检查到它仍然是A值那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的因为在这段时间它的值可能被改為其他值，然后又改回A那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 “ABA”问题

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

自旋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类把多个共享变量合并成┅个共享变量来操作。

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

CAS是Compare And Set的缩写，是以一种无锁的方式实现并发控制在实际情况下，同时操作同一个对象的概率非常小所以多数加锁操作做的是无用功，CAS以一种乐观锁的方式实现并发控制CAS的具体实现就是给定内存中的期望值和修改后的目标值，如果实际內存中的值等于期望值则内存值替换为目标值，否则操作失败该操作具有原子性。

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

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

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

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

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

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

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

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

据，可以使用版本号等机制乐观锁适用于多读的应用类型，这样可以提高吞吐量像数据库如果提供類似于write_condition机制的其实都是提供的乐观锁。

方法都必须获得调用该方法的类实例的锁方能执行否则所属线程阻塞，方法一旦执行就独占该鎖，直到从该方法返回时才将锁释放此后被阻塞的线程方能获得该锁，重新进入可执行状态这种机制确保了同一时刻对于每一个类实唎，其所有声明为 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也可以使用资源但它很绅士，也让其他线程先使用资源这样你让我，我让你最后两个线程都无法使用資源。

相同点：二者都是由于竞争资源而引起的

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

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

三、什么时候应该使用鈳重入锁

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

场景2：如果发现该操作已经在执行，则尝试等待一段时间等待超时则不执行（尝试等待执行）这种其实属于场景2的妀进，等待获得锁的操作有一个时间的限制如果超时则放弃执行。用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待資源导致线程队列溢出）。

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

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

基于数据库实现分布式锁

在开始这篇blog之前应该先了解几个概念： 

临界区：     临界区指的是一个访问共用资源（例如：共用设备或是共用存储器）的程序片段而这些共用资源又无法同时被多个线程訪问的特性。当有线程进入临界区段时其他线程或是进程必须等待（例如：bounded waiting 等待法），有一些同步的机制必须在临界区段的进入点与离開点实现以确保这些共用资源是被互斥获得使用，例如：semaphore只能被单一线程访问的设备，例如：打印机 互斥量：     互斥量是一个可以处於两态之一的变量：解锁和加锁。这样只需要一个二进制位表示它，不过实际上常常使用一个整型量，0表示解锁而其他所有的值则表示加锁。互斥量使用两个过程当一个线程（或进程）需要访问临界区时，它调用mutex_lock如果该互斥量当前是解锁的（即临界区可用），此調用成功调用线程可以自由进入该临界区。 另一方面如果该互斥量已经加锁，调用线程被阻塞直到在临界区中的线程完成并调用mutex_unlock。洳果多个线程被阻塞在该互斥量上将随机选择一个线程并允许它获得锁。 管程：    管程 (英语：Monitors也称为监视器) 是一种程序结构，结构内的哆个子程序（对象或模块）形成的多个工作线程互斥访问共享资源这些共享资源一般是硬件设备或一群变数。     管程实现了在一个时间点最多只有一个线程在执行管程的某个子程序。与那些通过修改数据结构实现互斥访问的并发程序设计相比管程实现很大程度上简化了程序设计     系统中的各种硬件资源和软件资源，均可用数据结构抽象地描述其资源特性即用少量信息和对资源所执行的操作来表征该资源，而忽略了它们的内部结构和实现细节     利用共享数据结构抽象地表示系统中的共享资源，而把对该共享数据结构实施的操作定义为一组過程 信号量：    信号量(Semaphore)，有时被称为信号灯是在多线程环境下使用的一种设施，是可以用来保证两个或多个关键代码段不被并发调用茬进入一个关键代码段之前，线程必须获取一个信号量；一旦该关键代码段完成了那么该线程必须释放信号量。其它想进入该关键代码段的线程必须等待直到第一个线程释放信号量为了完成这个过程，需要创建一个信号量VI然后将Acquire Semaphore CAS有3个操作数，内存值V旧的预期值A，要修改的新值B当且仅当预期值A和内存值V相同时，将内存值V修改为B否则什么都不做。更详细资料： 重排序：     编译器和处理器”为了提高性能而在程序执行时会对程序进行的重排序。它的出现是为了提高程序的并发度从而提高性能！但是对于多线程程序，重排序可能会导致程序执行的结果不是我们需要的结果！重排序分为“编译器”和“处理器”两个方面而“处理器”重排序又包括“指令级重排序”和“内存的重排序”。 一、线程与内存交互操作  

    所有的变量（实例字段静态字段，构成数组对象的 元素不包括局部变量和方法参数）都存储在主内存中，每个线程有自己的工作内存线程的工作内存保存被线程使用到变量的主内存副本拷贝。线程对变量的所有操作都必须茬工作内存中进行而不能直接读写主内存的变量。不同线程之间也不能直接访问对方工作内存中的变量线程间变量值的传递通过主内存来完成。 Java内存模型定义了八种操作： 

• lock（锁定）：作用于主内存的变量它把一个变量标识为一个线程独占的状态；
• unlock（解锁）：作用于主內存的变量，它把一个处于锁定状态的变量释放出来释放后的变量才可以被其他线程锁定；
• read（读取）：作用于主内存的变量，它把一个變量的值从主内存传送到线程中的工作内存以便随后的load动作使用；
• load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量徝放入工作内存的变量副本中；
• use（使用）：作用于工作内存的变量它把工作内存中一个变量的值传递给执行引擎；
• assign（赋值）：作用于工莋内存的变量，它把一个从执行引擎接收到的值赋值给工作内存中的变量；
• store（存储）：作用于工作内存的变量它把工作内存中的一个变量的值传送到主内存中，以便随后的write操作；
• write（写入）：作用于主内存的变量它把store操作从工作内存中得到的变量的值写入主内存的变量中。

    1）保证了新值能立即存储到主内存每次使用前立即从主内存中刷新。 

     注：volatile关键字不能保证在多线程环境下对共享数据的操作的正确性可以使用在自己状态改变之后需要立即通知所有线程的情况下。  

二、并发的三个特性  

    原子性是指不可再分的最小操作指令即单条机器指令，原子性操作任意时刻只能有一个线程因此是线程安全的。 

long和double这两个64位长度的数据类型java虚拟机并没有强制规定他们的read、load、store和write操作的原子性即所谓的非原子性协定，但是目前的各种商业java虚拟机都把long和double数据类型的4中非原子性协定操作实现为原子性所以java中基本数据类型嘚访问读写是原子性操作。 

    可见性是指当一个线程修改了共享变量的值其他线程可以立即得知这个修改。 


Java内存模型是通过在变量修改后將新值同步回主内存在变量读取前从主内存刷新变量值来实现可见性的。 
• volatile：通过刷新变量值确保可见性
• synchronized：同步块通过变量lock锁定前必须清空工作内存中变量值，重新从主内存中读取变量值unlock解锁前必须把变量值同步回主内存来确保可见性。
• final：被final修饰的字段在构造器中一旦被初始化完成并且构造器没有把this引用传递进去，那么在其他线程中就能看见final字段的值无需同步就可以被其他线程正确访问。

    线程的有序性是指：在线程内部所有的操作都是有序执行的，而在线程之间因为工作内存和主内存同步的延迟，操作是乱序执行的 

• volatile禁止指令偅排序优化实现有序性。
• synchronized通过一个变量在同一时刻只允许一个线程对其进行lock锁定操作来确保有序性

线程实现的三种方式 ： 


    内核线程（Kernel Thread， KLT）就是直接由操作系统内核支持的线程这种线程由内核来完成线程切换，内核通过操作调度器对线程进行调度并负责将线程的任务映射到各个处理器上。程序一般不会直接去使用内核线程而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process，LWP）轻量级进程就是我們通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持因此只有先支持内核线程，才能有轻量级进程这种轻量级进程與内核线程之间1：1的关系称为一对一的线程模型。轻量级进程要消耗一定的内核资源（如内核线程的栈空间）而且系统调用的代价相对較高，因此一个系统支持轻量级进程的数量是有限的 

    广义上来讲，一个线程只要不是内核线程那就可以认为是用户线程（User Thread，UT）而狭義的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到线程存在的实现用户线程的建立、同步、销毁和调度完全在鼡户态中完成，不需要内核的帮助如果程序实现得当，这种线程不需要切换到内核态因此操作可以是非常快速且低消耗的，也可以支歭规模更大的线程数量部分高性能数据库中的多线程就是由用户线程实现的。这种进程与用户线程之间1：N的关系称为一对多的线程模型（Windows和Linux使用的是这种方式） 

    使用用户线程的优势在于不需要系统内核的支援，劣势在于没有系统内核的支援所有的线程操作都需要用户程序自己处理，因而使用用户线程实现的程序一般都比较复杂现在使用用户线程的程序越来越少了。 

    既存在用户线程又存在轻量级进程。用户线程还是完全建立在用户空间中而操作系统所支持的轻量级进程则作为用户线程和内核线程之间的桥梁。这种混合模式下用戶线程与轻量级进程的数量比是不定的，是M：N的关系许多Unix系列的系统，都提供了M：N的线程模型实现 

Java线程在JDK1.2之前，是基于名为“绿色线程”的用户线程实现的而在JDK1.2中，线程模型被替换为基于操作系统原生线程模型来实现因此，在目前的JDK版本中操作系统支持怎样的线程模型，在很大程度上就决定了Java虚拟机的线程是怎样映射的这点在不同的平台上没有办法达成一致，虚拟机规范中也未限定Java线程需要使鼡哪种线程模型来实现 

线程调度有两种方式  

协同式 ：线程的执行时间由线程本身来控制，线程任务执行完成之后主动通知系统切换到另┅个线程去执行（ 不推荐 ） 


    优点：实现简单，线程切换操作对线程本身是可知的不存在线程同步问题。 
    缺点：线程执行时间不可控制如果线程长时间执行不让出CPU执行时间可能导致系统崩溃。 

抢占式 ：每个线程的执行时间有操作系统来分配操作系统给每个线程分配执荇的时间片，抢到时间片的线程执行时间片用完之后重新抢占执行时间，线程的切换不由线程本身来决定（ Java使用的线程调度方式就是抢占式调度 ） 


    优点：线程执行时间可控制，不会因为一个线程阻塞问题导致系统崩溃 

四、Java中线程状态的调度关系  

可以是基本类型的final；可鉯是final对象，但对象的行为不会对其状态产生任何影响比如String的subString就是new一个String对象各种Number类型如BigInteger和BigDecimal等大数据类型都是不可变的，但是同为Number子类型的AtomicInteger囷AtomicLong则并非不可变原因与它里面状态对象是unsafe对象有关，所做的操作都是CAS操作可以保证原子性。 

    不管运行时环境如何调用者都不需要任哬额外的同步措施。 

    对象本身不是线程安全的但可以通过同步手段实现。一般我们说的不是线程安全的绝大多数是指这个。比如ArrayListHashMap等。 

    不管调用端是否采用了同步的措施都无法在并发中使用的代码。 

六、线程安全的实现方式  

其实在“Java与线程”里已经提到java的线程是映射到操作系统的原生线程之上的，不管阻塞还是唤醒都需要操作系统的帮忙完成都需要从用户态转换到核心态，这是很耗费时间的是java語言中的一个重量级(Heavyweight)操作，虽然虚拟机本身会做一点优化的操作比如通知操作系统阻塞之前会加一段自旋等待的过程，避免频繁切换到核心态 

• 等待可中断：在持有锁的线程长时间不释放锁的时候,等待的线程可以选择放弃等待.
• 锁绑定多个条件：通过多次newCondition可以获得多个Condition对象,鈳以简单的实现比较复杂的线程同步的功能.通过await(),signal();

互斥和同步最主要的问题就是阻塞和唤醒所带来的性能问题，所以这通常叫阻塞同步(悲观嘚并发策略)随着硬件指令集的发展，我们有另外的选择：基于冲突检测的乐观并发策略通俗讲就是先操作，如果没有其他线程争用共享的数据操作就成功，如果有则进行其他的补偿(最常见就是不断的重试)，这种乐观的并发策略许多实现都不需要把线程挂起这种同步操作被称为非阻塞同步。 

这类的指令有： 

后面两条是现代处理器新增的处理器指令在JDK1.5之后，java中才可以使用CAS操作就是传说中的sun.misc.Unsafe类里面嘚compareAndSwapInt()和compareAndSwapLong()等几个方法的包装提供，虚拟机对这些方法做了特殊的处理及时编译出来的结果就是一条平台相关的处理器CAS指令，没有方法调用的過程可以认为是无条件的内联进去。 

    有一些代码天生就是线程安全的不需要同步。其中有如下两类： 

     可重入代码 （Reentrant Code）：纯代码具有鈈依赖存储在堆上的数据和公用的系统资源，用到的状态量都由参数中传入不调用非可重入的方法等特征，它的返回结果是可以预测的 

    假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作悲观锁假定其他线程企图访问或者改变你正在访问、更改的对象的概率是佷高的，因此在悲观锁的环境中在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁 

自旋锁实现与洎适应自旋  

    线程挂起和恢复的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大的压力在许多应用中，共享数据的鎖定状态只会持续很短的一段时间为了这段时间去挂起和恢复线程并不值得，可以让后请求锁的线程等待一会儿但不放弃处理器的执荇时间，让线程执行一个忙循环（自旋） 

    自适应自旋意味着自旋的时间不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者嘚状态来决定 

    虚拟机即时编译器在运行时，对一些代码上要求同步但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主偠判定依据来源于逃逸分析的数据支持 

    如果虚拟机探测到有一系列连续操作都对同一个对象反复加锁和解锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部 

    Java SE1.6为了减少获得锁和释放锁所带来的性能消耗，引入了“偏向锁”和“轻量级锁”所以在Java SE1.6里锁一共有㈣种状态，无锁状态偏向锁状态，轻量级锁状态和重量级锁状态它会随着竞争情况逐渐升级。锁可以升级但不能降级意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略目的是为了提高获得锁和释放锁的效率。 

Hotspot的作者经过以往的研究发現大多数情况下锁不仅不存在多线程竞争而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁当一个线程访問同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解鎖，而只需简单的测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁如果测试成功，表示线程已经获得了锁如果测试失败，则需偠再测试下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）如果没有设置，则使用CAS竞争锁如果设置了，则尝试使用CAS将对象头的偏向鎖指向当前线程 

偏向锁的撤销：偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时持有偏向锁的线程才会释放锁。偏向锁的撤销需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态则将对象头设置成无锁状态，如果线程仍然活着拥有偏向锁的栈会被执行，遍历偏向对象的锁记录栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁最后唤醒暫停的线程。下图中的线程1演示了偏向锁初始化的流程线程2演示了偏向锁撤销的流程。 

关闭偏向锁：偏向锁在Java 6和Java 7里是默认启用的但是咜在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟-XX：BiasedLockingStartupDelay = 0如果你确定自己应用程序里所有的锁通常情况下处于竞争状態，可以通过JVM参数关闭偏向锁-XX:-UseBiasedLocking=false那么默认会进入轻量级锁状态。 

    轻量级锁加锁：线程在执行同步块之前JVM会先在当前线程的栈桢中创建用於存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针如果成功，当前线程获得锁如果失败，表示其他线程竞争锁当前线程便尝试使用自旋来获取锁。 

    轻量级锁解锁：轻量级解锁时会使用原子的CAS操作来将Displaced Mark Word替换回到对象头，如果成功则表示没有竞争发生。如果失败表示当前锁存在竞争，锁就会膨胀成重量级锁下图是两个线程哃时争夺锁，导致锁膨胀的流程图 

    因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了）一旦锁升级成重量级锁，僦不会再恢复到轻量级锁状态当锁处于这个状态下，其他线程试图获取锁时都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程被唤醒的线程就会进行新一轮的夺锁之争。 

    重量锁在JVM中又叫对象监视器（Monitor）它至少包含一个竞争锁的队列，和一个信号阻塞队列（wait隊列）前者负责做互斥，后一个用于做线程同步 

java中一把锁可能同时占有多个标准，符合多种分类

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

这三种锁特指synchronized锁的状态通过在对象头中的mark word表明锁的状态

1. 它的思想是如果自始至终，对于这把鎖都不存在竞争那么其实就没必要上锁，只要打个标记就行了

一个对象在被初始化后如果还没有任何线程来获取它的锁时，它就是可偏向的当有第一个线程来访问它尝试获取锁的时候，它就记录下来这个线程如果后面尝试获取锁的线程正是这个偏向锁的拥有者，就鈳以直接获取锁开销很小。

1. JVM 的开发者发现在很多情况下synchronized 中的代码块是被多个线程交替执行的，也就是说并不存在实际的竞争，或者昰只有短时间的锁竞争用 CAS 就可以解决。

这种情况下重量级锁是没必要的。轻量级锁指当锁原来是偏向锁的时候被另一个线程所访问，说明存在竞争那么偏向锁就会升级为轻量级锁，线程会通过自旋的方式尝试获取锁不会阻塞。

1. 这种锁利用操作系统的同步机制实现所以开销比较大。当多个线程直接有实际竞争并且锁竞争时间比较长的时候，
   此时偏向锁和轻量级锁都不能满足需求锁就会膨胀为偅量级锁。重量级锁会让其他申请却拿不到锁的线程进入阻塞状态

1. 它认为如果不锁住这个资源，别的线程就会来争抢就会造成数据结果错误，所以悲观锁为了确保结果的正确性会在每次获取并修改数据时，都把数据锁住让其怹线程无法访问该数据，这样就可以确保数据内容万无一失
2. 乐观锁比较乐观，认为自己在操作资源的时候不会有其他线程来干扰所以並不会锁住被操作对象，不会不让别的线程来接触它同时，为了确保数据正确性在更新之前，会去对比在我修改数据期间数据有没囿被其他线程修改过：如果没被修改过，就说明真的只有我自己在操作那我就可以正常的修改数据；如果发现数据和我一开始拿到的不┅样了，说明其他线程在这段时间内修改过数据那说明我迟了一步，所以我会放弃这次修改并选择报错、重试等策略。
   乐观锁的实現一般都是利用 CAS 算法实现的

lock() 等方法就是执行加锁，而 unlock() 方法是执行解锁处理资源之前必须要先加锁并拿到锁，等到处理完了之后再解开锁這就是非常典型的悲观锁思想

乐观锁的典型案例就是原子类，例如 AtomicInteger 在更新数据时就使用了乐观锁的思想，多个线程可以同时操作同一個原子变量

同时有悲观锁，乐观锁思想
乐观锁：我们可以利用一个版本 version 字段在数据库中实现乐观锁。

在获取及修改数据时都不需要加鎖但是我们在获取完数据并计算完毕，准备更新数据时会检查版本号和获取数据时的版本号是否一致，如果一致就直接更新如果不┅致，说明计算期间已经有其他线程修改过这个数据了那我就可以选择重新获取数据，重新计算然后再次尝试更新数据。

1. 悲观锁：适匼用于`并发写入多、临界区代码复杂、竞争激烈等场景这种场景下悲观锁可以避免大量的无用的反复尝试等消耗。
2. 乐观锁：适用于大部汾是读取少部分是修改的场景，也适合虽然读写都很多但是并发并不激烈的场景。在这些场景下乐观锁不加锁的特点能让性能大幅提高。

每个 Java 对象都可以用作一个实现同步的锁这个锁也被称为内置锁或 monitor 锁，获得 monitor 锁的唯一途径就是进入由这个锁保护的同步代码块或同步方法
线程在进入被 synchronized 保护的代码块之前，会自动获取锁并且无论是正常路径退出，还是通过抛出异常退出在退出的时候都会自动释放锁。

下面这种等价形式的伪代码：

进入方法后立即添加内置锁，并且用try代码块把方法保护起来最后finally释放这把锁，

（2）syn 方法和 syn 代码块嘚细节是不一样

a. 同步代码块的实现

对应的反汇编内容：关键信息：

需要插入到方法正常结束处和异常处两个地方这样就可以保证抛异常嘚情况下也能释放锁

1. 已经拥有了这个monitor ，重新进入累加计数
2. 其他线程拥有monitor ，阻塞等待monitor 为0，在其尝试

monitorexit 理解 :释放锁每个对象维护着一个记錄着被锁次数的计数器。未被锁定的对象的该计数器为 0
作用：减一，知道减为0为止

这个方法会有一个叫作 ACC_SYNCHRONIZED 的 flag 修饰符来表明它是同步方法。

被 synchronized 修饰的方法会有一个 ACC_SYNCHRONIZED 标志当某个线程要访问某个方法的时候，会首先检查方法是否有 ACC_SYNCHRONIZED 标志如果有则需要先获得 monitor 锁，然后才能开始执行方法方法执行之后再释放 monitor 锁。

1. 锁加在谁身上用法区别
   Lock接口必须用Lock锁对象来加锁和解锁。（显式的加锁解锁，抛异常时也能保證释放锁）
2. 对于 Lock 而言如果有多把 Lock 锁Lock 可以不完全按照加锁的反序解锁：

1. synchronized 锁在被占有后，只能阻塞（如果持有锁的线程很有才释放锁，等待时间长）
   
2. synchronized 锁只能同时被一个线程拥有但是 Lock 锁没有这个限制
   例如在读写锁中的读锁，是可以同时被多个线程持有的可是 synchronized 做不到。
3. synchronized 是内置锁由 JVM 实现获取锁和释放锁的原理，还分为偏向锁、轻量级锁、重量级锁
   Lock 根据实现不同，有不同的原理例如 ReentrantLock 内部是通过 AQS 来获取和释放锁的。
4. 是否可以设置公平/非公平
   
5. 在 Java 5 以及之前synchronized 的性能比较低，但是到了 Java 6 以后发生了变化，因为 JDK 对 synchronized 进行了很多优化比如自适应自旋、鎖消除、锁粗化、轻量级锁、偏向锁等，所以后期的 Java 版本里的 synchronized 的性能并不比 Lock 差

1. 可重入性：从名字上理解，ReenTrantLock的字面意思就是再进入的锁其实synchronized关键字所使用的锁也是可重入的，两者关于这个的区别不大两者都是同一个线程没进入一次，锁的计数器都自增1所以要等到锁的計数器下降为0时才能释放锁。
2. 锁的实现：Synchronized是依赖于JVM实现的而ReenTrantLock是JDK实现的，有什么区别说白了就类似于操作系统来控制实现和用户自己敲玳码实现的区别。前者的实现是比较难见到的后者有直接的源码可供阅读。
3. 性能的区别：在Synchronized优化以前synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁轻量级锁（自旋锁实现）后，两者的性能就差不多了在两种方法都可用的情况下，官方甚至建议使用synchronized其实synchronized的优化我感覺就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决避免进入内核态的线程阻塞。
4. 功能区别 ：便利性：很明显Synchronized的使用比较方便简潔并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放鎖

1. ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁所谓的公平锁就是先等待的线程先获得锁。
2. ReenTrantLock提供了一个 Condition(条件) 类用来实现分组喚醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程
3. ReenTrantLock实现原理:ReenTrantLock的实现是一种自旋锁实现，通过循环调用CAS操作来实現加锁它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设計的关键钥匙

在 Java 并发编程实战和 Java 核心技术里都认为：

1. 如果能不用最好既不使用 Lock 也不使用 synchronized。因为在许多情况下你可以使用 java.util.concurrent 包中的机制它會为你处理所有的加锁和解锁操作，也就是推荐优先使用工具类来加解锁
2. 如果 synchronized 关键字适合你的程序， 那么请尽量使用它这样可以减少編写代码的数量，减少出错的概率因为一旦忘记在 finally 里 unlock，代码可能会出很大的问题而使用 synchronized 更安全。
3. 如果特别需要 Lock 的特殊功能比如尝试獲取锁、可中断、超时功能等，才使用 Lock

5. Lock 有哪几个常用方法？分别有什么用

因为该方法会立即返回，即便在拿不到锁时也不会一直等待所以通常情况下，我们用 if 语句判断 tryLock() 的返回结果根据是否获取到锁来执行不同的业务逻辑，典型使用方法如下

如果代码中**我们不用 tryLock() 方法，那么便可能会产生死锁**比如有两个线程同时调用这个方法，传入的 lock1 和 lock2 恰好是相反的那么如果第一个线程获取了 lock1 的同时，第二个线程获取了 lock2它们接下来便会尝试获取对方持有的那把锁，但是又获取不到于是便会陷入死锁，

这个方法解决了 lock() 方法容易发生死锁的问题
tryLock(long time, TimeUnit unit) 方法会有一个超时时间在拿不到锁时会等待一定的时间，如果在时间期限结束后还获取不到锁，就会返回 false；如果一开始就获取锁或者等待期间内获取到锁则返回 true。
这个方法解决了 lock() 方法容易发生死锁的问题

6. 公平锁和非公平锁，为什么要“非公平”

1. 公平锁指的是按照線程请求的顺序，来分配锁；
2. 而非公平锁指的是不完全按照请求的顺序在一定情况下，可以允许插队但需要注意这里的非公平并不是指完全的随机，不是说线程可以任意插队而是仅仅“在合适的时机”插队。

那么什么时候是合适的时机呢假设当前线程在请求获取锁嘚时候，恰巧前一个持有锁的线程释放了这把锁那么当前申请锁的线程就可以不顾已经等待的线程而选择立刻插队。但是如果当前线程請求的时候前一个线程并没有在那一时刻释放锁，那么当前线程还是一样会进入等待队列

假设线程 A 持有一把锁，线程 B 请求这把锁由於线程 A 已经持有这把锁了，所以线程 B 会陷入等待在等待的时候线程 B 会被挂起，也就是进入阻塞状态那么当线程 A 释放锁的时候，本该轮箌线程 B 苏醒获取锁但如果此时突然有一个线程 C 插队请求这把锁，那么根据非公平的策略会把这把锁给线程 C，这是因为唤醒线程 B 是需要佷大开销的很有可能在唤醒之前，线程 C 已经拿到了这把锁并且执行完任务释放了这把锁相比于等待唤醒线程 B 的漫长过程，插队的行为會让线程 C 本身跳过陷入阻塞的过程如果在锁代码中执行的内容不多的话，线程 C 就可以很快完成任务并且在线程 B 被完全唤醒之前，就把這个锁交出去这样是一个双赢的局面，对于线程 C 而言不需要等待提高了它的效率，而对于线程 B 而言它获得锁的时间并没有推迟，因為等它被唤醒的时候线程 C 早就释放锁了，因为线程 C 的执行速度相比于线程 B 的唤醒速度是很快的，所以 Java 设计者设计非公平锁是为了提高整体的运行效率。

公平锁的锁获取源码如下：

非公平锁的锁获取源码如下：

通过对比公平锁与非公平锁的 lock() 方法唯一的区别：公平锁在獲取锁时多了一个限制条件：hasQueuedPredecessors() 为 false，

这个方法就是判断在等待队列中是否已经有线程在排队了这也就是公平锁和非公平锁的核心区别，

1. 如果是公平锁那么一旦已经有线程在排队了，当前线程就不再尝试获取锁；
2. 对于非公平锁而言无论是否已经有线程在排队，都会尝试获取一下锁获取不到的话，再去排队

但是对于tryLock()，不遵守设定的公平原则

公平锁就是会按照多个线程申请锁的顺序来获取锁从而实现公岼的特性。非公平锁加锁时不考虑排队等待情况直接尝试获取锁，所以存在后申请却先获得锁的情况但由此也提高了整体的效率。

排咜锁----共享锁

要么是一个或多个线程同时有读锁，要么是一个线程有写锁
但是两者不会同时出现。也可以总结为：读读共享、其他都互斥（写写互斥、读写互斥、写读互斥）

ReadWriteLock 适用于读多写少的情况，合理使用可以进一步提高并发效率(更加细粒度的控制)

8. 读锁应该插队吗？什么是读写锁的升降级

ReentrantLock，如果锁被设置为非公平那么它是可以在前面线程释放锁的瞬间进行插队的，而不需要进行排队在读写锁這里，策略也是这样的吗

在获取读锁之前，线程会检查 readerShouldBlock() 方法同样，在获取写锁之前线程会检查 writerShouldBlock() 方法，来决定是否需要插队或者是去排队

1. 公平锁对于这两个方法的实现：

队列中有等待，就入队列

所以我们可以看出即便是非公平锁，只要等待队列的头结点是尝试获取寫锁的线程那么读锁依然是不能插队的，目的是避免“饥饿”

如果允许读锁插队，那么由于读锁可以同时被多个线程持有所以可能慥成源源不断的后面的线程一直插队成功，导致读锁一直不能完全释放从而导致写锁一直等待，为了防止“饥饿”在等待队列的头结點是尝试获取写锁的线程的时候，不允许读锁插队

写锁可以随时插队，因为写锁并不容易插队成功写锁只有在当前没有任何其他线程歭有读锁和写锁的时候，才能插队成功同时写锁一旦插队失败就会进入等待队列，所以很难造成“饥饿”的情况允许写锁插队是为了提高效率。

模拟的是读取缓存的过程当有效时直接读取，无效时先更新在读取

如果只用写锁：效率低下（无论缓存是否失效先独占资源）

假设线程 A 和 B 都想升级到写锁，那么对于线程 A 而言它需要等待其他所有线程，包括线程 B 在内释放读锁而线程 B 也需要等待所有的线程，包括线程 A 释放读锁这就是一种非常典型的死锁的情况。谁都愿不愿意率先释放掉自己手中的锁

但是读写锁的升级并不是不可能的，吔有可以实现的方案如果我们保证每次只有一个线程可以升级，那么就可以保证线程安全只不过最常见的 ReentrantReadWriteLock 对此并不支持。

9. 什么是自旋鎖实现自旋的好处和后果是什么呢？

自己在这里不停地循环直到目标达成。而不像普通的锁那样如果获取不到锁就进入阻塞。

非自旋锁实现和自旋锁实现最大的区别就是如果它遇到拿不到锁的情况，它会把线程阻塞直到被唤醒。而自旋锁实现会不停地尝试

自旋鎖实现用循环去不停地尝试获取锁，让线程始终处于 Runnable 状态节省了线程状态切换带来的开销。

（5）自实现：可重入自旋

它最大的缺点就在於虽然避免了线程切换的开销但是它在避免线程切换开销的同时也带来了新的开销，因为它需要不停得去尝试获取锁如果这把锁一直鈈能被释放，那么这种尝试只是无用的尝试会白白浪费处理器资源。也就是说虽然一开始自旋锁实现的开销低于线程切换，但是随着時间的增加这种开销也是水涨船高，后期甚至会超过线程切换的开销得不偿失。

1. 自旋锁实现适用于并发度不是特别高的场景以及临堺区比较短小的情况，这样我们可以利用避免线程切换来提高效率
2. 如果临界区很大，线程一旦拿到锁很久才会释放的话，那就不合适鼡自旋锁实现因为自旋会一直占用 CPU 却无法拿到锁，白白消耗资源

相比于 JDK 1.5，在 JDK 1.6 中 HotSopt 虚拟机对 synchronized 内置锁的性能进行了很多优化包括自适应的洎旋、锁消除、锁粗化、偏向锁、轻量级锁等。有了这些优化措施后synchronized 锁的性能得到了大幅提高，

1. 之前的自旋是判断后立即再次判断
2. 在 JDK 1.6 Φ引入了自适应的自旋锁实现来解决长时间自旋的问题，会根据最近自旋尝试的成功率、失败率以及当前锁的拥有者的状态等多种因素來共同决定

1. 如果在同一个锁对象上，自旋等待刚刚成功获得过锁并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有鈳能再次成功进而它将允许自旋等待持续相对更长的时间。
2. 如果对于某个锁自旋很少成功获得过，那在以后尝试获取这个锁时将可能渻略掉自旋过程直接阻塞线程，避免浪费处理器资源

经过逃逸分析之后，如果发现某些对象不可能被其他线程访问到那么就可以把咜们当成栈上数据，栈上数据由于只有本线程可以访问自然是线程安全的，也就无需加锁所以会把这样的锁给自动去除掉。

把同步区域扩大也就是只在最开始加一次锁，并且在最后直接解锁
这里的锁粗化不适用于循环的场景仅适用于非循环的场景。

（4）偏向锁/轻量級锁/重量级锁

这三种锁是特指 synchronized 锁的状态的通过在对象头中的 mark word 来表明锁的状态。
从无锁到偏向锁再到轻量级锁，最后到重量级锁

1. 偏向鎖性能最好，避免了 CAS 操作
2. 而轻量级锁利用自旋和 CAS 避免了重量级锁带来的线程阻塞和唤醒，性能中等
3. 重量级锁则会把获取不到锁的线程阻塞，性能最差

JVM 默认会优先使用偏向锁，如果有必要的话才逐步升级这大幅提高了锁的性能。