怎样使用网站模板,给别人做网站是外包公司,织梦网站模板如何安装教程视频教程,宝安网站制作哪家强目录
1. 单例模式 (1) 饿汉模式 (2) 懒汉模式 1. 单线程版本 2. 多线程版本 2. 解决懒汉模式产生的线程安全问题 (1) 产生线程安全的原因 (2) 解决线程安全问题 1. 通过加锁让读写操作紧密执行
方法一
方法二 2. 处理加锁引入的新问题 问题描述 … 目录
1. 单例模式 (1) 饿汉模式 (2) 懒汉模式 1. 单线程版本 2. 多线程版本 2. 解决懒汉模式产生的线程安全问题 (1) 产生线程安全的原因 (2) 解决线程安全问题 1. 通过加锁让读写操作紧密执行
方法一
方法二 2. 处理加锁引入的新问题 问题描述 解决方法 3. 避免内存可见性指令重排序 (1) 杜绝内存可见性问题 (2) 避免指令重排序问题
1. 模拟编译器指令重排序情景
2. 指令重排序概述
3. 指令重排序类型
(1)编译器重排序
(2) 处理器重排序
4. 指令重排序所引发的问题 1. 单例模式 单例模式能保证某个类在程序中只存在唯 一 一 份实例而不会创建出多个实例不允许new多次。要想保证单例模式只有唯一 一个实例最重要的做法就是用 private 修饰所有的构造方法在 new 的过程中会调用实例的类中的构造方法只要用 private 修饰所有构造方法在类外就无法获取到构造方法进而使得 new 操作在编译时报错因此保证某个类在程序中只能有一份实例而不能创建多个实例。 这一点在很多场景上都需要比如 JDBC 中的 DataSource 实例就只需要一个. 单例模式具体的实现方式分成 饿汉 和 懒汉 两种。 (1) 饿汉模式 下面这段代码是对唯一成员 instance 进行初始化用 static 修饰 instance对 instance 的初始化会在类加载的阶段触发类加载往往就是在程序一启动就会触发
由于是在类加载的阶段就早早地创建好了实例(static修饰)这也就是“饿汉模式” 名字的由来。 在初始化好 instance 后后续统一通过调用 getInstance() 方法获取 instance 单例模式的“点睛之笔”用 private 修饰类中所有构造方法 (2) 懒汉模式 如果说饿汉模式就是类加载的时候一个比较早的时期进行创建实例并且使用private 修饰所有的构造方法使得在代码中无法创建该类的其他实例那么懒汉方式的核心思路就是延时的去创建实例延时是真正用到的时候再去创建。这样的思路在编程中是非常有用的思路一些情况下并不需要实例对象通过懒汉模式来写代码就不会去实例对象进而可以减小开销提升效率。 1. 单线程版本 懒汉模式下创建线程的时机是在第一次使用的时候而不是在程序启动的时候
如果程序一启动就要去使用实例那 懒汉模式 和 饿汉模式 没有区别但是程序运行很久了都没有用到此时懒汉模式创建实例的时间更晚一些这样能减少不必要的开销 2. 多线程版本 2.解决懒汉模式产生的线程安全问题 (1) 产生线程安全的原因 对于饿汉模式 对于懒汉模式
为什么会有单线程版本和多线程版本的懒汉模式写法呢我们来看单线程版本如果运用到多线程的环境下会出现什么问题 instance 被 static 修饰多个线程调用 getInstance()返回的是同一个内存变量通过上面单线程版本的懒汉模式我们可以发现在 getInstance() 中不但涉及了读操作并且涉及了写操作虽然对于图中标注的写操作是赋值操作并且这一步的操作是原子的但是在多线程下调用的 getInstance() 方法并不是原子的getInstance() 方法中不但有写的操作还有读的操作满足条件才赋值不满足条件不赋值所以判断和赋值两个操作是紧密相连的不能保证这两步操作紧密执行就会出现下面的线程安全问题 t1t2如果按照上面的执行步骤会出现值覆盖随着第二个线程的覆盖操作第一个线程 new 出来的对象会被 GC 回收掉。看起来没什么问题但是 new 一个对象会产生大量额外不必要的开销new 一个对象的过程可能会把大内存的数据从硬盘加载到内存中单例模式不仅仅是期待只创建一个实例更重要的是期望不要进行这种重复性的耗时的工作一来没意义二来空间不允许即使对于上面的情况创建的第一个对象很快就被释放掉了但是也是有数据加载过程的。 总结
饿汉模式只涉及对内存变量的读操作不涉及写操作因此饿汉模式是线程安全的在单线程或者多线程的情况下饿汉模式的基本形式不变对于懒汉模式在 getInstance() 中涉及紧密相连的读写操作但是因为读写操作不能紧密执行导致出现线程安全问题。 (2) 解决线程安全问题 面试题
这两个单例模式的 getInstance() 在多线程环境下调用是否会出现 bug如何解决 bug? 1. 通过加锁让读写操作紧密执行 对于上述饿汉模式出现线程安全问题的原因就是读写操作判断 赋值不能紧密执行因此我们要对读写两步操作进行加锁才能保证线程安全问题
方法一 这样加锁后如果 t1 和 t2 还出现下图读写逻辑的执行顺序 t2 会阻塞等待 t1 或者 t1 会阻塞等待 t2new好对象之后读写操作结束后释放锁第二个线程才可以进行读写操作此时第二个线程的判断发现 instance ! null就会直接 return而不会再进行实例 。 方法二 直接对 getInstance() 方法加锁也能达到读写操作紧密执行的效果
此时锁对象locker — SingletonLazy.class这两种方法达到的效果相同。 2. 处理加锁引入的新问题 问题描述 对于当前懒汉模式的代码两个线程一把锁是不会构成请求保持形成死锁的
多个线程调用 getInstance() 方法其实只需要保证第一个线程调用 getInstance()执行的读写操作是紧密执行的即可后续的线程在进行读操作发现 instance ! null就都不会触发写操作自然就保证了线程安全 但是按照上图的 getInstance() 方法发现多个线程每次调用 getInstance() 都会进行一次加锁解锁操作因为synchronized 是重量锁多次的加锁解锁会造成大量额外的开销大大减低性能 拓展 StringBuffer 就是为了解决大量拼接字符串时产生很多中间对象问题而提供的一个类提供 append 和 insert 方法可以将字符串添加到已有序列的 末尾 或 指定位置。 StringBuffer 的本质是一个线程安全的可修改的字符序列把所有修改数据的方法都加上了synchronized。但是保证了线程安全是需要性能的代价的。 在很多情况下我们的字符串拼接操作不需要线程安全这时候 StringBuilder 登场了StringBuilder 是 JDK1.5 发布的 StringBuilder 和 StringBuffer 本质上没什么区别就是去掉了保证线程安全的那部分减少了开销。所以在单线程情况下优先考虑使用 StringBuilder。 StringBuffer 和 StringBuilder 二者都继承了 AbstractStringBuilder底层都是利用可修改的 char数组 (JDK9以后是 byte 数组)。 所以如果我们有大量的字符串拼接如果能预知大小的话最好在new StringBuffer 或者 new StringBuilder 的时候设置好 capacity 避免多次扩容的开销扩容要抛弃原有数组还要进行数组拷贝创建新的数组。 解决方法 再嵌套一次判断操作既可以保证线程安全又可以避免大量加锁解锁产生的开销 在单线程中连续嵌套两层相同的 if 语句是没有意义的因为单线程的 “执行流” 只有一个 嵌套两层相同的 if 语句结果相同但是在多线程中有多个并发执行的执行流可能因为其中一个线程修改了 instance导致其他线程再次执行到判断操作时会有所不同如上述懒汉模式在多线程下两个 if 得到的结果是不同的 虽然两个if相同但是目的和作用截然不同上面的 if是用来判断是否需要加锁下面的 if 判断是否需要new对象。 虽然两个 if 相同但是这只是一个巧和 3. 避免内存可见性指令重排序 要杜绝可能会出现的内存可见性问题 并且避免指令重排序问题只需要使用 volatile 修饰instance 即可 (1) 杜绝内存可见性问题 假如不加volatile 那么假设两个线程都执行到 synchronized 锁时, 一个线程加锁另一个线程阻塞等待 然后获取到锁对象的线程, 创建出来了这个单例 释放锁之后另一个没获取到锁对象的线程, 获取锁之后执行 if 判断结果它读取的到的instance的值是之前寄存器缓存中的值而寄存器中缓存的 instance 还是null因此第二个线程又回去执行锁中的逻辑就又会去实例化一个新的 instance。 内存可见性就是保证 每次去读取的时候, 读取到的值都是最新的值内存中的值而不是之前缓存在寄存器中的值 如果不加volatile 在上面说的案例中, 会有可能存在第二个线程获取到锁对象结果发现这个单例instance是等于 null的情况所以需要加上volatile 来保证不会出现这样的情况。 (2) 避免指令重排序问题 1. 模拟编译器指令重排序情景 要在超市中买到左边购物清单的物品有两种买法 方法一根据购物清单的顺序买(按照程序员编写的代码顺序进行编译) 方法二根据物品最近距离购买通过指令重排序后再编译 两种方法都能买到购物清单的所有物品但是比起第一种方法第二种方法在不改变原有逻辑的情况下优化执行指令顺序更高效地执行完所有的指令。 处理好加锁所引入的问题之后还有剩余的 指令重排序问题 和 可能会出现的 内存可见性 问题 在第一个 if 结束后可能不会直接 return而是还有后续的逻辑 如果是在最开始的懒汉模式的版本 只有一个套着 synchronized 的 if 的时候会因为加锁阻塞而避免使用未触发对象 (instance未初始化) 的情况就不会出现指令重排序问题 但是我们为了考虑效率为了减少不必要的加锁操作减少开销我们多加了一层 if正是多加了一层if使得 t2 线程因为未触发 synchronized 而不会进入阻塞等待 所以在 t1 线程还没来得及初始化 instance 时t2 就直接拿着未初始化的 instance 执行第一个 if 后面后续的逻辑了 左边是 多线程版本 的 懒汉模式 中的 getInstance() 要执行的操作右边是多个线程调用 getInstance() 如果真的因为指令重排序而导致 内存空间的首地址赋值给引用变量拿到钥匙 的操作被重排序到 初始化 instance 之前装修就会出现下面的问题 在一个线程已经获取锁对象进行加锁还未来得及初始化 instance 时另一个线程会因为最外层的 if 语句而跳过 if 中代码块里的加锁操作而避免了阻塞等待 如果后续的 getInstance() 在第一层 if 语句后还有其他逻辑第二个线程就会拿着未被初始化的 instance 来进行后面的逻辑。 这就是指令重排序问题而使用 volatile 修饰 instance 后不但能确保每次读取操作都是读内存而且关于该变量的读取和修改操作不会触发重排序。 2. 指令重排序概述 指令重排序是指编译器或处理器为了提高性能在不改变程序执行结果的前提下可以对指令序列进行重新排序的优化技术。这种优化技术可以使得计算机在执行指令时更高效地利用计算资源提高程序的执行效率。 JMMJava 内存模型详解 指令重排序 为了提升执行速度/性能计算机在执行程序代码的时候会对指令进行重排序。 什么是指令重排序? 简单来说就是系统在执行代码的时候并不一定是按照你写的代码的顺序依次执行。 常见的指令重排序有下面2种情况: (1) 编译器优化重排: 编译器包括JVM、JIT编译器等在不改变单线程程序语义的前提下重新安排语句的执行顺序。 (2) 指令并行重排: 现代处理器采用了指令级并行技术Instruction-Level ParallelismILP来将多条指令重叠执行。如果不存在数据依赖性处理器可以改变语句对应机器指令的执行顺序。 另外内存系统也会有“重排序”但又不是真正意义上的重排序。在JMM里表现为主存和本地内存的内容可能不一致进而导致程序在多线程下执行可能出现问题。 Java 源代码会经历编译器优化重排—指令并行重排一内存系统重排的过程最终才变成操作系统可执行的指令序列。 指令重排序可以保证串行语义一致但是没有义务保证多线程间的语义也一致所以在多线程下指令重排序可能会导致一些问题。 对于编译器优化重排和处理器的指令重排序指令并行重排和内存系统重排都属于是处理器级别的指令重排序处理该问题的方式不一样。 对于编译器通过禁止特定类型的编译器重排序的方式来禁止重排序。对于处理器通过插入内存屏障(Memory Barrier或有时叫做内存栅栏Memory Fence)的方式来禁止特定类型的处理器重排序。 内存屏障(Memory Barrier或有时叫做内存栅栏Memory Fence)是一种CPU指令用来禁止处理器指令发生重排序(像屏障一样)从而保障指令执行的有序性。 另外为了达到屏障的效果它也会使处理器写入、读取值之前将主内存的值写入高速缓存清空无效队列从而保障变量的可见性。 3. 指令重排序类型 (1)编译器重排序 编译器在生成目标代码时会对源代码中的指令进行优化和重排以提高程序的执行效率。编译器重排序时在编译阶段完成的目的是生成更高效率的机器代码。 (2) 处理器重排序 处理器在执行指令也可以对指令进行重排序以最大程度地利用处理器的流水线和多核等特性。目的提高指令的执行效率。 4. 指令重排序所引发的问题 虽然指令重排序可以提高程序的执行效率但是在多线程编程中可能会引发内存可见性问题。由于指令重排序 可能导致共享变量的读写顺序与代码中的顺序不一致当多个线程同时访问共享变量时可能会出现数据不一致的情况。
