【web】java多线程（常见锁策略+synchronized原理）

public class Main {
    public static void main(String[] args) {
        ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
        Lock readLock = readWriteLock.readLock();
        Lock writeLock = readWriteLock.writeLock();

        readLock.lock();
        Thread t = new Thread(){
            @Override
            public void run() {
                readLock.lock();
                System.out.println("读+读 可以访问到");
            }
        };

        t.start();
    }
}

1.2 可重入锁 vs 不可重入锁

可重入锁(ReentrantLock)：允许同一个线程多次申请同一把锁。

比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也叫做递归锁）。

Java里只要以Reentrant开头命名的锁都是可重入锁，而且JDK提供的所有现成的Lock实现类

synchronized 锁是可重入锁

而 Linux 系统提供的 mutex 是不可重入锁。

不可重入锁：在一个线程加锁后，第二次加同样的锁阻塞了，就是不可重入锁

public class Main {
    public static void main(String[] args) {
        // 同一个线程申请同一把锁
        Lock lock = new ReentrantLock();
        lock.lock(); // main 线程锁
        lock.lock(); // 如果能申请同一把锁，就能执行下面的代码
        System.out.println("可执行之后的代码");
    }
}

1.3 公平锁 vs 不公平锁

公平(fair)：按照申请锁的次序获取到锁

公平锁：先到先得，要维护一个阻塞队列，所以公平锁实复杂。

不公平锁：不遵守先到先得的顺序，后来的线程运气好刚来就得到锁。

操作系统内部的线程调度就可以视为是随机的. 如果不做任何额外的限制, 锁就是非公平锁. 如果要想实现公平锁, 就需要依赖额外的数据结构, 来记录线程们的先后顺序
公平锁和非公平锁没有好坏之分, 关键还是看适用场景

synchronized 锁是不公平锁

public class Main {
    public static void main(String[] args) {
        Lock lock = new ReentrantLock(true);   // 公平锁
        Lock lock2 = new ReentrantLock(false); // 不公平锁
        Lock lock3 = new ReentrantLock();          // 默认不公平锁
    }
}

总结：synchronized 锁是独占锁 + 可重入锁 + 不公平锁

1.4 乐观锁 vs 悲观锁

严格来讲，乐观锁和悲观锁是实现并发控制的两种解决方案，和“锁”的概念不是一个层级的概念。

乐观锁：评估后，并发情况中，多个线程修改一个共享资源的情况比较少，可以采用轻量级锁（无锁）

悲观锁：多个线程会频繁地修改同一个共享资源，必须使用互斥的方式（锁lock)来进行并发控制。

Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略

1.5 互斥锁 vs 自旋锁（重量级锁 vs 轻量级锁）

锁的实现导致的锁的种类不同：

默认情况下，我们的锁的实现，是采用OS提供的锁(mutex锁:互斥锁) 一旦请求锁失败，会导致当前线程（请求锁失败的线程）会放弃CPU，进入阻塞状态，把自己加到锁的阻塞队列中，等待被唤醒。必须进入到内核态，一旦放弃CPU，再到获取CPU，时间相隔很久(站在CPU指令角度)

性能太低。

思考不需要进行触发线程调度的锁的实现方式。

CAS（Compare and swap）

1. 比较 A 与 V 是否相等。（比较）

2. 如果比较相等，将 B 写入 V。（交换）

3. 返回操作是否成功。

硬件提供了CAS机制-> OS提供了CAS机制->JVM提供了CAS机制

自旋锁：

优点: 没有放弃 CPU, 不涉及线程阻塞和调度, 一旦锁被释放, 就能第一时间获取到锁
缺点: 如果锁被其他线程持有的时间比较久, 那么就会持续的消耗 CPU 资源. (而挂起等待的时候是不消耗 CPU 的)

🚌2. synchronized锁的原理

2.1 synchronized锁的基本特点

策略:可重入的＋不公平的＋独占锁

基本特点：

开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.
实现轻量级锁的时候大概率用到的自旋锁策略
是一种不公平锁
是一种可重入锁
不是读写锁

2.2 synchronized锁的加锁过程

JVM 将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级。

1) 偏向锁：第一个尝试加锁的线程, 优先进入偏向锁状态

2) 轻量级锁：随着其他线程进入竞争, 偏向锁状态被消除, 进入轻量级锁状态(自适应的自旋锁). 此处的轻量级锁就是通过 CAS 来实现

3) 重量级锁：如果竞争进一步激烈, 自旋不能快速获取到锁状态, 就会膨胀为重量级锁此处的重量级锁就是指用到内核提供的 mutex

什么是偏向锁?

偏向锁不是真的加锁, 而只是在锁的对象头中记录一个标记(记录该锁所属的线程). 如果没有其他线程参与竞争锁, 那么就不会真正执行加锁操作, 从而降低程序开销. 一旦真的涉及到其他的线程竞争, 再取消偏向锁状态, 进入轻量级锁状态

2.3 synchronized的锁优化操作

1. 锁消除优化

Vector v = new Vector(); V....

前提:Vector为了做到线程安全，每个方法都用synchronized 修饰了

但是当实际上，我们的代码中只有主线程->所有做线程保护的操作都是无用功（(加锁、释放锁)编译器＋JVM判断出只有一个线程时，就会消除掉所有锁的操作，提升性能!!

public class Main {
    private static synchronized void method(){
        System.out.println("锁优化");
    }

    // 有没有锁无关紧要
    public static void main(String[] args) {
        method();
    }
}

2. 锁粗化优化

前提:已经没办法进行锁消除的情况下

public class Main2 {
    static class MyThread extends Thread{
        int i = 0;
        // 加锁粒度过细，性能较低
        @Override
        public synchronized void run() {
            i++;
        }
    }
    static class MyThread2 extends Thread{
        int i = 0;
        // 加锁粒度适中，提升性能
        @Override
        public synchronized void run() {
            i++;
            i++;
            i++;
        }
    }
}

3. 锁升级优化

就是synchronized 锁的加锁过程

4. synchronized的锁优化总结

锁消除，能消除，尽量消除
锁粗化，看粒度是不是太细，尝试粗化
锁升级
JVM发现一定是多线程场景来了大部分对象不会被当成锁来使用＋对象头空间始终存在->对象头里就可以暂存一些其他信息
【从第一个线程尝试加锁到第二个线程尝试加锁】期间该对象锁，偏向于第一个线程。这个线程过来的时候，走的是快速通道 ->对象头来保存偏向哪个线程
【从有多个线程参与抢锁开始】︰一旦退出偏向状态，就无法回到偏向状态了优先尝试使用轻量级锁(cas + spin lock，不进入内核态，只在JVM的用户态，解决锁的竞争问题)->对象头里保存轻量级锁的地址
对象头里保存轻量级锁的地址 spin之后，还拿不到锁or自适应的情况下，spin之后，仍然拿不到锁走到重量级锁(放弃CPU，阻塞。需要内核态参与) ->对象头里保存重量级锁的地址