【JVM】学习笔记6 ——内存模型：Java并发操作的锁机制

Zkkkai

已于 2023-05-02 12:25:47 修改

阅读量192

点赞数

文章标签： jvm java 学习

于 2023-05-02 12:21:46 首次发布

本文链接：https://blog.csdn.net/weixin_43825107/article/details/130462624

版权

本文是个人JVM学习笔记整理，学习顺序主要基于 黑马程序员的JVM视频相关知识点参考 深入理解Java虚拟机（第三版） 欢迎大家讨论交流并指正错误。

本篇笔记为Java内存模型篇，主要为Java多线程并发操作时多数据安全的保障操作和优化。

前文：
【JVM】学习笔记1——JVM基本概念和结构
 【JVM】学习笔记2——垃圾回收基本概念与垃圾回收算法
 【JVM】学习笔记3——垃圾回收器及调优
 【JVM】学习笔记4——字节码指令及编译器代码处理
 【JVM】学习笔记5 ——类加载过程及类加载器

1. Java 内存模型

JMM 定义了一套在多线程读写共享数据时（成员变量、数组）时，对数据的可见性、有序性、和原子性的规则和保障

在此之前，主流程序语言（如C和C++等）直接使用物理硬件和操作系统的内存模型。因此，由于不同平台上内存模型的差异，有可能导致程序在一套平台上并发完全正常，而在另外一套平台上并发访问却经常出错，所以在某些场景下必须针对不同的平台来编写程序。

Java内存模型必须足够严谨，才能让Java的并发内存访问操作不会产生歧义；但是也必须定义得足够宽松，使得虚拟机的实现能有足够的自由空间去利用硬件的各种特性（寄存器、高速缓存和指令集中某些特有的指令）来获取更好的执行速度。

2. 原子性

2.1 问题：

两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果不一定是 0

static int i = 0;

Thread t1 = new Thread(() -> {
    for (int j = 0; j < 50000; j++) {
        i++;
    }
});

Thread t2 = new Thread(() -> {
    for (int j = 0; j < 50000; j++) {
        i--;
    }
});

2.2 分析

java中对静态变量的自增、自减操作不是原子操作。

对于i++和i–都需要对静态变量 i 取到操作数栈，之后和常量 1 做加法/减法运算，再将i重新存入静态变量中。

而Java内存模型中会将内存分为 主内存 和 工作内存

静态变量在主内存中，而自增自减操作在工作内存中完成。因此需要进行主存和工作内存的数据交换。

因此会出现两个线程同时获取静态变量对其同时操作的问题，导致一个线程的更新被覆盖。

2.3 解决方法 - synchronized （同步关键字）

语法

synchronized( 对象 ) { 
	要作为原子操作代码 
}

即给对象加锁，只有执行完代码块内的代码，才能解锁

如通过 Object对象为i++和i–操作加锁

static int i = 0;

static Object obj = new Object();

Thread t1 = new Thread(() -> {
    synchronized (obj) {
        for (int j = 0; j < 50000; j++) {
            i++;
        }
    }
});

Thread t2 = new Thread(() -> {
    synchronized (obj) {
        for (int j = 0; j < 50000; j++) {
            i--;
        }
    }
});

synchronized 关键字原理：

每个对象都存在着一个 monitor 与之关联，但当一个 monitor 被某个线程持有后，它便处于锁定状态。

monitor 中有以下属性：

_owner：指向持有 ObjectMonitor 对象的线程
_WaitSet：存放处于 wait 状态的线程队列
_EntryList：存放处于等待锁 block 状态的线程队列

Owner空闲时，线程会直接进入Owner，获得此锁

如果不空闲，则会进入 EntryList 区，等待锁的释放，锁释放后，EntryList 区的所有线程对锁进行争抢，获得锁的进入Owner区开始执行。

2.4 注意

synchronized 加锁力度可以大一些，在循环外加锁可以减少加锁解锁的代码运行次数。

上例中 t1 和 t2 线程必须用 synchronized 锁住同一个 obj 对象，如果 t1 锁住的是 m1 对象，t2 锁住的是 m2 对象，没法起到同步的效果。

3 可见性

3.1 问题：退不出的循环

static boolean run = true;

public static void main(String[] args) throws InterruptedException {
    Thread t = new Thread(()->{
        while(run){
            // ....
        }
    });
    t.start();

    Thread.sleep(1000);
    run = false; // 线程t不会如预想的停下来
}

线程内循环体为空的循环

改变静态变量为 false 循环不会停止。

3.2 原因

在最初的循环中，从主内存读取了 run 的值到工作内存

在这里插入图片描述

因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率

这里是进行了缓存的优化

在这里插入图片描述

之后主线程修改了 run 的值，并同步至主存，但 t 仍然从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值

在这里插入图片描述

3.3 解决方法 - volatile（易变关键字）

它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存

它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况；

多个写线程时候无法保证原子性

3.4注意

synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是synchronized是属于重量级操作，性能相对更低
如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，为什么？

因为 println 底层有 synchronized 同步关键字，也会强制读取主存中的值。

public void println(int x) {
    synchronized (this) {
        print(x);
        newLine();
    }
}

4 有序性

4.1 问题：退不出的循环 - 指令重排

int num = 0;
boolean ready = false;

public void actor1(I_Result r) {
    if(ready) {
        r.r1 = num + num;
    } else {
        r.r1 = 1;
    }
}


public void actor2(I_Result r) {
    num = 2;
    ready = true;
}

actor1、actor2分别由两个线程执行，在以上代码执行过程中 r.r1 的结果有以下情况：

先执行 actor1 ，此时ready为false，结果为1
先执行 actor2 ，执行结束后ready为true，再执行 actor1 结果为 2 + 2 = 4
先执行 actor2 ，至 num = 2，之后actor1 抢占时间片，ready仍未false，结果为1；
少部分情况下会出现结果为0
即先执行 actor2 的 ready = true; 再执行 actor1 此时ready为true、num为0，结果为 0 + 0 = 0，最后执行 actor2的 num = 2；
（出现次数很少）

此种现象为指令重排，是 JIT 编译器在运行时的一些优化

4.2 解决方法 - volatile（易变关键字）

同上文，加到成员变量上

4.3 分析-为什么产生指令重排-有序性理解

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序。

如下操作中 i 的赋值过程比较复杂

static int i; 
static int j;
// 在某个线程内执行如下赋值操作 
i = ...; // 较为耗时的操作 
j = ...;

这里指令执行的顺序对最终的结果不会产生影响。所以，上面代码真正执行时，

既可以是先执行 i的赋值，再执行 j 的赋值；
也可以是先执行 j 的赋值，再执行 i 的赋值

4.4 指令重排问题案例2

double-checked locking 模式实现单例（整个jvm中，类的实例对象只有一个）

public final class Singleton 
{ 
    private Singleton() { } 
    private static Singleton INSTANCE = null; 
    public static Singleton getInstance()  {
        // 实例没创建，才会进入内部的 synchronized代码块
        if(INSTANCE == null) {
            // 这里需要保证的是 ： 创建的线程是加锁的，如果已经创建了就不需要进入创建线程，因此外层的判断是必要的
            synchronized (Singleton.class) {
                if(INSTANCE == null) {
                    // 也许有其它线程已经创建实例，所以再判断一次
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

以上的实现特点是：

懒惰实例化
首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁

INSTANCE = new Singleton();字节码编译如下：

0: new #2 // class cn/itcast/jvm/t4/Singleton 
3: dup
4: invokespecial #3 // Method "<init>":()V
7: putstatic #4 // Field

其中 4和7的顺序不是固定的

（4 ：进行类的初始化；7：将对象地址赋值给静态变量）

即有可能先执行7，在执行4

先将对象地址赋值给了静态变量，此时 INSTANCE != null

当有另一个线程运行此代码，判断了INSTANCE != null，就会将 INSTANCE 对象返回

但是此时 4 的构造方法可能还未执行完毕，返回的对象可能并不完整

可以对 INSTANCE 添加 volatile 关键字，禁用指令重排。

4.5 happens-before

happens-before 规定了哪些写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，

抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见==（可以读到写的结果）==

线程对 volatile 变量的写，对接下来其它线程对该变量的读可见

结果是输出10

volatile static int x;
new Thread(()->{ 
    x = 10; 
},"t1").start();

new Thread(()->{ 
    System.out.println(x); 
},"t2").start();

线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见

static int x; 
static Object m = new Object(); 

new Thread(()->{ 
    // 加锁之后 为 X 赋值
    synchronized(m) { 
        x = 10; 
    } 
},"t1").start();

//上一个线程解锁

new Thread(()->{ 
    // 同样进行加锁，可以读到 x = 10
    synchronized(m) { 
        System.out.println(x); 
    } 
},"t2").start();

线程 start 前对变量的写，对该线程开始后对该变量的读可见

static int x; 

// 先赋值
x = 10; 
new Thread(()->{ 
    // 线程start后读取 x = 10
    System.out.println(x); 
},"t2").start();

线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）

static int x; 
// 线程内对 x 赋值
Thread t1 = new Thread(()->{ 
    x = 10; 
},"t1");
// 启动线程
t1.start();
//等待线程结束
t1.join(); 
// 可以读取 x = 10
System.out.println(x);

线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通过t2.interrupted 或 t2.isInterrupted）

注：这里的打断并不是让线程停止，而是给线程一个标记，使得 Thread.currentThread().isInterrupted() = true

static int x; 
public static void main(String[] args) { 
    Thread t2 = new Thread(()->{
        while(true) { 
            if(Thread.currentThread().isInterrupted()) { 
                // 打断之后这里为true
               	// 读取 x = 10
                System.out.println(x);
                break; 
            } 
        } 
    },"t2"); 
    
    t2.start();
    new Thread(()->{ 
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace(); 
        }
        // x 赋值为 10
        x = 10;
        // 打断 t2
        t2.interrupt(); 
    },"t1").start(); 
    
    while(!t2.isInterrupted()) { 
        Thread.yield(); 
    }
    
    System.out.println(x);
}

对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z （hb是happens-before）

5. CAS 与原子类

5.1 CAS

CAS 即 Compare and Swap ，它体现的一种乐观锁的思想

无锁并发

比如多个线程要对一个共享的整型变量执行 +1 操作：

// 需要不断尝试 
while(true) { 
    int 旧值 = 共享变量 ; // 比如拿到了当前值 0 
    int 结果 = 旧值 + 1; // 在旧值 0 的基础上增加 1 ，正确结果是 1 
    
    /*这时候如果别的线程把共享变量改成了 5，本线程的正确结果 1 就作废了，
    这时候 compareAndSwap 返回 false，重新尝试，直到：
    compareAndSwap 返回 true，表示我本线程做修改的同时，别的线程没有干扰 */
    
    if( compareAndSwap ( 旧值, 结果 )) { 
        // 成功，退出循环 
        break;
    } 
}

在外层加入 true 的循环判断，保证可以再修改成功前一直尝试。

在 compareAndSwap 中，传入的旧值会和共享变量作比较，如果相等说明没有其他线程进行修改，那么就继续执行赋值操作，并返回true，使外层循环可以跳出。

获取共享变量时，为了保证该变量的可见性，需要使用 volatile 修饰。结合 CAS 和 volatile 可以实现无锁并发，适用于竞争不激烈、多核 CPU的场景下。（volatile 保证是从工作内存中读取而不是从本地缓存中读取）

因为没有使用 synchronized，所以线程不会陷入阻塞，这是效率提升的因素之一。因此需要多核CPU保证可以利用CPU时间，不然其他线程在修改时候暂用了唯一的CPU时间，本线程也无法进行重试
但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响

5.2 CAS底层实现

底层依赖于一个 Unsafe 类来直接调用操作系统底层的 CAS 指令

5.3 乐观锁和悲观

CAS 是基于乐观锁的思想：最乐观的估计，（其他线程大概率不会改，所以主要正常执行，如果被改了再进行补救操作），不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗。
synchronized 是基于悲观锁的思想：最悲观的估计，（其他线程一定会改，所以要先加锁），得防着其它线程来修改共享变量，我上了锁你们都别想改，我改完了解开锁，你们才有机会。

5.4 原子操作类

JUC（java.util.concurrent）中提供了原子操作类，可以提供线程安全的操作，例如：AtomicInteger（原子整数类，保证int操作的线程安全）、AtomicBoolean等，它们底层就是采用 CAS 技术 + volatile 来实现的。

如上文原子性中的例子，可以用 AtomicInteger 类进行自增自减操作，使用无锁并发的方法：

// 创建原子整数对象
private static AtomicInteger i = new AtomicInteger(0);

public static void main(String[] args) throws InterruptedException {
    Thread t1 = new Thread(() -> {
        for (int j = 0; j < 5000; j++) {
            i.getAndIncrement();  // 获取并且自增  i++
            // i.incrementAndGet();  // 自增并且获取  ++i
        }
    });

    Thread t2 = new Thread(() -> {
        for (int j = 0; j < 5000; j++) {
            i.getAndDecrement(); // 获取并且自减  i--
        }
    });

    t1.start();
    t2.start();
    t1.join();
    t2.join();
    System.out.println(i);
}

这里的结果是0，不会产生线程冲突

6. synchronized 优化

6.1 对象头：

Java HotSpot 虚拟机中，每个对象都有对象头（包括 class 指针和 Mark Word）。Mark Word 平时存储这个对象的哈希码、分代年龄

当加锁时，这些信息就根据情况被替换为标记位、线程锁记录指针、重量级锁指针、线程ID 等内容

6.2 轻量级锁

如果一个对象虽然有多线程访问，但多线程访问的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。

即在进行加锁操作时候，如果没有其他线程已经对此对象加锁，那么可以先加轻量级锁。

尝试加锁时候：

如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在线程1的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝。
虚拟机将使用CAS操作尝试把对象的Mark Word更新为线程1 的锁记录地址。（这里的判断条件就是锁标记是否仍为01）
如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位将转变为“00”，表示此对象处于轻量级锁定状态。
如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了；否则就说明这个锁对象已经被其他线程抢占了，那轻量级锁就不再有效，必须要膨胀为重量级锁。
解锁过程也同样是通过CAS操作来进行的，如果对象的 Mark Word仍然指向线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中记录的Mark Word替换回来，锁标记改为01。

在整个加锁过程中，对象头的Mark Word都会被设置为00（代表轻量级锁）

6.3 锁膨胀

如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

尝试加锁时候：

同轻量级锁的1和2步骤
更新操作失败，发现锁对象已经被线程1 抢占，轻量级锁需要膨胀为重量级锁。
锁标记更新为 10 （代表重量级锁），并将对象的 Mark Word 更新为重量级锁指针（为了解锁时可以根据指针唤醒阻塞中的线程）
线程2 阻塞等待
线程1 等待，CAS操作解锁：解锁轻量级锁失败，线程1 通过重量级锁的方法，释放重量级锁，还原 Mark Word信息后，唤起阻塞线程
线程2 被唤醒，竞争重量级锁

这里重量级锁的 markword会更新为重量级锁的指针，那么如何还原轻量级锁保存的原始mark word

6.4 重量级锁 - 自旋

传统的使用 synchronized 加锁操作都是重量级锁。

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

自旋过程：

当线程2 尝试获取锁，但发现已经被线程1 加锁时，线程2会重复获取锁的操作，而不是直接进行阻塞（阻塞-唤醒的操作比较消耗资源），但这个尝试自旋获取锁的过程不会持续进行，到一定次数仍未得到锁，还会进行阻塞。
进行自旋会消耗CPU时间片，因为相当于线程2仍在运行。

在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋。

自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
Java 7 之后不能控制是否开启自旋功能，JVM内部进行自旋控制

6.5 偏向锁（感觉没有讲清楚，可以看一下JUC）

如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不去做了。

轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID是自己的就表示没有竞争，不用重新 CAS.

缺点：

撤销偏向需要将持锁线程升级为轻量级锁，这个过程中所有线程需要暂停（STW）
访问对象的 hashCode 也会撤销偏向锁（对象头无所状态下存储了 hashcode，加偏向锁后，hashcode存到了线程中，访问hashcode需要撤销偏向锁，将hashcode取回对象头）这里轻量级锁是不是也取不到，撤销轻量锁不需要stw？
如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID。（这里不是没有竞争吗？）
撤销偏向和重偏向都是批量进行的，以类为单位
如果撤销偏向到达某个阈值，整个类的所有对象都会变为不可偏向的
可以主动使用 -XX:-UseBiasedLocking 禁用偏向锁

6.6 其他优化

6.6.1. 减少上锁时间

同步代码块中尽量短

上锁时间短竞争机会少，如果时间长，可能会让轻量级锁升级为重量级锁，因为多了竞争。

6.6.2. 减少锁的粒度

将一个锁拆分为多个锁提高并发度，例如：

ConcurrentHashMap（ConcurrentHashMap和HashMap原理基本类似，只是在HashMap的基础上需要支持并发操作，保证多线程情况下对HashMap操作的安全性。当某个线程对集合内的元素进行数据操作时，会锁定这个元素，如果其他线程操作的数据hash得到相同的位置，就必须等到这个线程释放锁之后才能进行操作。）
LongAdder （计数累加的原子操作类）分为 base 和 cells 两部分。没有并发争用的时候或者是 cells 数组正在初始化的时候，会使用 CAS 来累加值到 base，有并发争用，会初始化 cells 数组，数组有多少个 cell，就允许有多少线程并行修改，最后将数组中每个 cell 累加，再加上 base 就是最终的值
LinkedBlockingQueue （基于链表的阻塞队列）入队和出队使用不同的锁，相对于 LinkedBlockingArray 只有一个锁效率要高

6.6.3. 锁粗化

多次循环进入同步块不如同步块内多次循环

另外 JVM 可能会做如下优化，把多次 append 的加锁操作粗化为一次（因为都是对同一个对象加锁，没必要重入多次）

new StringBuffer().append("a").append("b").append("c");

stringBuffer内部实现了synchronized

6.6.4. 锁消除

JVM 会进行代码的逃逸分析，例如某个加锁对象是方法内局部变量，不会被其它线程所访问到，这时候就会被即时编译器忽略掉所有同步操作。

如stringBuffer 没有传出方法，会忽略掉synchronized 关键字。

6.6.5. 读写分离

读操作不需要同步，写操作需要同步

CopyOnWriteArrayList

ConyOnWriteSet

Zkkkai

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【JVM】学习笔记6 ——内存模型：Java并发操作的锁机制

本篇笔记为Java内存模型篇，主要为Java多线程并发操作时多数据安全的保障操作和优化。JMM 定义了一套在多线程读写共享数据时（成员变量、数组）时，对数据的可见性、有序性、和原子性的规则和保障
复制链接

扫一扫