Java多线程 - 锁

三性

可见性

指的是线程之间的可见性，一个线程对状态的修改，对其他线程是可见的。在 Java中 volatile、synchronized 和 final 实现可见性。
原子性

如果一个操作是不可分割的，我们则称之为原子操作，也就是有原子性。比如i++，就不是原子操作。在Java 中 synchronized和在lock、unlock 中操作保证原子性
有序性

一系列操作是按照规定的顺序发生的。如果在本线程之内观察，所有的操作都是有序的，如果在其他线程观察，所有的操作都是无序的；前半句指“线程内表现为串行语义”后半句指“指令重排序”和“工作内存和主存同步延迟”。Java语言提供了volatile 和 synchronized 两个关键字来保证线程之间操作的有序性。volatile是因为其本身包含“禁止指令重排序”的语义，
synchronized 是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得的，此规则决定了持有同一个对象锁的两个同步块只能串行执行。

Volatile

作用

保证了可见性。
防止指令重排序(有序性)。
半个原子性：对任意单个volatile变量的读/写具有原子性

读-写时内存语义

写的内存语义
当写一个volatile变量时，JMM会把该线程对应的本地内存中共享变量值刷新会共享内存
读的内存语义

当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

Volatile的内存屏障实现

是否可以重排序	第二个操作	第二个操作	第二个操作
第一个操作	普通读/写	volatile读	volatile写
普通读/写	YES	YES	NO
volatile读	NO	NO	NO
volatile写	YES	NO	NO

编译器生成字节码文件时会在指令序列中插入内存屏障来禁止特定类型的处理器排序。但是，在实际执行过程中，只要不改变volatile的内存语义，
编译器可以根据实际情况省略部分不必要的内存屏障。

放置的内存屏障

在每个volatile写操作前面插入StoreStore屏障
在每个volatile写操作后面插入StoreLoad屏障
在每个volatile读操作后面插入LoadLoad屏障
在每个volatile读操作后面插入LoadStore屏障

什么是指令重排序

执行任务的时候，为了提高编译器和处理器的执行性能，编译器和处理器(包括内存系统，内存在行为没有重排但是存储的时候是有变化的)会对指令重排序。编译器优化的重排序是在编译时期完成的，指令重排序和内存重排序是处理器重排序

编译器优化的重排序

在不改变单线程语义的情况下重新安排语句的执行顺序。比如，在第10行创建了临时变量，在使用前才进行初始化。或者，下面的情况。

int a = 3;
a = 5;int a = 5

指令级并行重排序

处理器的指令级并行技术将多条指令重叠执行，如果不存在数据的依赖性，为了使 CPU 内部的运算单元能够尽量被充分利用，处理器可能会对输入的字节码指令进行重排序处理，也就是处理器优化。

现在的CPU一般采用流水线来执行指令。一个指令的执行被分成：取址、译码、访存、执行、写回、等若干个阶段。然后，多条指令可以同时存在于流水线中，同时被执行。指令流水线并不是串行的，多个指令可以同时处于同一个阶段，只要CPU内部相应的处理部件未被占满即可。

比如说CPU有一个加法器和一个除法器，那么一条加法指令和一条除法指令就可能同时处于“执行”阶段, 而两条加法指令在“执行”阶段就只能串行工作。

a++;
b=f(a);  //会阻塞直到a++有结果
c--; //没有因果关系，所以，可以先计算。但是，这个先计算是发生在CPU执行时

像这样有依赖关系的指令如果挨得很近，后一条指令必定会因为等待前一条执行的结果，而在流水线中阻塞很久，占用流水线的资源。而编译器的乱序，作为编译优化的一种手段，则试图通过指令重排将这样的两条指令拉开距离, 以至于后一条指令进入CPU的时候，前一条指令结果已经得到了，那么也就不再需要阻塞等待了。比如将指令重排为：

a++; c--; b=f(a);

相比于CPU的乱序，编译器的乱序才是真正对指令顺序做了调整。但是编译器的乱序也必须保证程序上下文的因果关系不发生改变。

内存系统的重排序

因为使用了读写缓存区，使得看起来并不是顺序执行的。

内存重排序实际上并不是真的相关操作被排序了，而是因为CPU引入高速缓存还没来得及刷新导致；

寄存器是什么和高速缓存什么区别：

CPU要取数据，处理数据，都要放到寄存器处理。一般寄存器不用太大，它只要存放指令一次操作的数据就够了。

高速缓存是内存的部分拷贝，因为高速缓存速度快，把常用的数据放这里可以提高速度。

每个CPU都有自己的缓存，为了提高共享变量的写操作，CPU把整个操作变成异步的了，如果写入操作还没来的及同步到其它CPU，就有可能发生其它CPU读取到的是旧的值，因此看起来这条指令还没执行一样。

多CPU架构中，多个CPU高速缓冲区数据同步，依赖于缓存一致性协议

缓存一致性协议

在多处理器的情况下，每个处理器总是嗅探总线上传播的数据来检查自己的缓存是否过期，当处理器发现自己对应的缓存对应的地址被修改，
就会将当前处理器的缓存行设置为无效状态，当处理器对这个数据进行操作的时候，会重新从系统中把数据督导处理器的缓存里。这个协议被称之为缓存一致性协议。

CPU对于Volatile的支持

在有volatile修饰的共享变量进行写操作的时候会多出一条带有lock前缀的汇编代码，而这个lock操作会做两件事：

将当前处理器的缓存行的数据同步到系统内存。lock信号确保存在该信号期间CPU可以独占共享内存。在之前通过锁总线的方式，现在采用锁缓存的方式。
这个写回操作会使其他处理器的缓存中缓存了该地址的缓存行无效。在下一次这些CPU需要使用这些地址的值时，强制要求去共享内存中读取。

总结

volatile提供了一种轻量级同步机制来完成同步，它可以保操作的可见性、有序性以及对于单个volatile变量的读/写具有原子性，对于符合操作等非原子操作不具有原子性。

volatile通过添加内存屏障(特殊的字节码)及缓存一致性协议(lock指令)来完成对可见性的保证。

Synchronized

三种应用方式

修饰实例方法，作用于当前实例(this)加锁，进入同步代码前要获得当前实例的锁
修饰静态方法，作用于当前类对象(XX.class)加锁，进入同步代码前要获得当前类对象的锁
修饰代码块，指定加锁对象，对给定对象(object)加锁，进入同步代码库前要获得给定对象的锁。

Synchronized 锁升级

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

升级过程

一个对象刚开始实例化的时候，没有任何线程来访问它的时候。它是可偏向的，意味着，它现在认为只可能有一个线程来访问它，所以当第一个线程来访问它的时候，它会偏向这个线程，此时，对象持有偏向锁。偏向第一个线程，这个线程在修改对象头成为偏向锁的时候使用CAS操作，并将对象头中的ThreadID改成自己的ID，之后再次访问这个对象时，只需要对比ID，不需要再使用CAS在进行操作。
一旦有第二个线程访问这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到对象时偏向状态，这时表明在这个对象上已经存在竞争了。检查原来持有该对象锁的线程是否依然存活，如果挂了，则可以将对象变为无锁状态，然后重新偏向新的线程。如果原来的线程依然存活，则马上执行那个线程的操作栈，检查该对象的使用情况，如果仍然需要持有偏向锁，则偏向锁升级为轻量级锁，（偏向锁就是这个时候升级为轻量级锁的），此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁；如果不存在使用了，则可以将对象回复成无锁状态，然后重新偏向。
轻量级锁认为竞争存在，但是竞争的程度很轻，一般两个线程对于同一个锁的操作都会错开，或者说稍微等待一下（自旋），另一个线程就会释放锁。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁膨胀为重量级锁，重量级锁使除了拥有锁的线程以外的线程都阻塞，防止CPU空转。

其中，偏向所锁，轻量级锁都是乐观锁，重量级锁是悲观锁。

Synchronized底层原理

Java对象结构

实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。（相当于C语言的内存对其）
对象头：jvm中采用2个字来存储对象头(如果对象是数组则会分配3个字，多出来的1个字记录的是数组长度)，其主要结构是由Mark Word 和 Class Metadata Address 组成。

Java对象头结构

虚拟机位数	头对象结构	说明
32/64bit	Mark Word	存储对象的hashCode、锁信息或分代年龄或GC标志等信息
32/64bit	Class Metadata Address	类型指针指向对象的类元数据，JVM通过这个指针确定该对象是哪个类的实例。

Mark Word在默认情况下存储着对象的HashCode、分代年龄、锁标记位等以下是32位JVM的Mark Word默认存储结构

锁状态	25bit	4bit	1bit是否是偏向锁	2bit 锁标志位
无锁状态	对象HashCode	对象分代年龄	0	01

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。Mark Word可能变化为存储以下4种数据：

加上最初的默认状态，一共有5种变化。

重量级锁

Monitor对象

当Synchronized为重量级锁时，指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其monitor之间的关系有存在多种实现方式。在Java虚拟机(HotSpot)中，monitor是由ObjectMonitor实现的。

JVM: 即Java Virtual Machine，JAVA编译后生成的JAVA字节码是在JVM上跑，须要由JVM把字节码翻译成机器指令。主流的JVM包括Hotspot、Jikes RVM等。JVM运行的码文件是.jar

DVM：即Dalvik Virtual Machine，是安卓中使用的虚拟机。每一个进程相应着一个Dalvik虚拟机实例。Dalvik虚拟机运行的是Dalvik字节码。Dalvik使用即时编译(JIT)。因为JVM是Oracle公司（原SUN公司）的产品，Google担心版权的问题，既然Java是开源的，索性就研究了JVM，写出了DVM。Android执行的码文件是.dex。

ART：Android最新的虚拟机，使用AOT技术。

JIT：JIT会在运行时分析应用程序的代码，识别哪些方法可以归类为热方法，这些方法会被JIT编译器编译成对应的汇编代码，然后存储到代码缓存中，以后调用这些方法时就不用解释执行了，可以直接使用代码缓存中已编译好的汇编代码。

AOT：预编译。在运行之前，就对其包含的Dex字节码进行翻译，得到对应的本地机器指令，于是就可以在运行时直接执行了。

ObjectMonitor的主要数据结构如下：

ObjectMonitor() {_header       = NULL;_count        = 0; //记录个数_waiters      = 0,_recursions   = 0;_object       = NULL;_owner        = NULL; //指向持有ObjectMonitor对象的线程_WaitSet      = NULL; //保存ObjectWaiter对象列表.处于wait状态的线程，会被加入到_WaitSet_WaitSetLock  = 0 ;_Responsible  = NULL ;_succ         = NULL ;_cxq          = NULL ;FreeNext      = NULL ;_EntryList    = NULL ; //保存ObjectWaiter对象列表.处于等待锁block状态的线程，会被加入到该列表_SpinFreq     = 0 ;_SpinClock    = 0 ;OwnerIsThread = 0 ;}

每个等待锁的线程都会被封装成ObjectWaiter对象。

当多个线程同时访问一段同步代码时：

首先会进入 _EntryList 集合，当线程获取到对象的monitor后，进入 _Owner区域并把monitor中的owner变量设置为当前线程，同时monitor中的计数器count加1；
若线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待被唤醒；
若当前线程执行完毕，也将释放monitor（锁）并复位count的值，以便其他线程进入获取monitor(锁)；

总结：monitor对象存在于每个Java对象的对象头中(存储的指针的指向)，synchronized锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因，同时也是notify/notifyAll/wait等方法存在于顶级对象Object中的原因。

Synchronized重量级锁底层原理

对于Synchronized代码块，在字节码中使用monitorenter和monitorexit实现。

3: monitorenter  //进入同步代码
//..........省略其他
15: monitorexit   //退出同步代码
16: goto          24 //正常退出，继续执行
//省略其他.......
21: monitorexit //异常结束时被执行的释放monitor 的指令

偏向锁

HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得。偏向锁是为了在只有一个线程执行同步块时提高性能。

优势

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。

流程

访问Mark Word中偏向锁的标识是否设置成1，锁标志位是否为01——确认为可偏向状态。
如果为可偏向状态，则测试线程ID是否指向当前线程，如果是，进入步骤(5)，否则进入步骤(3)
如果线程ID并未指向当前线程，则通过CAS操作竞争锁。如果竞争成功，则将Mark Word中线程ID设置为当前线程ID，然后执行(5)；如果竞争失败，执行(4)。
如果CAS获取偏向锁失败，则表示有竞争(CAS获取偏向锁失败说明至少有过其他线程曾经获得过偏向锁，因为线程不会主动去释放偏向锁)。当到达全局安全点(safepoint)时，会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着(因为可能持有偏向锁的线程已经执行完毕，但是该线程并不会主动去释放偏向锁)，如果线程不处于活动状态，则将对象头设置成无锁状态(标志位为“01”)，然后重新偏向新的线程；如果线程仍然活着，撤销偏向锁后升级到轻量级锁状态(标志位为“00”)，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁。
执行同步代码

总结

偏向锁只适用于一个线程竞争获得锁的情况，如果出现另一个线程竞争，立即升级为轻量级锁

轻量级锁

轻量级锁是为了在线程近乎交替执行同步块时提高性能。

流程

在代码进入同步块的时候，如果同步对象锁状态为无锁状态(锁标志位为“01”状态，是否为偏向锁为“0”)，虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，官方称之为 Displaced Mark Word。这时候线程堆栈与对象头的状态如下图所示。
拷贝对象头中的Mark Word复制到锁记录中。
拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock record里的owner指针指向object mark word。如果更新成功，则执行步骤(3)，否则执行步骤(4)。
如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如下图所示。
如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，若当前只有一个等待线程，则可通过自旋稍微等待一下，可能另一个线程很快就会释放锁。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁膨胀为重量级锁，重量级锁使除了拥有锁的线程以外的线程都阻塞，防止CPU空转，锁标志的状态值变为“10”，Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

Synchronized锁类型

synchronized 锁是非公平锁。
synchronized是可重入锁，所以不会自己把自己锁死

Java锁

CAS操作

使用锁时，线程获取锁是一种悲观锁策略，即假设每一次执行临界区代码都会产生冲突，所以当前线程获取到锁的时候同时也会阻塞其他线程获取该锁。

CAS操作（又称为无锁操作）是一种乐观锁策略，它假设所有线程访问共享资源的时候不会出现冲突，既然不会出现冲突自然而然就不会阻塞其他线程的操作。

因此，线程就不会出现阻塞停顿的状态。那么，如果出现冲突了怎么办？无锁操作是使用**CAS(compare and swap)**又叫做比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操作直到没有冲突为止。

操作过程

CAS比较交换的过程可以通俗的理解为CAS(V,O,N)，包含三个值分别为：

V 内存地址存放的实际值
O 预期的值（旧值）
N 更新的新值。

更新一个变量的时候，只有当变量的预期值A和内存地址V当中的实际值相同时，才会将内存地址V对应的值修改为B。

举例：

1.在内存地址V当中，存储着值为10的变量。

2.此时线程1想把变量的值增加1.对线程1来说，旧的预期值A=10，要修改的新值B=11。

3.在线程1要提交更新之前，另一个线程2抢先一步，把内存地址V中的变量值率先更新成了11。

4.线程1开始提交更新，首先进行A和地址V的实际值比较，发现A不等于V的实际值，提交失败。

5.线程1 重新获取内存地址V的当前值，并重新计算想要修改的值。此时对线程1来说，A=11，B=12。这个重新尝试的过程被称为自旋。

6.这一次比较幸运，没有其他线程改变地址V的值。线程1进行比较，发现A和地址V的实际值是相等的。

7.线程1进行交换，把地址V的值替换为B，也就是12.

Java锁的种类

公平锁/非公平锁

公平锁：加锁前先查看是否有排队等待的线程，有的话优先处理排在前面的线程，先来先得。
非公平锁：线程加锁时直接尝试获取锁，获取不到就自动到队尾等待。

可重入锁/不可重入锁

可重入锁：当线程获取某个锁后，还可以继续获取它，可以递归调用，而不会发生死锁

Java的可重入锁有：reentrantLock（显式的可重入锁）、synchronized（隐式的可重入锁）

不可重入锁：与可重入相反，获取锁后不能重复获取，否则会死锁（自己锁自己）。

独享锁/共享锁

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

对ReentrantLock和Synchronized而言都是独占锁

共享锁：指该锁可以被多个线程锁持有。

对ReentrantReadWriteLock其读锁是共享，其写锁是独占写的时候只能一个人写，但是读的时候，可以多个人同时读

互斥锁/读写锁

互斥锁

在访问共享资源之前对其进行加锁操作，在访问完成之后进行解锁操作。加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。

如果解锁时有一个以上的线程阻塞，那么所有该锁上的线程都被编程就绪状态，第一个变为就绪状态的线程又执行加锁操作，那么其他的线程又会进入等待。在这种方式下，只有一个线程能够访问被互斥锁保护的资源。举个形象的例子：多个人抢一个马桶。

读写锁

读写锁既是互斥锁，又是共享锁，read模式是共享，write是互斥(排它锁)的。

读写锁有三种状态：读加锁状态、写加锁状态和不加锁状态

乐观锁/悲观锁

乐观锁

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。

分段锁

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

并发容器类的加锁机制是基于粒度更小的分段锁，分段锁也是提升多并发程序性能的重要手段之一。

容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

在ConcurrentHashMap中使用了一个包含16个锁的数组，每个锁保护所有散列桶的1/16，其中第N个散列桶由第（N mod 16）个锁来保护。假设使用合理的散列算法使关键字能够均匀的分部，那么这大约能使对锁的请求减少到越来的1/16。也正是这项技术使得ConcurrentHashMap支持多达16个并发的写入线程。

自旋锁

自旋锁，就是指当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。

自旋锁适用于锁保护的临界区很小的情况，临界区很小的话，锁占用的时间就很短。自旋等待不能替代阻塞，虽然它可以避免线程切换带来的开销，但是它占用了CPU处理器的时间。

如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好，反之，自旋的线程就会白白消耗掉处理的资源，它不会做任何有意义的工作，这样反而会带来性能上的浪费。