四、共享模型之内存( 主要是volatile 的使用）
1. Java 内存模型
JMM 即 Java Memory Model，它定义了主存（共享内存）、工作内存（线程私有）抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、 CPU 指令优化等。
JMM体现在以下几个方面
原子性 - 保证指令不会受到线程上下文切换的影响
可见性 - 保证指令不会受 cpu 缓存的影响
有序性 - 保证指令不会受 cpu 指令并行优化的影响
2. 可见性
（1）背景： 工作线程会将主存中的数值读取到工作线程中的缓存。如果此时主存中数值改变，但是工作线程中读取的值并不会改变，从而引发问题。
（2）解决方法： 使用volatile易变关键字。它可以用来修饰成员变量和静态成员变量（放在主存中的变量），他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存。
（3）可见性与原子性
前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对volatile变量的修改对另一个线程可见， 不能保证原子性，仅用在一个写线程，多个读线程的情况。
注意， synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是 synchronized 是属于重量级操作，性能相对更低。
另外，如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到 对 run 变量的修改了，想一想为什么？因为使用了synchronized关键字。
（4）两阶终止模式优化。
用 volatile 是为了保证该变量在多个线程之间的可见性
（5）同步模式之犹豫模式。*
定义，Balking （犹豫）模式用在一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做 了，直接结束返回。用一个标记来判断该任务是否已经被执行过了，需要避免线程安全问题。加锁的代码块要尽量的小，以保证性能。
3. 有序性
定义：JVM 会在不影响正确性的前提下，可以调整语句的执行顺序
方法：volatile 修饰的变量，可以禁用指令重排
指令重排：
事实上，现代处理器会设计为一个时钟周期完成一条执行时间长的 CPU 指令。为什么这么做呢？可以想到指令还可以再划分成一个个更小的阶段，例如，每条指令都可以分为： 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 这5 个阶段
在不改变程序结果的前提下，这些指令的各个阶段可以通过重排序和组合来实现指令级并行
支持流水线的处理器：
现代 CPU 支持多级指令流水线，例如支持同时执行 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 的处理器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一 条执行时间长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令地吞吐率。
4. 内存屏障原理
可见性
写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中新数据
有序性
写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
5. Volatile 原理
（1）原理
volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）。 对 volatile 变量的写指令后会加入写屏障，对 volatile 变量的读指令前会加入读屏障。
（2）保证可见性
写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中新数据
（3）保证有序性
写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
（4）不保证原子性
（5）double-checked locking 问题
五、共享模型之无锁（主要是通过乐观锁来实现资源共享）
1. 无锁解决线程安全问题
使用原子整数 AtomicInteger balance = new AtomicInteger();
2. CAS与volatile
（1）AtomicInteger 的解决方法，内部并没有用锁来保护共享变量的线程安全。那么它是如何实现的呢？
其中的关键是 compareAndSwap（比较并设置值），它的简称就是 CAS （也有 Compare And Swap 的说法），它必须是原子操作。
（2）工作流程
当一个线程要去修改Account对象中的值时，先获取值pre（调用get方法），然后再将其设置为新的值next（调用cas方法）。在调用cas方法时，会将pre与Account中的余额进行比较。
如果两者相等，就说明该值还未被其他线程修改，此时便可以进行修改操作。
如果两者不相等，就不设置值，重新获取值pre（调用get方法），然后再将其设置为新的值next（调用cas方法），直到修改成功为止。
注意：其实 CAS 的底层是 lock cmpxchg 指令（X86 架构），在单核 CPU 和多核 CPU 下都能够保证【比较-交换】的原子性。
在多核状态下，某个核执行到带 lock 的指令时，CPU 会让总线锁住，当这个核把此指令执行完毕，再开启总线。这个过程中不会被线程的调度机制所打断，保证了多个线程对内存操作的准确性，是原子的。
（3）volatile的重要性
获取共享变量时，为了保证该变量的可见性，需要使用 volatile 修饰。
它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取 它的值，线程操作 volatile 变量都是直接操作主存。即一个线程对 volatile 变量的修改，对另一个线程可见。
注意：volatile 仅仅保证了共享变量的可见性，让其它线程能够看到新值，但不能解决指令交错问题（不能保证原子性）。CAS 必须借助 volatile 才能读取到共享变量的新值来实现【比较并交换】的效果
（4）效率问题
一般情况下，使用无锁比使用加锁的效率更高。
（5）CAS特点
结合 CAS 和 volatile 可以实现无锁并发，适用于线程数少、多核 CPU 的场景下。
CAS 是基于乐观锁的思想：乐观的估计，不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗。
synchronized 是基于悲观锁的思想：悲观的估计，得防着其它线程来修改共享变量，我上了锁你们都别想改，我改完了解开锁，你们才有机会。
CAS 体现的是无锁并发、无阻塞并发，请仔细体会这两句话的意思
因为没有使用 synchronized，所以线程不会陷入阻塞，这是效率提升的因素之一
但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响
3. 原子整数（更新基本类型）
J.U.C 并发包提供了
AtomicBoolean
AtomicInteger
AtomicLong
4. 原子引用
//原子引用，泛型类型为小数类型
AtomicReference
AtomicReference是作用是对”对象”进行原子操作。 提供了一种读和写都是原子性的对象引用变量。原子意味着多个线程试图改变同一个AtomicReference(例如比较和交换操作)将不会使得AtomicReference处于不一致的状态。
使用场景：一个线程使用student对象，另一个线程负责定时读表，更新这个对象。那么就可以用AtomicReference这个类。
5. ABA问题
（1）问题描述：主线程仅能判断出共享变量的值与初值 A 是否相同，不能感知到这种从 A 改为 B 又 改回 A 的情况，如果主线程希望：
只要有其它线程【动过了】共享变量，那么自己的 cas 就算失败，这时，仅比较值是不够的，需要再加一个版本号
（2）方法
AtomicStampedReference 可以给原子引用加上版本号，追踪原子引用整个的变化过程，如： A -> B -> A -> C ，通过AtomicStampedReference，我们可以知道，引用变量中途被更改了几次。
AtomicMarkableReference并不关心引用变量更改了几次，只是单纯的关心是否更改过，所以就有了。
两者的区别，AtomicStampedReference 需要我们传入整型变量作为版本号，来判定是否被更改过。AtomicMarkableReference需要我们传入布尔变量作为标记，来判断是否被更改过。
6. 原子数组（更新数组类型）
（1）分类
AtomicLongArray：提供对int[]数组元素的原子性更新操作。
AtomicIntegerArray：提供对long[]数组元素的原子性更新操作。
AtomicReferenceArray：提供对引用类型[]数组元素的原子性更新操作。
（2）lamba表达式的使用
提供者
无参又返回
()->返回结果
方法
有参有返回
(参数一…)->返回结果
消费者
有参无返回
(参数一…)->void
7. 原子更新属性
（1）类型
AtomicIntegerFieldUpdater
AtomicLongFieldUpdater
AtomicStampedReference
AtomicReferenceFieldUpdater
原子更新器用于帮助我们改变某个对象中的某个属性
（2）原子更新器初始化过程
从上面的例子可以看出，原子更新器是通过newUpdater来获取实例的。其中传入了三个参数，拥有属性的类的Class，属性的Class，属性的名称。初始化过程用到了反射。
8. 原子累加器 （多个cell），底层是LongAddr
9. LongAdder原理
原理之伪共享
缓存行伪共享得从缓存说起
缓存与内存的速度比较
因为 CPU 与 内存的速度差异很大，需要靠预读数据至缓存来提升效率。
而缓存以缓存行为单位，每个缓存行对应着一块内存，一般是 64 byte（8 个 long）
缓存的加入会造成数据副本的产生，即同一份数据会缓存在不同核心的缓存行中
CPU 要保证数据的一致性，如果某个 CPU 核心更改了数据，其它 CPU 核心对应的整个缓存行必须失效
因为 Cell 是数组形式，在内存中是连续存储的，一个 Cell 为 24 字节（16 字节的对象头和 8 字节的 value），因 此缓存行可以存下 2 个的 Cell 对象。这样问题来了：
Core-0 要修改 Cell[0]
Core-1 要修改 Cell[1]
无论谁修改成功，都会导致对方 Core 的缓存行失效，
比如 Core-0 中 Cell[0]=6000, Cell[1]=8000 要累加 Cell[0]=6001, Cell[1]=8000 ，这时会让 Core-1 的缓存行失效
@sun.misc.Contended 用来解决这个问题，它的原理是在使用此注解的对象或字段的前后各增加 128 字节大小的 padding（空白），从而让 CPU 将对象预读至缓存时占用不同的缓存行，这样，不会造成对方缓存行的失效。
10. Unsafe
LongAdder 也是基于 Unsafe 提供的 CAS 操作 +valitale 去实现的。
Unsafe 对象提供了非常底层的，操作内存、线程的方法，Unsafe 对象不能直接调用，只能通过反射获得。
六、共享模型之不可变
1. 不可变
如果一个对象在不能够修改其内部状态（属性），那么它就是线程安全的，因为不存在并发修改。
2. 不可变设计
方法一 final
final 的使用 **
发现该类、类中所有属性都是 **final 的
属性用 final 修饰保证了该属性是只读的，不能修改
类用 final 修饰保证了该类中的方法不能被覆盖，防止子类无意间破坏不可变性
方法二 保护性拷贝
3. 享元模式
- 简介
定义 英文名称：Flyweight pattern. 当需要重用数量有限的同一类对象时
wikipedia： A flyweight is an object that minimizes memory usage by sharing as much data as
possible with other similar objects
出自 "Gang of Four" design patterns
归类 Structual patterns
- 体现
<1>包装类
在JDK中 Boolean，Byte，Short，Integer，Long，Character 等包装类提供了 valueOf 方法，例如 Long 的valueOf 会缓存 -128~127 之间的 Long 对象，在这个范围之间会重用对象，大于这个范围，才会新建 Long 对象
<2>String 串池
<3>BigDecimal BigInteger 大数据类
<4>有限数量的线程池
4. Final 原理
