共享模型之内存

最新推荐文章于 2024-11-11 21:19:25 发布
最新推荐文章于 2024-11-11 21:19:25 发布
阅读量140 收藏
点赞数 1
分类专栏： java多线程 文章标签： java jvm 面试
版权声明：本文为博主原创文章，遵循 CC 4.0 BY 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_46188681/article/details/127539644
版权

共享模型之内存

4.共享模型之内存

4.1 Java 内存模型

JMM 即 Java Memory Model，它定义了主存、工作内存抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。
JMM 体现在以下几个方面

  • 原子性 - 保证指令不会受到线程上下文切换的影响
  • 可见性 - 保证指令不会受 cpu 缓存的影响
  • 有序性 - 保证指令不会受 cpu 指令并行优化的影响

4.2 可见性

退不出的循环 先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：

 // 本意：让程序在睡眠1秒后，main线程将run设置为false，让while循环停止下来
    static boolean run = true;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(run){
                
            }
        });
        t.start();
        Util.sleep(1);
        run = false; // 线程t不会如预想的停下来
    }

为什么呢？分析一下：

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

image-20211122011017967

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

image-20211122011054527

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

image-20211122011125811

解决方法1: volatile（易变关键字）

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

 volatile static boolean run = true;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(run){

            }
        });
        t.start();
        Util.sleep(1);
        run = false; 
    }

解决方案2：synchronized 可以保证原子性，还能保证可见性

synchronized在修改了本地内存中的变量后，解锁前会将本地内存修改的内容刷新到主内存中，确保了共享变量的值是最新的，也就保证了可见性。

    volatile static boolean run = true;
    static Object lock = new Object();
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(true){
                synchronized (lock){
                    if (!run){
                        break;
                    }
                }
            }
        });
        t.start();
        Util.sleep(1);
        synchronized (lock){
            run = false;
        }

可见性 vs 原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 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-- ，只能保证看到最新值，不能解决指令交错

// 假设i的初始值为0 
getstatic i // 线程2-获取静态变量i的值 线程内i=0 
getstatic i // 线程1-获取静态变量i的值 线程内i=0 
iconst_1 // 线程1-准备常量1 
iadd // 线程1-自增 线程内i=1 
putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1 
iconst_1 // 线程2-准备常量1 
isub // 线程2-自减 线程内i=-1 
putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

注意 synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是 synchronized 是属于重量级操作，性能相对更低

如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到 对 run 变量的修改了，想一想为什么？

因为 System.out.println()中的println()方法由synchronized 关键字修饰

4.3 同步模式-Balking

alking （犹豫）模式用在一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做 了，直接结束返回

@Slf4j
public class MyTest {
    public static void main(String[] args) throws InterruptedException {
        TwoPhaseTermination termination = new TwoPhaseTermination();
        // 启动监视器 3s后关闭
        termination.start();
        termination.start();

        Thread.sleep(4000);
        log.debug("停止监控...");
        termination.stop();


    }
}
@Slf4j
class TwoPhaseTermination{
    // 监视器
    private Thread monitor;
    private volatile boolean stop = false;
    // 用来标识是否已经有线程已经在执行启动了
    private volatile boolean starting=false;

    public void start(){
        // 进行判断避免 重复start()
        synchronized (this){
            if (starting){
                log.debug("获取锁失败");
                return;
            }
            starting = true;
        }

        monitor=new Thread(()->{
            while (true){

                // 根据停止标记来停止监控
                if (stop){
                    log.debug("释放资源...");
                    break;
                }

                try {
                  Thread.sleep(500);
                    log.debug("执行监控任务...");
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        },"monitor");
        monitor.start();
    }

    public void stop(){
        stop=true;
        monitor.interrupt();

    }
}

它还经常用来实现线程安全的单例

public final class Singleton {
    private Singleton() {
    }
    private static Singleton INSTANCE = null;
    public static synchronized Singleton getInstance() {
        if (INSTANCE != null) {
            return INSTANCE;
        }

        INSTANCE = new Singleton();
        return INSTANCE;
    }
}

4.4有序性

JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码

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

可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是

i = ...; 
j = ...;

也可以是

j = ...;
i = ...;

这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU 执行指令的原理来理解一下吧

4.5指令级并行原理

指令重排序优化: 事实上，现代处理器会设计为一个时钟周期完成一条执行时间最长的 CPU 指令。为什么这么做呢？可以想到指令 还可以再划分成一个个更小的阶段，例如，每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据 写回 这 5 个阶段

image-20211122162407269

在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行，这一技术在 80年代中叶到 90年代中叶占据了计算架构的重要地位。

提示： 分阶段，分工是提升效率的关键！

指令重排的前提是，重排指令不能影响结果，例如

// 可以重排的例子
int a = 10; // 指令1
int b = 20; // 指令2
System.out.println( a + b );
// 不能重排的例子
int a = 10; // 指令1
int b = a - 5; // 指令2

支持流水线的处理器 现代 CPU 支持多级指令流水线，例如支持同时执行 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 的处理 器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一 条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了 指令地吞吐率。

提示： 奔腾四（Pentium 4）支持高达 35 级流水线，但由于功耗太高被废弃

image-20211122162631644

4.6诡异的结果

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; 
}

I_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？

情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1

情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1

情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）

情况4：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现：

创建 maven 项目，提供如下测试类

mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress -
DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=cn.itcast -
DartifactId=ordering -Dversion=1.0 

import org.openjdk.jcstress.annotations.*;

import org.openjdk.jcstress.infra.results.I_Result;

@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State
public class ConcurrencyTest {
    int num = 0;
    boolean ready = false;
    @Actor
    public void actor1(I_Result r) {
        if(ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }
    @Actor
    public void actor2(I_Result r) {
        num = 2;
        ready = true;
    }
}

执行

mvn clean install 
java -jar jcstress.jar

挑选一些我们感兴趣的结果

*** INTERESTING tests 
 Some interesting behaviors observed. This is for the plain curiosity. 
 2 matching test results. 
 [OK] test.ConcurrencyTest 
 (JVM args: [-XX:-TieredCompilation]) 
 Observed state Occurrences Expectation Interpretation 
 0 1,729 ACCEPTABLE_INTERESTING !!!! 
 1 42,617,915 ACCEPTABLE ok 
 4 5,146,627 ACCEPTABLE ok 
 [OK] test.ConcurrencyTest 
 (JVM args: []) 
 Observed state Occurrences Expectation Interpretation 
 0 1,652 ACCEPTABLE_INTERESTING !!!! 
 1 46,460,657 ACCEPTABLE ok 
 4 4,571,072 ACCEPTABLE ok

可以看到，出现结果为 0 的情况有 638 次，虽然次数相对很少，但毕竟是出现了。

解决方法 : volatile 修饰的变量，可以禁用指令重排


import org.openjdk.jcstress.annotations.*;

import org.openjdk.jcstress.infra.results.I_Result;

@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
@State
public class ConcurrencyTest {
    int num = 0;
   volatile boolean ready = false;
    @Actor
    public void actor1(I_Result r) {
        if(ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }
    @Actor
    public void actor2(I_Result r) {
        num = 2;
        // volatile修饰的变量之前的指令不会被重排序了
        ready = true;
    }
}

*** ERROR tests
  Tests break for some reason, other than failing the assert. Correct implementations should have none.

  0 matching test results.

4.7 volatile 原理

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

  • 对 volatile 变量的读指令前会加入读屏障
  • 对 volatile 变量的写指令后会加入写屏障

4.71.如何保证可见性

  • 写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
public void actor2(I_Result r) {
 num = 2;
 ready = true; // ready 是 volatile 赋值带写屏障
 // 写屏障  把vloatile之前的修改都同步到主存中
}
  • 读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据
  public void actor1(I_Result r) {
        // 读屏障
        // ready 是 volatile 读取值带读屏障
        if(ready) {
            r.r1 = num + num;
        } else {
            r.r1 = 1;
        }
    }

image-20211122172959223

4.7.2.如何保证有序性

写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

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

读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

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

image-20211122173709853

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LJXOGFWr-1666785851126)(C:\Users\14823\Desktop\learn-note\typroa-img\image-20211122173944100.png)]

4.7.3 double-checked locking

以著名的 double-checked locking 单例模式为例

public class Singleton {
    private Singleton() { }
    private static Singleton INSTANCE = null;
    public synchronized static  Singleton getInstance() {
        if(INSTANCE == null) { 
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

以上的实现特点是：

  • 懒惰实例化
  • 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
  • 有隐含的，但很关键的一点：第一个 if 使用了 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: aretur
    // synchronized 可以保证：可见性，原子性，有序性[前提是改变量完全交给synchronized保护]
    // 只有在 monitorenter 和 monitorexit 之间的代码才会保证有序性

其中

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

image-20211122181133479

  • 关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取
    INSTANCE 变量的值

  • 这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初
    始化完毕的单例

  • 对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才会真正有效

public class Singleton {
    private Singleton() { }
    // 加上 volatile 关键字避免指令重排序
    private static volatile Singleton INSTANCE = null;
    public synchronized static  Singleton getInstance() {
        if(INSTANCE == null) { // t2
            // 首次访问会同步，而之后的使用没有 synchronized
            synchronized(Singleton.class) {
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

字节码上看不出来 volatile 指令的效果

// -------------------------------------> 加入对 INSTANCE 变量的读屏障
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;
// -------------------------------------> 加入对 INSTANCE 变量的写屏障
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

如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：

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

image-20211122181729340

4.7.4 happens-before

happens-before 规定了对共享变量的写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结，抛 开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见

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

static int x;
    static Object m = new Object();
    public static void main(String[] args) {

        new Thread(()->{
            synchronized(m) {
                x = 10;
            }
        },"t1").start();
        new Thread(()->{
            synchronized(m) {
                System.out.println(x);
            }
        },"t2").start();

            }

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

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

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

      static int x;
        Thread t1 = new Thread(()->{
            x = 10;
        },"t1");
        t1.start();
        t1.join();
        System.out.println(x);

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

static int x;
        public static void main(String[] args) {
            Thread t2 = new Thread(()->{
                while(true) {
                    if(Thread.currentThread().isInterrupted()) {
                        System.out.println(x);
                        break;
                    }
                }
            },"t2");
            t2.start();
            new Thread(()->{
                sleep(1);
                x = 10;
                t2.interrupt();
            },"t1").start();
            while(!t2.isInterrupted()) {
                Thread.yield();
            }
            System.out.println(x);
        }

5.对变量默认值（0，false，null）的写，对其它线程对该变量的读可见

6.具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z ，配合 volatile 的防指令重排，有下面的例子

volatile static int x;
static int y;
new Thread(()->{ 
	 y = 10;
 	x = 20;
},"t1").start();
new Thread(()->{
	 // x=20 对 t2 可见, 同时 y=10 也对 t2 可见
	 System.out.println(x); 
},"t2").start();

4.7.5 习题

4.7.5.1 balking 模式习题

希望 doInit() 方法仅被调用一次，下面的实现是否有问题，为什么？

volatile仅仅只能保证可见性和有序性，并不能保证原子性，有可能会出现A线程正调用了doInit()方法，此时还没有完成赋值操作，而B线程进到if判断为真，继续调用doInit()方法。 使用synchronized加锁保证原子性，或用其他的加锁方式

    public class TestVolatile {
        volatile boolean initialized = false;
        void init() {
            if (initialized) {
                return;
            }
            doInit();
            initialized = true;
        }
        private void doInit() {
        }
    }
4.7.5.2 线程安全单例习题

单例模式有很多实现方法，饿汉、懒汉、静态内部类、枚举类，试分析每种实现下获取单例对象（即调用 getInstance）时的线程安全，并思考注释中的问题

  • 饿汉式：类加载就会导致该单实例对象被创建
  • 懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建

实现1：

// 问题1：为什么加 final 答：避免子类去继承，改变父类getInstance方法的逻辑，导致不是单例的
// 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例
    public final class Singleton implements Serializable {
// 问题3：为什么设置为私有? 是否能防止反射创建新的实例? 答：不可以的，反射可以暴力破解，但是我们可以在构造方法中增加逻辑进行解决，比如判断 INSTANCE！=null 就抛出异常
        private Singleton() {}
        // 问题4：这样初始化是否能保证单例对象创建时的线程安全? 答：是可以的，jvm在执行类加载时是线程安全的
        private static final Singleton INSTANCE = new Singleton();
        // 问题5：为什么提供静态方法而不是直接将 INSTANCE 设置为 public, 说出你知道的理由
        //答：提供更好的封装性，可以提供懒惰的初始化；可以提供泛型的支持；对创建单例变量有更好的控制。
        public static Singleton getInstance() {
            return INSTANCE;
        }
        public Object readResolve() {
            return INSTANCE;
        }
    }

    // 解决序列化与反序列化破坏单例模式的问题，如果在反序列化时，发现有readResolve方法，直接调用该方法进行返回
    private Object readResolve() {
        return this.INSTANCE;
    }

实现2：

// 问题1：枚举单例是如何限制实例个数的
// 答：由枚举控制，是单实例的。
    
// 问题2：枚举单例在创建时是否有并发问题
// 答：没有。因为它也是静态成员变量。

// 问题3：枚举单例能否被反射破坏单例
// 答：不能用反射破坏。拿不到构造方法，不能实现反射。

// 问题4：枚举单例能否被反序列化破坏单例
// 答：枚举在实现的时候就继承了序列化的接口，不能被破坏。 枚举类接口中的readObject 默认防止反序列化

// 问题5：枚举单例属于懒汉式还是饿汉式
// 答：饿汉式的 ，只有类加载时才会被实例化

// 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做
// 答：在枚举类中写一个构造方法
enum Singleton { 
 INSTANCE; 
}

实现3：

   public final class Singleton {
        private Singleton() { }
        private static Singleton INSTANCE = null;
        // 分析这里的线程安全, 并说明有什么缺点
       
// 答：我们只需要第一次调用 getInstance() 时线程进入同步等待，而后面的都不需要了，此处的缺点就是锁的粒度太大，导致即使已经有线程创建好了实例，可别的线程下次来依旧需要停下来获取同步锁
        public static synchronized Singleton getInstance() {
            if( INSTANCE != null ){
                return INSTANCE;
            }
            INSTANCE = new Singleton();
            return INSTANCE;
        }
    }

实现4：

 public final class Singleton {
        private Singleton() { }
        // 问题1：解释为什么要加 volatile ?
    	// 答：保证可见性和有序性，防止指令重排，避免有的线程拿到未初始化完整的实例
        private static volatile Singleton INSTANCE = null;

        // 问题2：对比实现3, 说出这样做的意义 
        // 答：只需要在第一次实例化时进行同步等待，往后的调用无需同步等待，因为对象已经被实例化，直接返回，大大提高效率
        public static Singleton getInstance() {
            if (INSTANCE != null) {
                return INSTANCE;
            }
            synchronized (Singleton.class) {
                // 问题3：为什么还要在这里加为空判断, 之前不是判断过了吗？
                
                // 答：保证实例的唯一性，有可能A线程进入同步块但是还未来得及赋值，B线程执行完if然后等待同步锁，等A线程执行				完，B线程拿到同步锁，继续执行new Singleton()操作，导致单例不唯一
                if (INSTANCE != null) {
                    return INSTANCE;
                }
                INSTANCE = new Singleton();
                return INSTANCE;
            }
        }
    }

实现5：

  public final class Singleton {
        private Singleton() { }
        // 问题1：属于懒汉式还是饿汉式
        // 答：懒汉式，只有调用getInstance才会导致LazyHolder发送类加载
        private static class LazyHolder {
            static final Singleton INSTANCE = new Singleton();
        }
        // 问题2：在创建时是否有并发问题
        public static Singleton getInstance() {
            return LazyHolder.INSTANCE;
        }
    }

4.8 本章小结

本章重点讲解了 JMM 中的

  • 可见性 - 由 JVM 缓存优化引起
  • 有序性 - 由 JVM 指令重排序优化引起
  • happens-before 规则
  • 原理方面
  • CPU 指令并行
    • volatile
  • 模式方面
    • 两阶段终止模式的 volatile 改进
    • 同步模式之 balking
野生java研究僧
关注
专栏目录
JUC学习之共享模型之内存
m0_53157173的博客
12-25 497
JUC学习之共享模型之内存Java 内存模型可见性退不出的循环解决方法两阶段终止模式interrupt实现volatile实现同步模式之 Balking定义实现指令重排有序性指令级并行原理名词Clock Cycle TimeCPIIPC鱼罐头的故事指令重排序优化支持流水线的处理器SuperScalar 处理器CPU 缓存结构原理1. CPU 缓存结构2.CPU 缓存读3. CPU 缓存一致性诡异的结果解决方法volatile 原理内存屏障1. 如何保证可见性2.如何保证有序性volatile 不能解决指令交
《Java 并发编程》共享模型之内存
华仔仔的博客
04-14 965
Java 内存模型1. Java 内存模型1.1 原子性1.2 可见性1.3 有序性 1. Java 内存模型 Java 内存模型（Java Memory Model，JMM）是 JVM 规范中定义的一种抽象模型，用来屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。 JMM 体现在以下几个方面： 原子性：保证指令不受到线程上下文的影响。 可见性：保证指令不会受 CPU 缓存的影响。 有序性：保证指令不会受 CPU 指令并行优化的影响。 1.1 原子性
并发编程：（四）共享模型之内存
余笙的博客
07-23 352
一、Java内存模型 1、前言 Monitor 主要关注的是访问共享变量时，保证临界区代码的原子性。 2、定义 JMM 即 Java Memory Model，它定义了主存（所有线程共享的数据存放位置）、工作内存（每个线程私有的数据存放位置）抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。 JMM 体现在以下几个方面： 原子性 - 保证指令不会受到线程上下文切换的影响 可见性 - 保证指令不会受 CPU 缓存的影响 有序性 - 保证指令不会受 CPU 指令并行优化的影响 3、可
深入理解共享模型之内存
pleasenoerror的博客
07-09 90
深入理解共享模型之内存
JVM之内存模型
qq_45901741的博客
02-07 1301
对于JVM的内存模型，面试中通常会直接问你对它的认识和了解多少，所以我们的回到应该由浅入深，逐层刨析。 一. Java 虚拟机内存模型 首先，我们得知道，JVM内存空间分为五部分，分别是：方法区、堆、Java虚拟机栈、本地方法栈、程序计数器。 这些数据区域可以分为两个部分：一部分是线程共享的，一部分则是线程私有的。其中，线程共享的数据区包括方法区和堆，线程私有的数据区包括虚拟机栈、本地方法栈和程序计数器。如下图所示： 接下来我们挨个再说。 1.1、线程共享数据区域 1.1.1、方法区 方法区用于存储已被虚
JVM 内存模型
qq_3579905531的博客
04-17 5012
目录 1.JVM 内存模型是什么？ ​1.1 什么是内存模型? 2. JVM 概述 3.JVM 体系结构 4.内存管理 5.碎片回收 6. 图解JVM 6.1 说明：😁😁😁😁😁 7. 将JVM抽象表示： 7.1 说明： 1.JVM 内存模型是什么？ JVM是【Java Virtual Machine（Java虚拟机）】的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。 引入Java语言虚拟机后，...
《JUC并发编程 - 高级篇》04 -共享模型之内存 （Java内存模型 | 可见性 | 有序性 ）
LXYDSF的博客
07-15 1170
《JUC并发编程 - 高级篇》04 -共享模型之内存 （Java内存模型 | 可见性 | 有序性 ）
共享内存编程模型.ppt
05-03
共享内存编程模型.ppt
Java 内存模型
07-23
总之，Java内存模型是Java编程中的一个基础性话题，它定义了Java程序在多线程环境下关于数据共享、线程通信和同步的规则和约束。深入掌握Java内存模型对于编写高效且正确的Java多线程程序有着不可忽视的作用。程序员...
Linux进程间通信之共享内存
07-26
虽然共享内存有很多优点，但它也存在一些不足之处： 1. **同步问题**：需要程序员自己实现对共享内存访问的同步机制，比如使用互斥锁、信号量等，避免数据竞争和不一致的问题。 ### 共享内存编程模型 实现共享...
共享与分布内存并行计算.pdf
08-06
共享内存并行计算和分布式内存并行计算是两种主要的并行计算模型。在共享内存系统中，所有的执行单元，比如线程，可以访问同一块物理内存，这简化了数据共享，但可能导致竞争条件和同步问题。而分布式内存系统中，每...
论文研究 - 基于共享内存总线的多处理器的定时Petri网模型
05-25
由于多处理器的性能取决于许多以不同方式影响性能的参数，因此在指令执行级使用定时Petri网对基于共享内存总线的多处理器进行建模，并使用已开发的模型来研究处理器随系统中处理器数量的变化而变化。 结果很好地...
日常bug记录，easyexcel导入报错convert data ... to class java.math.BigDecimal error
mm
11-11 188
排查发现实体类中有BigDecimal属性，然而数据中这个属性为null，进行转换时报错。在实体类上加上自定义转换器。解决方法：自定义转换器类。
SpringBoot 实现图片加水印
最新发布
心猿意码
11-11 293
通过上述步骤，我们可以在SpringBoot项目中实现一个简单的图片加水印功能。当然，实际应用中可能需要更复杂的水印处理，比如水印图片、调整水印位置等，可以根据需求进行相应的扩展和优化。
刷题---顺序表算法题
weixin_63997543的博客
11-11 285
顺序算法题----力扣刷题
JAVA-01-变量
LJH_laura_li的博客
11-08 472
在方法、构造函数或块内部定义的变量。
2024年华为OD机试真题-查找充电设备-C++-OD统一考试（E卷）
面试高手的博客
11-08 299
某个充电站，可提供n个充电设备只，每个充电设备均有对应的输出功率任意个充电设备组合的输出功率总和，均构成功率集合P的1个元素功率集合P的最优元素，表示最接近充电站最大输出功率pmax 的元素。每一题都含有详细的解题思路和代码注释，精编c++、JAVA、Python三种语言解法。当充电设备输出功率50、20、20组合时，其输出功率总和为90，最接近充电站最大充电输出功率，因此最优元素为90。所有充电设备的输出功率组合，均大于充电站最大充电输出功率30，此时最优元素值为0。第 2 行为每个充电设备的输出功率。
JAVA学习接口案例实例
shangan_3的博客
11-08 215
【代码】JAVA学习接口案例实例。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值