并发编程—锁总结

并发编程中需要处理的两个关键问题：线程之间的通信和线程之间如何同步。

通信机制：是指线程之间以何种方式交换信息。主要有共享内存和消息传递。

        共享内存：线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信。

        消息传递：线程之间没有公共状态，通过发送消息显式通信。

同步：是指程序中用于控制不同线程间操作发生相对顺序的机制。

        在共享内存模型中，程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。

        在消息传递模型中，消息发送必须在消息接收之前，所以同步是隐式的。

Java并发编程采用的是共享内存模型，整个通信是隐式的，对程序员是完全透明的，所以要求程序员理解线程之间通信的工作机制。

Java内存模型

JMM：Java Memory Model，即Java内存模型。内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中变量存储内存和从内存中取出变量这样的底层细节。

从抽象角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory），本地内存中存储了该线程以读/写共享变量的副本。

共享变量：在Java中，所有实例域、静态域和数组元素都存储在堆内存中，堆内存在线程之间共享。

内存模型抽象结构：

可见性

为什么会存在内存可见性问题？

对于共享变量，线程每次读取的是本地内存中共享变量的副本，写入的时候也直接修改本地内存中副本的值，然后在某个时间点上再将工作内存与主内存中的值进行同步。这样导致的问题是，如果线程A对某个变量进行了修改，线程B却有可能看不到线程A对共享变量所做的修改。即多个本地内存和主内存之间不是完全同步的。

JMM通过控制主内存与每个线程的本地内存之间的交互，提供内存可见性的保证。

线程之间通信：

重排序

为了优化程序性能，编译器和处理器会对指令序列进行重新排序。编译器和处理器在重排序时会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。

重排序类型： 编译器重排序、CPU指令重排序、CPU内存重排序

数据依赖性仅针对单个处理器中和单个线程中的执行操作，不用处理器之间和不同线程之间的数据依赖性不被考虑。由于CPU使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。第三类是造成“内存可见性”问题的主因。

重排序和内存可见性关系？

例：初始X=0，Y=0。两个线程执行完毕结果？

线程1: X=1;a=Y

线程2: Y=1;b=X

两个线程的指令都没有重排序，但是线程之间可以顺序也可以交叉，仍然可能出现多种结果。其中a=0，b=0的结果：线程1先执行X=1，后执行a=Y，但此时X=1还在自己的Store Buffer里面，没有及时写入主内存中。

可见Store Buffer的延迟写入是重排序的一种，称为内存重排序（Memory Ordering）。

常用关键字

volatile关键字

为了确保共享变量能被准确和一致地更新，线程应该确保通过排他锁单独获得这个变量。Java语言提供了volatile，在某些情况下比锁要更加方便。如果一个字段被声明成volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的。

volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”（当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值）。

volatile的三重功效：64位写入的原子性、内存可见性和禁止重排序。
 

使用场景1：64位写入的原子性

因为JVM的规范并没有要求64位的long或者double的写入是原子的。在32位的机器上，一个64位变量的写入可能被拆分成两个32位的写操作来执行。这样一来，读取的线程就可能读到“一半的值”。解决办法也很简单，在long前面加上volatile关键字。
 

volatile场景2：重排序，单例模式线程安全的写法（DCL）

public class Singleton {
    private static Singleton instance;
        public static Singleton getInstance() {
            if (instance == null) {
                synchronized(Singleton.class) {
                    if (instance == null) {
                        // 此处代码有问题
                        instance = new Singleton();
                    }
                }
            } 
            return instance;
        }
}

上述的 instance = new Singleton(); 代码有问题：其底层会分为三个操作：
1. 分配一块内存。
2. 在内存上初始化成员变量。
3. 把instance引用指向内存

操作2和操作3可能重排序，即先把instance指向内存，此时可能拿到一个未完全初始化的对象，直接访问成员变量可能出错。这就是典型的“构造方法溢出”问题。
解决办法就是为instance变量加上volatile修饰。

底层原理

volatile底层实现原理_yelang0的博客-CSDN博客_volatile原理

volatile可见性的实现就是借助了CPU的lock指令，通过在写volatile的机器指令前加上lock前缀，使写volatile具有以下两个原则：

1. 写volatile时处理器会将缓存写回到主内存。
2. 一个处理器的缓存写回到内存会导致其他处理器的缓存失效。

volatile有序性的保证就是通过禁止指令重排序来实现的。指令重排序包括编译器和处理器重排序，JMM会分别限制这两种指令重排序。

那么禁止指令重排序又是如何实现的？

答案是加内存屏障。JMM为volatile加内存屏障有以下4种情况：

在每个volatile写操作的前面插入一个StoreStore屏障，防止写volatile与后面的写操作重排序。
在每个volatile写操作的后面插入一个StoreLoad屏障，防止写volatile与后面的读操作重排序。
在每个volatile读操作的后面插入一个LoadLoad屏障，防止读volatile与后面的读操作重排序。
在每个volatile读操作的后面插入一个LoadStore屏障，防止读volatile与后面的写操作重排序。
 

synchronized关键字

synchronized实现同步的基础：Java中的每一个对象都可以作为锁。表现为以下三种形式：

        对于普通同步方法，锁是当前实例的对象；    

        对于静态同步方法，锁是当前类的Class对象；

        对于同步块，锁是Synchonized括号里配置的对象。

实现原理

通过javap -c -v反编译可以看出：

代码块同步是使用monitorenter和monitorexit指令实现的。monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。

方法的同步？

Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。

为什么说jdk1.6之前，synchronized效率低？

JVM是通过进入、退出对象监视器(Monitor) 来实现对方法、同步块的同步的，而对象监视器的本质依赖于底层操作系统的 互斥锁(Mutex Lock) 实现。

“锁” 其实是互斥同步的具体实现，而互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要用户态转到内核态来完成。这些操作给系统的并发性能带来了很大的压力。所以，优化的方向就是减少线程的阻塞，因为挂起线程和恢复线程需要切换到操作系统的内核状态。

Java 1.6 为了减少获得锁和释放锁带来的性能损耗，引入了 “偏向锁“ 和 ”轻量级锁“ 

1、Java对象头

为什么放在对象头。

如果对象是数组类型，虚拟机用3个字宽存储对象头，如果非数组类型，则用2字宽存储对象头。

32位和64位对应对象头存储：

Java对象头里的Mark Word里默认存储对象的HashCode、分代年龄和锁标记位。

32位存储如下：是否是偏向锁：1表示是

运行期间，Mark Word里存储的数据会随着锁标志位的变化而变化。

锁的状态总共有四种：无锁状态、偏向锁、轻量级锁和重量级锁。级别依次从低到高。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁（但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级）。
 

 2、锁升级过程

偏向锁

大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。因此偏向锁是在只有一个线程执行同步块时进一步提高性能。

当线程1访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，只需要比较当前线程的threadID和Java对象头（Mark Word）中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态（锁标识设置为01，偏向锁0），其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

1.6之后的虚拟机默认启用偏向锁，可以使用JVM参数来关闭：-XX：-UseBiasedLocking=false；程序将默认进入轻量级锁状态。

轻量级锁

轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用产生的性能消耗。轻量级锁所适应的场景是线程交替执行同步块的情况，如果存在同一时间访问同一锁的情况，就会导致轻量级锁膨胀为重量级锁。

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

轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。

重量级锁

对象监视器的本质依赖于底层操作系统的互斥锁(Mutex Lock)，而操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要相对比较长的时间，这就也是为什么Synchronized效率低的原因。因此，这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”。JDK中对Synchronized做的种种优化，其核心都是为了减少这种重量级锁的使用。JDK1.6以后，为了减少获得锁和释放锁所带来的性能消耗，提高性能，引入了“轻量级锁”和“偏向锁”。

锁优化：

虚假唤醒问题：

锁分类 

• 乐观锁/悲观锁

        悲观锁认为数据发生并发冲突的概率很大，读操作之前就上锁。synchronized关键字，ReentrantLock都是悲观锁的典型。
        乐观锁认为数据发生并发冲突的概率比较小，读操作之前不上锁。等到写操作的时候再判断数据在此期间是否被其他线程修改。如果被修改了就把数据重新读出，重复该过程。一般会使用“数据版本机制”或“CAS操作”来实现。Java中java.util.concurrent.atomic包下面的原子变量类就是典型的乐观锁，使用了CAS(Compare and Swap 比较并交换)实现的。

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

• 独占锁/共享锁

        独占锁是指该锁一次只能被一个线程所持有。共享锁是指该锁可被多个线程所持有。Synchronized、ReentrantLock都属于独占锁，但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，写锁是独占锁。

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

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

        互斥锁/读写锁就是具体实现，ReentrantLock是互斥锁，ReadWriteLock是读写锁，既是共享的又是独占的。

• 可重入锁

        又称递归锁，是指在一个线程外层方法获取到锁，进入内层方法会自动获取锁。

synchronized关键字，就是可重入锁。如果不是可重入锁，method2不会被执行，造成死锁。

public void synchronized method1() {
    // ...
    method2();
} 
public void synchronized method2() {
    // ...
}

• 公平锁/非公平锁

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

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

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

• 自旋锁

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

        

Lock接口

Lock是JUC工具包的一个接口，常用的方法是lock()/unlock()。lock()不能被中断，对应的lockInterruptibly()可以被中断。

public interface Lock {
    void lock();
    void lockInterruptibly() throws InterruptedException;
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock();
    Condition newCondition();
}

ReentrantLock类继承关系

ReentrantLock本身没有代码逻辑，实现都在其内部类Sync中：

sync.acquire(1);

sync.release(1);

public class ReentrantLock implements Lock, java.io.Serializable {
    private final Sync sync;
    
    abstract static class Sync extends AbstractQueuedSynchronizer {
        ...
    }
     
    public void lock() {
        sync.acquire(1);
    }

    public void unlock() {
        sync.release(1);
    }


    public ReentrantLock() {
        sync = new NonfairSync();
    }

    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }
}

Sync是一个抽象类，它有两个子类FairSync与NonfairSync，分别对应公平锁和非公平锁。ReentrantLock的构造方法会通过传入参数决定锁是公平还是非公平的。默认非公平。

实现原理

Sync的父类AbstractQueuedSynchronizer，被称为队列同步器（AQS）。父类是AbstractOwnableSynchronizer。

核心要素：

• 标记该锁的状态 state；
• 标记持有锁的线程 exclusiveOwnerThread
• 支持对一个线程进行阻塞或唤醒 LockSupport；
• 队列维护所有阻塞线程。

1）、标记：

public abstract class AbstractOwnableSynchronizer implements java.io.Serializable {
    private transient Thread exclusiveOwnerThread; // 记录持有锁的线程
    ...
}

public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {

    /**
     * The synchronization state.
     */
    private volatile int state;  // 记录锁的状态，通过CAS修改state值

    ...
}

锁状态通过一个volatile修饰的int值state体现：

当state=0时，没有线程持有锁，exclusiveOwnerThread=null；
当state=1时，有一个线程持有锁，exclusiveOwnerThread=该线程；
当state > 1时，说明该线程重入了该锁。
 

2）、阻塞或唤醒

Unsafe类提供了阻塞或唤醒线程的一对操作原语，也就是park/unpark。

public final class Unsafe {
    public native void unpark(Object thread);
    public native void park(boolean isAbsolute, long time);
}

LockSupport工具类对这一对原语做了封装：

public class LockSupport {
    // ...
    private static final Unsafe U = Unsafe.getUnsafe();
    public static void park() {
        U.park(false, 0L);
    } 
    public static void unpark(Thread thread) {
        if (thread != null)
        U.unpark(thread);
    }
}

3）、双向链表和CAS实现的阻塞队列。

public abstract class AbstractQueuedSynchronizer {
    // ...
    static final class Node {
    volatile Thread thread; // 每个Node对应一个被阻塞的线程
    volatile Node prev;
    volatile Node next;
    // ...
    } 
    private transient volatile Node head;
    private transient volatile Node tail;
    // ...
}

ReentrantReadWriteLock