文章目录
1.JMM(Java Memory Model)
Java内存模型 [Java Memory Model]
速度排序：CPU > 内存 > I/O 设备
- CPU 增加了缓存，以均衡内存与 CPU 的速度差异；
- 操作系统以线程分时复用 CPU，进而均衡 I/O 设备与 CPU 的速度差异；
- 编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。
CPU要通过内存从硬盘上(IO设备读取数据),可在CPU中放置缓存区,存放缓存数据,
缓存中的数据和内存中的数据可能不一致.
Java 内存模型，用于
屏蔽掉各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的并发效果，JMM 规范了 Java 虚拟机与计算机内存是如何协同工作,规定了一个线程如何以及何时可以看到由其他线程修改过后的共享变量的值，以及如何同步的访问共享变量。
计算机在高速的 CPU 和相对低速的存储设备之间使用高速缓存，作为内存和处理器之间的缓冲。将运算需要使用到的数据复制到缓存中，让运算能快速运行，当运算结束后再从缓存同步回内存之中。
在多处理器的系统中(或者单处理器多核的系统)，每个处理器内核都有自己的高速缓存，它们有共享同一主内存(Main Memory)。当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致。
Java 内存模型中规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。
工作内存是 JMM 的一个抽象概念，也叫本地内存，其存储了该线程以读 / 写共享变量的副本。
在具体操作时,主内存的和数据先读取到要执行各个线程中的工作内存中进行缓存;
然后各自线程在各自操作后,存到工作内存中,再将数据更新到主内存中去.
每个处理器内核拥有私有的高速缓存，JMM 中每个线程拥有私有的本地内存。
不同线程之间无法直接访问对方工作内存中的变量，
线程间的通信一般有两种方式进行:一是通过消息传递，二是共享内存。
Java语言就是用了共享内存的方式.
主内存、工作内存与 Java 内存区域中的 Java 堆、栈、方法区等并不是同一个层次的内存划分，这两者基本上是没有关系的.
从变量、主内存、工作内存的定义来看，主内存主要对应于Java 堆中的对象实例数据部分，而工作内存对应于虚拟机栈中的部分区域。
线程本地缓存, 会导致可见性问题
线程切换执行, 会导致原子性问题
编译优化重排指令, 会导致有序性问题
2.并发编程的可见性
可见性:一个线程对共享变量的修改，另外一个线程能够立刻看到.
多核处理器，每个 CPU 都有自己的缓存，缓存仅对所在处理器可见，CPU 缓存与内存的数据很难保证一致。
避免处理器停顿下来等待向内存写入数据而产生的延迟，处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区合并对同一内存地址的多次写操作，并以批处理的方式刷新，写缓冲区不会即时将数据刷新到主内存中。缓存不能及时刷新导致可见性问题。
案例:
假设线程 1 和线程 2 同时开始执行，那么第一次都会将 a=0 读到各自的CPU 缓存里，线程 1 执行 a++之后 a=1，但是此时线程 2 是看不到线程 1 中 a 的值的，所以线程 2 里 a=0，执行 a++后 a=1。
线程 1 和线程 2 各自 CPU 缓存里的值都是 1，之后线程 1 和线程 2 都会将自己缓存中的 a=1 写入内存，导致内存中 a=1，而不是我们期望的 2。
3.并发编程的有序性
有序性指的是程序按照代码的先后顺序执行。
编译器为了优化性能，有时候会改变程序中语句的先后顺序;
比如说有两个执行指令,指令1要去内存中读取数据,比较慢,这样的话,会影响到效率;那么就可以把指令2拉到前面来,让指令2先去执行;
但是毕竟打乱顺序是不太好的,可能会出现问题;
例如执行这道蒸米饭的流程:
正常流程: 淘洗米粒--> 打开蒸锅盖--> 均匀放入米粒和纯净水--> 关上蒸锅盖-->打开蒸锅电源;
若乱序打破顺序,可能出现:
关上蒸锅盖--> 均匀放入米粒和纯净水--> 淘洗米粒--> 打开蒸锅盖 -->打开蒸锅电源;
4.并发编程的原子性
-
原子性是指不可分,在线程切换时可能就会出现原子性问题,
-
一个或者多个操作,在CPU执行过程中只要不被中断,顺利执行下去,就是遵循了原子性;
-
不论是多核还是单核，具有原子性的量，同一时刻只能有一个线程来对它进行操作.
-
CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符。线程切换导致了原子性问题.
-
Java 并发程序都是基于多线程的，自然也会涉及到任务切换，任务切换的时机大多数是在时间片结束的时候。
案例:
- 指令 1：把变量 count 从内存加载到工作内存；
- 指令 2：在工作内存执行 +1 操作；
- 指令 3：将结果写入内存;
- 两个线程 A 和 B 同时执行 count++，即便 count 使用 volatile 修辞，我们预期的结果值是 2，但实际可能是 1。
注意:++操作分开的话就是先运算,再赋值,若在线程1中读取到操作数后,还没进行赋值操作呢,线程切换了,这时再另一个线程中度取到的还是那个操作数,然后操作一下;这时线程又切换了;线程直接输出了操作数;
在这个线程切换的时候,就已经破坏了原子性;
5.volatile 关键字
使用volatile 关键字修饰 共享变量（类的成员变量、类的静态成员变量) 时:
- 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
- 禁止指令重排;
- 无法保证原子性;
案例:
比如这里放置了一个共享的标记值flag;
public class ThreadDemo implements Runnable{
//共享数据;
private boolean flag = false;
@Override
public void run() {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
//让一个线程修改共享变量值
this.flag = true;
System.out.println(this.flag);
}
//getter,setter方法;
public boolean getFlag() {
return flag;
}
public void setFlag(boolean flag) {
this.flag = flag;
}
}
测试,执行;
public class TestVolatile {
public static void main(String[] args) {
ThreadDemo td = new ThreadDemo();
//创建线程
Thread t = new Thread(td);
t.start();
//当读取到标记值被修改时才能退出这个死循环;
while(true){
//main线程执行需要用flag变量;
if(td.getFlag()){
System.out.println("main线程执行---->");
break;
}
}
}
}
虽然在某个线程中已经将标记值flag改为了true;但是main线程并不知道,
导致循环无法退出,main线程无法执行完成;
若用volatile 关键字来修饰共享变量;
这边线程修改了标记值,那么由于可见性,main线程这边可以及时看到改变;
再次测试;
单例模式的双重检查版本时,就用到了volatile 关键字;利用了它的可见性属性;
public class DuplicationCheck {
public static void main(String[] args) {
//这里通过Singleton类提供的方法 ;获取Singleton类的对象;
Singleton singleton1 = Singleton.getInstance();
Singleton singleton2 = Singleton.getInstance();
System.out.println(singleton1.hashCode());//460141958
System.out.println(singleton2.hashCode());//460141958
//注意看看两次获取的是 同一个对象;
System.out.println(singleton1 == singleton2);// true
}
}
// 双重检查版;
class Singleton {
// 将构造方法私有化;
private Singleton() {
}
// 在自己内部定义引用;
// 用 volatile修饰的共享变量，每次的更新对于其他线程都是可见的 ;
private static volatile Singleton singleton;
//给外界提供一个获取对象的方法;
public static Singleton getInstance() {
//当不存在实例对象时才创建;
if (singleton == null) {
//用同步代码块;
synchronized (Singleton.class){
//在这里再次进行判断检查;
if(singleton == null){
singleton = new Singleton();
}
}
}
return singleton;
}
}
6.保持原子性: 加锁,JUC原子类
加锁
加锁这个概念,在当时初步学习线程的时候,就已经学到了;
ReentrantLock锁,synchronized锁;
将无法分离的执行操作,加上锁,即可保持原子性;但是从效率方面看的话,加锁使得效率降低;
- synchronized 是独占锁/排他锁(
后面会学到);synchronized 并不能阻止 CPU 时间片切换，只是当其他线程要访问这个资源时，发现锁还未释放，所以只能在外面等待。
- synchronized 可以保证原子性，由于被 synchronized 修饰的代码，无论是单核 CPU 还是多核 CPU，只有一个线程能够执行该代码，一定能保证原子操作.
synchronized 也能够保证可见性和有序性。
JUC原子类
加锁的话是阻塞式的实现;
原子变量是非阻塞式方式实现.
在jdk可查看这两个包,可保持原子性;
原子类的原子性是通过 volatile + CAS 实现原子操作的。
AtomicInteger 类中的 value 是有volatile 关键字修饰的，保证value的内存可见性.
低并发情况下：使用 AtomicInteger。
案例一; 比如对这个共享变量num不用任何机制;
num++操作的话,它不是安全的,在线程切换时可能会破坏原子性;
public class ThreadDemo implements Runnable {
//共享变量
private int num = 0;
@Override
public void run() {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + ":::" + getNum());
}
public int getNum() {
return num++;
}
}
测试
public class Test {
public static void main(String[] args) {
ThreadDemo td = new ThreadDemo();
for (int i = 0; i <10 ; i++) {
Thread t = new Thread(td);
t.start();
}
}
}
多执行几次,就会发现num++操作并不安全;有可能一个线程正在读取,就被另一个线程抢了,执行后,线程切换之后操作数可能会出现同样的结果.
案例二:
在试试用volatile修饰共享变量数据;
public class ThreadDemo implements Runnable {
//共享变量
private volatile int num = 0;
@Override
public void run() {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + ":::" + getNum());
}
public int getNum() {
return num++;
}
}
测试,多执行几次;发现还是无法保持原子性;
案例三:
使用并发包下的原子类修饰共享变量;
其中调用的getAndIncrement()方法[获得并且＋1操作]就相当于++的操作;并且人家是并发包提供的方法;
getAndIncrement()相当于 i++ ;incrementAndGet()相当于 ++i ;
public class ThreadDemo implements Runnable {
//共享变量
private AtomicInteger num = new AtomicInteger(0);
@Override
public void run() {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + ":::" + getNum());
}
public int getNum() {
return num.getAndIncrement();
}
}
测试,多执行几次,发现保持原子性还是可以的;
7.CAS (Compare-And-Swap)
Compare-And-Swap 就是比较并且交换;硬件对于并发操作的支持
实现方式为乐观锁,以自旋锁为思想;轻量级锁的状态;(下篇笔记中有这几个锁的概述说明);
乐观锁就是自信地不加锁,
自旋锁就是轮询的方式进行检测,不停地比较共享数据的预估值信息和内存中的信息是否相同;
(轮询这个概念在上次学Nginx的特性的时候有一点印象).
轻量级锁:其实还是用了自旋的思想,不会导致线程阻塞;
- 每次判断预期值和内存中的值是不是相同，如果不相同则说明该内存值已经被其他线程更新过了，因此需要拿到该最新值作为预期值，重新判断。
- 线程不断的循环判断是否该内存值已经被其他线程更新过了，这就是自旋的思想。
比如刚才案例三种调用原子类AtomicInteger的方法getAndIncrement();
它调用了getAndAddInt()方法;
底层也有CAS的身影
CAS 包含了三个操作数：
- 内存值 V
- 预估值 A (比较时,从内存中再次读到的值)
- 更新值 B (更新后的值)
当且仅当预期值A==V，将内存值V=B，否则什么都不做
当判断不成功不能更新值时,不会阻塞,继续获得 cpu执行权,继续判断执行
缺点:
CAS 使用自旋锁的方式，该锁不断循环判断，
因此不会类似 synchronize线程阻塞导致线程切换。
不断的自旋，会导致 CPU 的消耗，在并发量大的时候容易导致 CPU 跑满,所以说比较适用于低并发.
比如说;线程A在主内存读取到num=0;然后一番操作;这时先看一下主内存的值是不是改了(这个是不断地轮询检测的);发现没有该改变;好的,快速把更新的值num=1 更新到内存值;
然后再看这个情况;
在线程A读取时,线程B也读取了;然后它操作比较快;在预估值A和内存值V比较,好的,把最终更新值num=1更新过去;
这时的话,线程A啊,它也操作完了,慢着,先用预估值探探路,发现预估值和内存值不一致,那么,就别去提交了,要是提交的话就没法保证原子性.
在CAS中的ABA问题
某个线程将内存值由 A 改为了 B，再由 B 改为了 A。
当另外一个线程使用预期值去判断时，预期值与内存值相同，误以为该变量没有被修改过而导致的问题。
解决 ABA 问题的主要方式，通过使用类似添加版本号的方式，来避免 ABA 问题。
如原先的内存值为（A，1），线程将（A，1）修改为了（B，2），再由（B，2）修改为（A，3）。
此时另一个线程使用预期值（A，1）与内存值（A，3）进行比较，只需要比较版本号 1 和 3，即可发现该内存中的数据被更新过了。
594
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
