😀 Java并发 – (并发基础)
Java并发 – (并发基础)
1、什么是共享资源
-
堆是被所有线程共享的一块内存区域。在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例
-
Java中几乎所有的对象实例都在这里分配内存。方法区与堆一样，也是各个线程共享的一块内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。
-
光看文字，会让我们觉得很抽象。如下图：
2、并发编程的难点
🤔 原子性问题
- 操作系统做任务切换(
CPU切换)，可以发生在任何一条CPU指令执行完成后; - CPU能保证的原子操作是指令级别的，而不是高级语言的操作符(
例如：n++)。 - 如下图，是
n++编译后，被编译CPU执行的指令。
🧐 可见性问题
- 可见性是指一个线程对共享变量的修改，另外一个线程能够立刻看到。
- 可见性问题是由
CPU的缓存导致的，多核CPU均有各自的缓存，这些缓存均要与内存进行同步。
🧡 有序性问题
- 在执行程序时。为了提高性能，编译器和处理器常常会对指令做
重排序; - 重排序不会影响单线程的执行结果，但是在并发情况下，可能会出现诡异的BUG。
- 参考地址：//zhuanlan.zhihu.com/p/298448987
3、JMM
💛 并发编程的关键目标
并发编程需要处理两个关键问题，即线程之间如何通信和同步。
- 通信:指线程之间以何种机制来交换信息;
- 同步:指程序中用于控制不同线程之间的操作发生的相对顺序的机制。
💜 并发编程的内存模型
共有两种并发编程模型:共享内存模型、消息传递模型,Java采用的是前者。
- 在共享内存模型下，线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信;
- 在共享内存模型下，同步是显示进行的，程序员必须显示指定某段代码需要在线程之间互斥执行。
❣️ 这个内存模型:JMM
- 参考地址：//javaguide.cn/java/concurrent/jmm.html#从-cpu-缓存模型说起
- 参考地址：//xie.infoq.cn/article/739920a92d0d27e2053174ef2
- 参考地址：//concurrent.redspider.group/RedSpider.html
JMM 是
Java Memory Model的缩写，Java线程之间的通信由 JMM 控制，即JMM决定一个线程对共享变量的写入何时对另一个线程可见。JMM定义了线程和主内存之间的抽象关系，通过控制主内存与每个本地内存（抽象概念）之间的交互，JMM为Java程序员提供了内存可见性的保证。
🔵 源代码与指令间的重排序
为了
提高性能，编译器和处理器常常会对指令做重排序。重排序有3种类型，其中后2种都是处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。
- 编译器优化重排序：编译器在不改变单线程程序语义的前提下可以重新安排语句的执行顺序。
- 指令级并行重排序︰现代处理器采用了指令级并行技术来将多条指令重叠执行，如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
- 内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
🍉 重排序对可见性的影响
参考下图，虽然处理器执行的顺序是A1->A2，但是从内存角度来看，实际发生的顺序是A2->A1。这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与实际的操作执行顺序不一致。由于现代的处理器都会使用写缓冲区，因此它们都会允许对写 – 读操作执行重排序。
❓ 如何解决重排序带来的问题
对于编译器，
JMM的编译器重排序规则会禁止特定类型的编译器重排序(比如volatile)。对于处理器重排序，
JMM的处理器重排序规则会要求编译器在生成指令序列时，插入特定类型的内存屏障（Memcry Barries /Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。
由于常见的处理器内存模型比JMM要弱， Java编译器在生成字节码时，会在执行指令序列的适当位置插入内存屏障来限制处理器的重排序。同时，由于各种处理器内存模型的强弱不同，为了在不同的处理器平台向程序员展示一个一致的内存模型,JMM在不同的处理器中需要插入的内存屏障的数量和种类也不同。
CPU内存屏障:
- LoadLoad: 禁止读和读的重排序;
- StoreStore:禁止写和写的重排序;
- LoadStore:禁止读和写的重排序;
- StoreLoad:禁止写和读的重排序。
Java内存屏障
public final class Unsafe {
public native void loadFerice();// LoadLoad + LoadStore
public native void storeFence();// StoreStore + LoadStore
public native void fullFence(); // loadFence() + storeFence() + StoreLoad
}
❓ happens-before
JMM使用
happens-before规则来阐述操作之间的内存可见性，以及什么时候不能重排序。在JMM中。如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before关系。换个角度来说．如果A happens-before B，则意味着A的执行结果必须对B可见，也就是保证跨线程的内存可见性。其中，前4条规则与程序员密切相关。
- 1、程序顺序规则:一个线程中的每个操作, happens-before于该线程中的任意后续操作;
- 2、volatile变量规则:对一个volatile域的写, happens-before于任意后续对这个volatile域的读;
- 3、synchronized规则:对一个锁的解锁, happens-before于随后对这个锁的加锁;
- 4、传递性:若A happens-before B，且B happens-before C，则A happens-before C;
- 5、start()规则:若线程A执行Thread.start()，则线程A的start()操作happens-before于线程B中的任意操作;
- 6、 join()规则︰若线程A执行ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()的成功返回。
4、Volatile
🍊 volatile的基本特性
- 可见性:对一个
volatile变量的读，总是能看到对这个volatile变量最后的写入; - 原子性:对任意单个
volatile变量的读/写具有原子性，但类似vclatile++这种复合操作不具有原子性。
🍐 volatile的内存语义
- 写内存语义:当写一个
volatile变量时，JMM会把该线程本地内存中的共享变量的值刷新到主内存; - 读内存语义:当读一个
volatile变量时，JMM会把该线程本地内存置为无效，使其从主内存中读取共享变量。
🥥 volatile的实现机制
为了实现
volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。
- 在每个volatile写操作的前面插入一个StoreStore屏障;
- 在每个volatile写操作的后面插入一个StoreLoad屏障;
- 在每个volatile读操作的后面插入—个LoadLoad屏障;
- 在每个volatile读操作的后面插入一个LoadStore屏障。
🥩 volatile与锁的对比
volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。在功能上锁比volatile更强大，在可伸缩性和执行性能上volatile更有优势。
5、锁
锁的内存语义
- 当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中;
- 当线程获取锁时，JMM会把该线程对应的本地内存置为无效。
锁的实现机制
- synchronized:采用
CAS + Mark Word实现。存在锁升级的情况; - Lock:采用
CAS + volatile实现。存在锁降级的情况核心是AQS 。
