Java并发
一、锁
1. 偏向锁
1. 思想背景
来源：HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同 一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。
原理：在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出 同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否 存储着指向当前线程的偏向锁。
悟：偏向锁的来源就是为了节省当同一个线程访问临界区资源的时候频繁CAS加锁解锁操作的开支，同样这也是偏向锁使用的场景，即只有一个线程访问临界区资源的情况
Java对象头中的Mark Word结构：
image
2. 偏向锁的加锁
当一个线程访问同步块并 获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出 同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁：
如果当前对象头的线程ID指向了该线程，那么说明已经获得了锁
否则，判断对象头中的Mark Word锁的标识是否是偏向锁(对应就是锁标志位为01，是否是偏向锁为1)
如果是偏向锁，那么会使用CAS将线程ID指向该线程
否则，则使用CAS竞争锁(说明此时是更高级的轻量锁或者重量锁，需要竞争才行)
最顺利的情况就是线程ID指向该线程，这就对应只有一个线程频繁访问临界区资源的情况，此时能够最大程度的减少CAS操作
3.偏向锁的撤销
偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时， 持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点(在这个时间点上没有正 在执行的字节码)：
首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着
如果不处于活动状态，则将对象头设置成无锁状态
否则，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word进行更改：
要么重新偏向于其他线程，
要么恢复到无锁
要么标记对象不适合作为偏向锁(此时需要升级锁)
最后唤醒暂停的线程
4. 过程图
image
2. 轻量锁
1. 思想背景
起源：由于线程的阻塞/唤醒需要CPU在用户态和内核态间切换，频繁的转换对CPU负担很重，进而对并发性能带来很大的影响
原理：在只有两个线程并发访问资源区是，一个持有锁，另一个进行自旋等待
2. 轻量锁加锁
线程在执行同步块之前，JVM会先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中(Displaced Mark Word-即被取代的Mark Word)做一份拷贝
拷贝成功后，线程尝试使用CAS将对象头的Mark Word替换为指向锁记录的指针(将对象头的Mark Word更新为指向锁记录的指针，并将锁记录里的Owner指针指向Object Mark Word)
如果更新成功，当前线程获得锁，继续执行同步方法
如果更新失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁，若自旋后没有获得锁，此时轻量级锁会升级为重量级锁，当前线程会被阻塞
3. 轻量级锁解锁
解锁时会使用CAS操作将Displaced Mark Word替换回到对象头
如果解锁成功，则表示没有竞争发生
如果解锁失败，表示当前锁存在竞争，锁会膨胀成重量级锁，需要在释放锁的同时唤醒被阻塞的线程，之后线程间要根据重量级锁规则重新竞争重量级锁
4. 流程图
image
3. 三种锁比较
image
二、处理器和Java中原子性操作的实现
1. 处理器原子性操作的实现
处理器级别内存操作的原子性保证有两种机制：总线锁定和缓存锁定。(注意：处理器会自动保证基本的内存操作的原子性，即对于内存中某一个地址数据的访问时保证同一时刻只有一个处理器可以)
1. 总线锁
总线锁比较简单粗暴，对于需要限制的共享变量，通过LOCK信号，使得在操作该贡献变量的时候，一个处理器独占共享内存
2. 缓存锁
总线锁使得只能有一个处理器访问内存，其他处理器不能够操作内存里的其他数据，属于“一刀切”“一棒子打死”的做法，所以开销比较大。
所谓“缓存锁定”是指内存区域如果被缓存在处理器的缓存 行中，并且在Lock操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不在总线上声 言LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子 性，因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时，会使缓存行无效，从而使他们重新从内存中获取数据。
虽然，缓存锁更好，但是总线锁并没有完全弃用。有些情况，缓存锁没有办法发挥，此时便需要总线锁了。
2. Java中实现原子操作的原理
不管是加锁还是其他方法，Java都是使用循环CAS的方式实现原子操作的。
三、Java内存模型
一、内存模型
JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存(Main Memory)中，每个线程都有一个私有的本地内存(Local Memory)，本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。
1. 指令重排序
在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序：
编译器优化的重排序：编译器在不改变串行语义的前提下，可以安排语句的执行顺序
指令级并行的重排序：现代处理器才用了指令级的并行技术(流水线技术)来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应 机器指令的执行顺序。
内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上 去可能是在乱序执行。(我们不用关注内存系统的重排序，其不再JMM的覆盖范围)
2. 数据依赖性
如果两个操作中至少有一个操作是写操作的话，那么就说这两个操作之间具有数据依赖性。
编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。(这里的顺序依赖性只针对单线程下的指令)，即指令重排序必须保证单线程下的串行语义。
3. 顺序一致性
当程序未正确同步时，就可能存在数据竞争，所谓数据竞争就是：1. 在一个线程中写入一个变量 2. 在另一个线程中读同一个变量 3. 且写和读没有通过同步来排序
而正确同步的线程，不会发生数据竞争。
如果程序是正确同步的，那么程序的执行具有顺序一致性。
顺序一致性模型有两条规则：
一个线程中的所有操作必须按照程序的顺序来执行。
(不管程序是否同步)所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中，每个操作都必须原子执行且立刻对所有线程可见。
可见，这两条规则是非常理想化的，如果线程的操作是按照我门程序中写的顺序执行，且不同线程之间的操作立刻可见，那么并发编程会是一件很容易的事情。但是很遗憾JMM一条也没有遵守顺序一致性模型。对于第一条，编译器和处理器都会对指令进行重排序，所以执行顺序和书写顺序并不相同；对于第二条更不可能了。
但是，在Java中同步了的程序具有顺序一致性的效果：
[图片上传失败...(image-2082d2-1583984997624)]
因此，Java保证只要是同步了的代码，程序员可以把他当做是在顺序一致性模型下运行的一样
二、Volatile内存语义
volatile变量读写的内存语义：
当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存(注意：是所有的共享变量，不光是volatile变量)
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量(注意：这里也是所有的共享变量)
关于线程如何确定要将共享变量的值刷新到内存，以及为何要从内存读取最新的值，涉及到cpu之间的通信、嗅探等，这里不做展开。
悟：volatile变量的内存语义保证了在读volatile变量之前，内存中所有的共享变量都是最新的，也就是之前执行的的任意线程的写操作都对本次的读操作可见；同样，本次写操作都对之后任意线程执行的读操作可见。而且，volatile的读操作和写操作都具有原子性。
1. volatile读写操作对重排序的影响
JMM的内存语义解决了内存可见性可能会引发的问题，但是还有一种问题可能会产生，那就是指令重排序的问题：
volatile a = 0;
int b = 1;
public void A (){
b = 2; // 1
a = 1; // 2
}
public void B() {
int c = 0;
if (a == 1) // 3
c = b; // 4
}
假如volatile不会对重排序有任何影响的话，那么由于代码1和代码2两处没有数据依赖性，所以二者是可以重排序的，我们假设代码2在代码1之前被执行，此时由于a是volatile变量，所以将a = 1， b = 1刷新进入主内存；如果这时候方法A所在的线程cpu时间片用完了，轮到了方法B在另一个线程中执行，由于a是volatile变量所以代码3处执行的时候会将b = 1， a = 1从主内存中读出，此时代码4再执行的话c会变为1，而不是预想的2(因为按照我们书写的顺序来看，a=1发生在b=2之后)
发生这种错误的原因在于：volatile变量写操作与在其之前的代码发生了重排序，使得刷新内存的时机提早了，可能会漏掉我们写在volatile变量赋值操作之前的那些共享变量的修改。所以这就引出了volatile变量对指令重排序的第一个影响：
第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保 volatile写之前的操作不会被编译器重排序到volatile写之后。换句话说，以volatile写这行代码为分割线，之前的对共享变量的各种读写操作的指令不管如何进行重排序，都不可能跑到volatile写操作之后执行，确保volatile写操作刷新内存里共享变量的值时程序员希望发生的变动都能够正确的刷新到内存中
同理，对应也有volatile变量对指令重排序的另一个影响：
第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保 volatile读之后的操作不会被编译器重排序到volatile读之前。确保volatile读操作读取内存里的最新值是程序员希望读到的、操作的值
另外还有一条影响：
第一个操作是volatile写，第二个操作是volatile读时，不能重排序
三、Lock锁的内存语义
Java中的锁的内存语义和volatile一模一样，而ReentrantLock加锁和释放锁的原理就是通过操作一个volatile状态变量来实现。
1. ReentrantLock公平锁加锁的实现
ReentrantLock有自己的继承链，但是真正开始加锁是从自己的tryAcquire方法：
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState(); // 获取锁的开始，首先读volatile变量state
if (c == 0) {
if (isFirst(current) && compareAndSetState(0, acquires)) { // ------------- 代码 1------------
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
重点在代码1，注意：这里的条件中有一个CAS操作，也就是说多个竞争锁的线程中可能都能够执行到这里，但是只有一个能够使得该条件返回true，其他都返回false。执行CAS返回true的线程通过setExclusiveOwnerThread进行独占式绑定。而，CAS返回false的线程最终会直接从该加锁方法中返回false，意味着加锁失败。
2. ReentrantLock公平锁释放锁的实现
ReentrantLock公平锁的释放最终的实现是在其父类中实现的，开始释放锁是在tryRelease方法中：
protected final boolean tryRelease(int releases){
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c); // 释放锁的最后，写volatile变量state return free;
}
由于线程已经得到了锁，所以释放锁的方法中没有任何CAS操作API的调用，释放锁的逻辑是：判断c的值，如果c为0了，说明要释放锁，此时需要解除线程对该锁的绑定；如果c没有变为0，只是简单的更新state，永远不要忘了state是一个volatile变量。
四、final的内存语义
五、再理解happen-before原则
happen-before原则是JMM对程序员的一种保证，即一个操作A happen-before另一个操作B，意味着：
A的结果对B可见，且A的执行顺序在B之前
并不意味着Java具体实现必须要按照happen-before指定的顺序来执行，如果重排序后执行结果与按照happen-before关系来执行的结果一致，那么也是允许的
也就是说，JMM的happen-before只是保证了串行语义的顺序和正确同步的顺序。也就是说，A happen-before B如果A与B之间有依赖关系、同步关系的话，那么A确实在B之前执行；如果A与B之间没有依赖、没有同步关系的话，那么A与B之间的执行顺序是可以改变的，但是对于程序员来说，结果都一样，没所谓，所以认为A执行在B之前也是可以的。
三、线程
四、Java中的Lock
使用Lock比使用synchronized有很多优点：
Lock更灵活，当一个线程同时涉及到多个锁的时候，使用synchronized就显得很麻烦了，比如在获取B锁之后要释放A锁，在获取C锁之后要放弃B锁
Lock对加锁有更多的选择：Lock支持非阻塞地获取锁、能被中断地获取锁(当获取到锁的线程被中断时，中断异常将会被抛出，同时释放锁)、超时获取锁
Java中Lock中常见的API方法
image
队列同步器
Java中的队列同步器AbstractQueuedSynchronizer是用来构建锁和其他同步组件的基础框架。它使用一个int成员变量表示同步状态，并且提供了CAS方法，通过内置的FIFO队列来完成资源获取线程的排队工作。
Java中的锁和其他的同步组件一般都是在内部定义一个同步器的实现子类，通过同步器定义的方法来管理同步状态。锁是面向程序员的，而其内部同步器的实现是面向设计者的。
同步器提供给同步组件的方法主要就是上文Java锁语义中提到的：
getState
setState
compareAndSetState
三个方法。
一、队列同步器的实现原理
Java中队列同步器内部维护了一个双向的队列，队列的作用就是将没有竞争到锁的线程包装成一个Node节点插入到队列中，其中头结点代表持有锁的线程。当然，有一些具体的信息都包括在Node节点中：
image
而线程之所以表现为一种阻塞状态，是因为获取不到锁的线程会陷入一个自旋的循环中不断地尝试获取锁而导致线程卡在lock()方法处，具体细节下面再说。需要注意的是，AQS中将竞争锁失败的线层包装成节点插入到队列的尾部是一个CAS操作，这保证了队列插入顺序在多线程下的正确性。
二、独占式同步状态获取与释放
上面说了，Lock的实现基本上是委托于内部AQS的子类，以ReenTrantLock为例，其内部有一系列Sync的内部类是AQS的具体实现类，而ReentrantLock的lock方法内部调用了sync的acquire(int arg):
public final void acquire(int arg) {
if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();
}
其中的tryAcquire(arg)方法的实现在上文中展示过了，tryAcquire方法是多个线程竞争锁发生的地方，只有一个锁能够返回true并且独占锁，其他的都会返回false。
而其他的tryAcquire返回false的线程会调用acquireQueued实现将线程包装成双向队列的Node并加入的同步队列中。
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
重点关注方法内部的for循环，通过这个循环我们知道只有头结点的后继节点会在自旋中调用tryAcquire方法尝试获取锁，而其他的后继节点只是在空自旋；然后，当头结点代表的线程释放锁之后，将其移除双向队列的地方在后继节点代替它成为头结点的地方，看到了将被阻塞的节点加入到队列中的操作，接下来该看看是如何把一个阻塞的线程包装成双向链表的节点的：
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
对于独占式获取锁的过程，该方法传递的参数是Node.EXCLUSIVE，代表一个正阻塞在独占状态下的节点。该方法实现的前半部分负责调用CAS方法将该节点加入到双向队列的尾部，而最后有调用了一次enq(Node)方法：
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
Q:这里点疑惑好像又加入了一次尾部，是不是有点重复了？
小结
以ReentrantLock为例，独占式锁的加锁流程：
ReentrantLock的lock方法的实现委托给了ReentrantLock内部的AQS的实现类Sync的acquire(int arg)方法，而Sync并没有重写该方法，acquire的具体实现在抽象父类AbstractQueuedSynchronizer
acquire方法会调用tryAcquire方法尝试获取锁，这里是发生多个线程竞争锁的地方；其中只有一个线程能够通过CAS方法获取到锁返回true，竞争失败的线程都会返回false
那些竞争失败的线程首先会被addWaiter方法包装成一个双向队列的节点并且加入到双向队列的尾部
之后会在acquireQueued方法进行自旋操作，但是只有头结点的后继节点才会调用tryAcquire方法尝试获取锁，其他的后继节点只会空自旋
