Java并发编程第五章共享模型之内存

wm1043

于 2024-09-07 11:31:31 发布

阅读量1.1k

点赞数 36

文章标签： java 开发语言

本文链接：https://blog.csdn.net/m0_56369671/article/details/141968168

版权

1. 可见性

引子

@Slf4j(topic = "c.Test32")
public class Test32 {
    // 易变
    static boolean run = true;

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

        sleep(1);
        log.debug("过了1s应该停止");
        run = false; // 线程t不会如预想的停下来
    }
}

1s后程序并为停止

这是因为1.初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。

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

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

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

        前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见，不能保证原子性，仅用在一个写线程，多个读线程的情况：上例从字节码理解是这样的：
        getstatic run // 线程 t 获取 run true
        getstatic run // 线程 t 获取 run true
        getstatic run // 线程 t 获取 run true
        getstatic run // 线程 t 获取 run true
        putstatic run // 线程 main 修改 run 为 false，仅此一次
        getstatic run // 线程 t 获取 run false
        比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错。

设计模式之犹豫模式

在之前两阶段模式的基础上修改


@Slf4j(topic = "c.liangjieduangaijin")
public class liangjieduangaijin {
    public static void main(String[] args) throws InterruptedException {
        TPTVolatile t = new TPTVolatile();
        t.start();
        Thread.sleep(3500);
        log.debug("stop");
        t.stop();
    }
}

// 停止标记用 volatile 是为了保证该变量在多个线程之间的可见性
// 我们的例子中，即主线程把它修改为 true 对 t1 线程可见
@Slf4j(topic = "c.TPTVolatile")
class TPTVolatile {
    private Thread thread;
    private volatile boolean stop = false;

    public void start() {
        thread = new Thread(() -> {
            while (true) {
                Thread current = Thread.currentThread();
                if (stop) {
                    log.debug("料理后事");
                    break;
                }
                try {
                    Thread.sleep(1000);
                    log.debug("将结果保存");
                } catch (InterruptedException e) {
                }
                // 执行监控操作
            }
        }, "监控线程");
        thread.start();
    }

    public void stop() {
        stop = true;
        thread.interrupt();
    }
}

执行前先判断是否为stop，像思考一下所以叫犹豫模式。

if (stop) {
log.debug("料理后事");
break;
}

前面的犹豫模式还有个问题，监控线程只开启一次就可以了，但主线程多次调用的话会创建多个线程，尝试修改

private volatile boolean starting=false;

    //启动监控线程
    public void start() {
        if (starting){
            return;
        }
        starting=true;

加了这么几行代码。看似可以，但多并发下还是拦不住，应该再加synchronized。

  private volatile boolean starting = false;

    // 启动监控线程
    public void start() {
        synchronized (this) {
            if (starting) {
                return;
            }
            starting = true;
        }
        thread = new Thread(() -> {
            while (true) {
                Thread current = Thread.currentThread();
                if (stop) {
                    log.debug("料理后事");
                    break;
                }
                try {
                    Thread.sleep(1000);
                    log.debug("将结果保存");
                } catch (InterruptedException e) {
                }
                // 执行监控操作
            }
        }, "监控线程");
        thread.start();
    }

开了三个线程就一个监控线程执行了。

2. 有序性

        JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码
        static int i;
        static int j;
        // 在某个线程内执行如下赋值操作
        i = ...;
        j = ...;
        可以看到，至于是先执行 i 还是先执行 j ，对最终的结果不会产生影响。
        这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？这要从 CPU执行指令的原理来说起。

串行太慢，改为流水线后

一个例子

class test {
    int num = 0;
    boolean ready = false;

    // 线程1 执行此方法
    public void actor1(I_Result r) {
        if (ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }

    // 线程2 执行此方法
    public void actor2(I_Result r) {
        num = 2;
        ready = true;
    }
}

结果为4或者1，但也有很小的概率为0.这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现：

可见0的出现次数虽然很少但也出现了。加上volatile就可以禁用重排序。

3. volatile原理

        volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）
        对 volatile 变量的写指令后会加入写屏障
        对 volatile 变量的读指令前会加入读屏障

1. 如何保证可见性

写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中

public void actor2(I_Result r) {
    num = 2;
    ready = true; // ready 是 volatile 赋值带写屏障
    // 写屏障
}

而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

public void actor1(I_Result r) {
        // 读屏障
        // ready 是 volatile 读取值带读屏障
        if (ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }

示意图

2. 保证不会指令重排

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
但这并不能不能解决指令交错：
写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
而有序性的保证也只是保证了本线程内相关代码不被重排序

3. double-checked locking 问题

单例模式有饿汉式单例类和饿汉式单例类。饿汉式创建时就加载单例对象性能较差，而饿汉式有会有线程安全问题可以使用关键字synchronized，代码如下

public class LazySingleton {
    private static LazySingleton instance = null;

    // 私有构造函数，防止外部实例化
    private LazySingleton() {}

    // 提供公共的静态方法获取实例，使用同步确保线程安全
    public static synchronized LazySingleton getInstance() {
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}

该懒汉式单例类在getInstance（）方法前面增加了关键字synchronized进行线程锁定，以处理多个线程同时访问的问题。上述代码虽然解决了线程安全问题，但是每次调用getInstance（）时都需要进行线程锁定判断，在多线程高并发访问环境中，将会导致系统性能大大降低。如何既解决线程安全问题又不影响系统性能呢？继续对懒汉式单例进行改进。事实上，无须对整个getInstance（）方法进行锁定，只需锁定代码“instance＝new LazySingleton（）；”即可。因此，getInstance（）方法可以进行如下改进：

public static LazySingleton getInstance() {
    if (instance == null) {
        synchronized (LazySingleton.class) {
            if (instance == null) {
                instance = new LazySingleton();
            }
        }
    }
    return instance;
}

问题貌似得以解决，事实并非如此。如果使用以上代码来创建单例对象，还是会存在单例对象不唯一。原因如下：

假如某一瞬间线程A和线程B都在调用getInstance（）方法，此时instance对象为null值，均能通过“instance＝＝null”的判断。由于实现了synchronized加锁机制，线程A进入synchronized锁定的代码中执行实例创建代码，线程B处于排队等待状态，必须等待线程A执行完毕后才可以进入synchronized锁定代码。但当A执行完毕时，线程B并不知道实例已经创建，将继续创建新的实例，导致产生多个单例对象，违背单例模式的设计思想。因此需要进行进一步改进，在synchronized锁定代码中再进行一次“instance＝＝null”判断，这种方式称为双重检查锁定（Double-Check Locking）。使用双重检查锁定实现的懒汉式单例类代码如下：

public class LazySingleton {
    private static LazySingleton instance = null;

    // 私有构造函数，防止外部实例化
    private LazySingleton() {}

    // 提供公共的静态方法获取实例
    public static LazySingleton getInstance() {
        // 第一重判断：检查实例是否为 null
        if (instance == null) {
            synchronized (LazySingleton.class) {
                // 锁定代码块，确保只有一个线程可以创建实例
                // 第二重判断：在锁定后再次检查实例是否为 null
                if (instance == null) {
                    instance = new LazySingleton(); // 创建单例实例
                }
            }
        }
        return instance;
    }
}

这次看着应该是很完备了，且慢还有问题，getinstance的字节码为

0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
27: aload_0
28: monitorexit
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn

其中
17 表示创建对象，将对象引用入栈 // new Singleton
20 表示复制一份对象引用 // 引用地址
21 表示利用一个对象引用，调用构造方法
24 表示利用一个对象引用，赋值给 static INSTANCE
也许 jvm 会优化为：先执行 24，再执行 21。如果两个线程 t1，t2 按如下时间序列执行：

关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取INSTANCE 变量的值，这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例。
解决方法很简单，对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效。完整代码如下：

public class LazySingleton {
    private volatile static LazySingleton instance = null;

    // 私有构造函数，防止外部实例化
    private LazySingleton() {}

    // 提供公共的静态方法获取实例
    public static LazySingleton getInstance() {
        // 第一重判断：检查实例是否为 null
        if (instance == null) {
            synchronized (LazySingleton.class) {
                // 锁定代码块，确保只有一个线程可以创建实例
                // 第二重判断：在锁定后再次检查实例是否为 null
                if (instance == null) {
                    instance = new LazySingleton(); // 创建单例实例
                }
            }
        }
        return instance;
    }
}

        读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面
两点：
        1.可见性
                写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
                而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据
2. 有序性
                写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
                读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
更底层是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性。

总结

本章重点讲解了 JMM 中的
        可见性 - 由 JVM 缓存优化引起
        有序性 - 由 JVM 指令重排序优化引起
        happens-before 规则
        原理方面
                CPU 指令并行
                volatile
        模式方面
                两阶段终止模式的 volatile 改进
                同步模式之 balking