Java多线程（二）——synchronized 详解

最新推荐文章于 2024-10-08 15:17:10 发布

m0_45198397

最新推荐文章于 2024-10-08 15:17:10 发布

阅读量5k

点赞数 6

分类专栏： Java秋招之路文章标签： java jvm 开发语言

本文链接：https://blog.csdn.net/m0_45198397/article/details/128558476

版权

Java秋招之路专栏收录该内容

4 篇文章 1 订阅

订阅专栏

2.3 synchronized 的用法分类

2.4 synchronized 的用法详解

2.5 synchronized总结+补充

3 synchronized 底层原理

3.1 synchronized 同步语句块的情况

3.2 synchronized 修饰方法的的情况

4 synchronized与其他同步方法的比较

4.1 synchronized 和 volatile 有什么区别？

4.2 synchronized 和 ReentrantLock 有什么区别？

5 synchronized优化

5.1 各个锁状态MarkWord 字节中的内容

总结

1 volatile 关键字

1.1保证变量可见性

在 Java 中，volatile 关键字可以保证变量的可见性，如果将变量声明为 volatile ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。（见下图）

volatile 关键字能保证数据的可见性，但不能保证数据的原子性。synchronized 关键字两者都能保证。

1.2 不能保证数据的原子性举例

public class VolatoleAtomicityDemo {
    public volatile static int inc = 0;

    public void increase() {
        inc++;
    }

    public static void main(String[] args) throws InterruptedException {
        ExecutorService threadPool = Executors.newFixedThreadPool(5);
        VolatoleAtomicityDemo volatoleAtomicityDemo = new VolatoleAtomicityDemo();
        for (int i = 0; i < 5; i++) {
            threadPool.execute(() -> {
                for (int j = 0; j < 500; j++) {
                    volatoleAtomicityDemo.increase();
                }
            });
        }
        // 等待1.5秒，保证上面程序执行完成
        Thread.sleep(1500);
        System.out.println(inc);
        threadPool.shutdown();
    }
}

正常情况下，运行上面的代码理应输出 2500。但你真正运行了上面的代码之后，你会发现每次输出结果都小于 2500。这是因为：自增操作 inc++ 不是原子性的，实际上，inc++ 其实是一个复合操作，包括三步：

读取 inc 的值。
对 inc 加 1。
将 inc 的值写回内存。

volatile 是无法保证这三个操作是具有原子性的，有可能导致下面这种情况出现：

线程 1 对 inc 进行读取操作之后，还未对其进行修改。线程 2 又读取了 inc的值并对其进行修改（+1），再将inc 的值写回内存。
线程 2 操作完毕后，线程 1 对 inc的值进行修改（+1），再将inc 的值写回内存。

这也就导致两个线程分别对 inc 进行了一次自增操作后，inc 实际上只增加了 1。如果想要保证上面的代码运行正确也非常简单，利用 synchronized 、ReentrantLock或者AtomicInteger都可以。

1.3 禁止JVM指令重排序

在 Java 中，volatile 关键字除了可以保证变量的可见性，还有一个重要的作用就是防止 JVM 的指令重排序。 如果我们将变量声明为 volatile ，在对这个变量进行读写操作的时候，会通过插入特定的 内存屏障 的方式来禁止指令重排序。

2 synchronized 关键字

2.1 概念及演进

synchronized 是 Java 中的一个关键字，翻译成中文是同步的意思，主要解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

在 Java 早期版本中，synchronized 属于 重量级锁，效率低下。这是因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。

不过，在 Java 6 之后， synchronized 引入了大量的优化如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，这些优化让 synchronized 锁的效率提升了很多。因此， synchronized 还是可以在实际项目中使用的，像 JDK 源码、很多开源框架都大量使用了 synchronized 。

2.2 对象锁和类锁

对象锁：在 Java 中，每个对象都会有一个 monitor 对象，这个对象其实就是 Java 对象的锁，通常会被称为“内置锁”或“对象锁”。可以防止多个线程同时访问这个对象的synchronized方法（如果一个对象有多个synchronized方法，只要一个线程访问了其中的一个synchronized方法，其它线程不能同时访问这个对象中任何一个synchronized方法）。类的对象可以有多个，所以每个对象有其独立的对象锁，互不干扰（类的不同对象之间异步）。

类锁：在 Java 中，针对每个类也有一个锁，可以称为“类锁”，每个类只有一个 Class 对象，所以每个类只有一个类锁（类的各个对象之间同步）。

2.3 synchronized 的用法分类

从两个维度上面分类：

1. 根据修饰对象分类：synchronized 可以修饰方法和代码块

修饰代码块：synchronized(this|object) {} / synchronized(类.class) {}

修饰方法：修饰非静态方法 / 修饰静态方法

引申：静态 synchronized 方法和非静态 synchronized 方法之间的调用互斥么？不互斥！如果一个线程 A 调用一个实例对象的非静态 synchronized 方法，而线程 B 需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。

2. 根据获取的锁分类
获取对象锁：synchronized(this|object) {} / 修饰非静态方法。如果一个对象有多个synchronized方法，只要一个线程访问了其中的一个synchronized方法，其它线程不能同时访问这个对象中任何一个synchronized方法。

获取类锁：synchronized(类.class) {} / 修饰静态方法

2.4 synchronized 的用法详解

用法详解，这篇讲得好！

2.5 synchronized总结+补充

线程同步方法是通过锁来实现，每个对象都有且仅有一个锁，这个锁与一个特定的对象关联，线程一旦获取了对象锁，其他访问该对象的线程就无法再访问该对象的其他非同步方法；
对于静态同步方法，锁是针对这个类的，锁对象是该类的Class对象。静态和非静态方法的锁互不干预。一个线程获得锁，当在一个同步方法中访问另外对象上的同步方法时，会获取这两个对象锁。
当多个线程等待一个对象锁时，没有获取到锁的线程将发生阻塞。
死锁是线程间相互等待锁锁造成的，一旦程序发生死锁，程序将死掉。
synchronized关键字是不能继承的。也就是说，基类的方法synchronized f(){} 在继承类中并不自动是synchronized f(){}，而是变成了f(){}。继承类需要你显式的指定它的某个方法为synchronized方法；
在定义接口方法时不能使用synchronized关键字。
构造方法不能使用synchronized关键字，构造方法本身就属于线程安全的，不存在同步的构造方法一说。但可以使用synchronized代码块来进行同步。
无论synchronized关键字加在方法上还是对象上，它取得的锁都是对象，而不是把一段代码或函数当作锁；
实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。
尽量不要使用 synchronized(String a) 因为 JVM 中，字符串常量池具有缓存功能。

3 synchronized 底层原理

synchronized 关键字底层原理属于 JVM 层面的东西。

3.1 synchronized 同步语句块的情况

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            System.out.println("synchronized 代码块");
        }
    }
}

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

当执行 monitorenter 指令时，线程试图获取锁也就是获取 对象监视器 monitor 的持有权。
在执行monitorenter时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。
对象锁的的拥有者线程才可以执行 monitorexit 指令来释放锁。在执行 monitorexit 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。
如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

3.2 synchronized 修饰方法的的情况

public class SynchronizedDemo2 {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。如果是实例方法，JVM 会尝试获取实例对象的锁。如果是静态方法，JVM 会尝试获取当前 class 的锁。不过其本质也是对对象监视器 monitor 的获取。

4 synchronized与其他同步方法的比较

4.1 synchronized 和 volatile 有什么区别？

synchronized 关键字和 volatile 关键字是两个互补的存在，而不是对立的存在！

volatile 关键字是线程同步的轻量级实现，所以 volatile性能肯定比synchronized关键字要好。但是 volatile 关键字只能用于变量而 synchronized 关键字可以修饰方法以及代码块。
volatile 关键字能保证数据的可见性，但不能保证数据的原子性。synchronized 关键字两者都能保证。
volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized 关键字解决的是多个线程之间访问资源的同步性。

4.2 synchronized 和 ReentrantLock 有什么区别？

1. 两者都是可重入锁

“可重入锁” 指的是自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增 1，所以要等到锁的计数器下降为 0 时才能释放锁。JDK 提供的所有现成的 Lock 实现类，包括 synchronized 关键字锁都是可重入的。

2. synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API

synchronized 是依赖于 JVM 实现的， JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。
ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。

3. ReentrantLock 比 synchronized 增加了一些高级功能

等待可中断 : ReentrantLock提供了一种能够中断等待锁的线程的机制，通过 lock.lockInterruptibly() 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
可实现公平锁 : ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。ReentrantLock默认情况是非公平的，可以通过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来制定是否是公平的。
可实现选择性通知（锁可以绑定多个条件）: synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制。ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition()方法。

如果你想使用上述功能，那么选择 ReentrantLock 是一个不错的选择。

关于 Condition接口的补充：

Condition是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例（即对象监视器），线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。在使用notify()/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知” ，这个功能非常重要，而且是 Condition 接口默认提供的。而synchronized关键字就相当于整个 Lock 对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程，这样会造成很大的效率问题。而Condition实例的signalAll()方法，只会唤醒注册在该Condition实例中的所有等待线程。

5 synchronized优化

JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，即：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁是单向的。这种策略是为了提高获得锁和释放锁的效率。

5.1 各个锁状态MarkWord 字节中的内容

1、无锁状态

25bit	4bit	1bit(是否是偏向锁)	2bit(锁标志位)
对象的hashCode	对象分代年龄	0	01

这里的 hashCode 是 Object#hashCode 或者 System#identityHashCode 计算出来的值，不是用户覆盖产生的 hashCode。

2、偏向锁状态

23bit	2bit	4bit	1bit	2bit
线程ID	epoch	对象分代年龄	1	01

这里线程ID 和 epoch 占用了 hashCode 的位置，所以，如果对象如果计算过 identityHashCode 后，便无法进入偏向锁状态，反过来，如果对象处于偏向锁状态，并且需要计算其 identityHashCode 的话，则偏向锁会被撤销，升级为重量级锁。

epoch字段：对于偏向锁，如果线程ID = 0 表示未加锁。

3、轻量级锁状态

30bit	2bit
指向线程栈锁记录的指针	00

这里指向栈帧中的 Lock Record 记录，里面当然可以记录对象的 identityHashCode。

4、重量级锁状态

30bit	2bit
指向锁监视器的指针	10

这里指向了内存中对象的 ObjectMonitor 对象，而 ObectMontitor 对象可以存储对象的 identityHashCode 的值。

5.2 锁的升级

1、偏向锁

偏向锁是针对于一个线程而言的，线程获得锁之后就不会再有解锁等操作了，这样可以省略很多开销。假如有两个线程来竞争该锁话，那么偏向锁就失效了，进而升级成轻量级锁了。

如果支持偏向锁（没有计算 hashCode），那么在分配对象时，分配一个可偏向而未偏向的对象（MarkWord的最后 3 位为 101，并且 Thread Id 字段的值为 0）。

a、偏向锁的加锁

偏向锁标志是未偏向状态，使用 CAS 将 MarkWord 中的线程ID设置为自己的线程ID，
1. 如果成功，则获取偏向锁成功。
2. 如果失败，则进行锁升级。
偏向锁标志是已偏向状态
1. MarkWord 中的线程 ID 是自己的线程 ID，成功获取锁
2. MarkWord 中的线程 ID 不是自己的线程 ID，需要进行锁升级

偏向锁的锁升级需要进行偏向锁的撤销。

b、偏向锁的撤销

对象是不可偏向状态
1. 不需要撤销
对象是可偏向状态
1. MarkWord 中指向的线程不存活
  1. 允许重偏向：退回到可偏向但未偏向的状态
  2. 不允许重偏向：变为无锁状态
2. MarkWord 中的线程存活
  1. 线程ID指向的线程仍然拥有锁
    1. 升级为轻量级锁，将 mark word 复制到线程栈中
  2. 不再拥有锁
    1. 允许重偏向：退回到可偏向但未偏向的状态
    2. 不允许重偏向：变为无锁状态

小结： 撤销偏向的操作需要在全局检查点执行。我们假设线程A曾经拥有锁（不确定是否释放锁），线程B来竞争锁对象，如果当线程A不在拥有锁时或者死亡时，线程B直接去尝试获得锁（根据是否允许重偏向（rebiasing），获得偏向锁或者轻量级锁）；如果线程A仍然拥有锁，那么锁升级为轻量级锁，线程B自旋请求获得锁。

2、轻量级锁

之所以是轻量级，是因为它仅仅使用 CAS 进行操作，实现获取锁。

a、加锁流程

如果线程发现对象头中Mark Word已经存在指向自己栈帧的指针，即线程已经获得轻量级锁，那么只需要将0存储在自己的栈帧中（此过程称为递归加锁）；在解锁的时候，如果发现锁记录的内容为0，那么只需要移除栈帧中的锁记录即可，而不需要更新Mark Word。

线程尝试使用 CAS 将对象头中的 Mark Word 替换为指向锁记录（Lock Record）的指针，如果成功，当前线程获得轻量级锁，如果失败，虚拟机先检查当前对象头的 Mark Word 是否指向当前线程的栈帧，如果指向，则说明当前线程已经拥有这个对象的锁，则可以直接进入同步块执行操作，否则表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。当竞争线程的自旋次数达到界限值（threshold），轻量级锁将会膨胀为重量级锁。

b、撤销流程

轻量级锁解锁时，如果对象的Mark Word仍然指向着线程的锁记录，会使用CAS操作，将Dispalced Mark Word替换到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在锁竞争，锁就会膨胀为重量级锁。

3、重量级锁

重量级锁（heavy weight lock），是使用操作系统互斥量（mutex）来实现的传统锁。当所有对锁的优化都失效时，将退回到重量级锁。它与轻量级锁不同竞争的线程不再通过自旋来竞争线程，而是直接进入堵塞状态，此时不消耗CPU，然后等拥有锁的线程释放锁后，唤醒堵塞的线程，然后线程再次竞争锁。但是注意，当锁膨胀（inflate）为重量锁时，就不能再退回到轻量级锁。