Java高并发--CPU多级缓存与Java内存模型
主要是学习慕课网实战视频《Java并发编程入门与高并发面试》的笔记
CPU多级缓存
为什么需要CPU缓存：CPU的频率太快，以至于主存跟不上，这样在处理器时钟周期内，CPU常常需要等待主存，浪费了资源。所有缓存的出现是为了缓解CPU和主存之间速度不匹配的问题——将运算所需数据复制到缓存中，使得运算能快速进行；当运算结束后再将缓存同步回内存中，这样处理器无需等待缓慢的内存读写。
缓存并非存储了所有的数据，那么它存在的意义是什么？
- 时间局部性：如果某个数据被访问，那么它在不久的将来有可能被再次访问
- 空间局部性：如果某个数据被访问，那么与它相邻的数据很快可能被访问
Java内存模型
下图中是JVM中堆和栈的关系，在不同的线程中，可能有多个变量，它们指向的是堆上的同一个对象，这些变量都是该对象的“私有拷贝”。私有表示仅在当前线程可访问，拷贝是说这是该对象的一个引用。
线程A和线程B之间如果要通信的话，必须经历以下两个步骤：
- 线程A将本地内存（工作内存）中的变量刷新到主内存中
- 主内存将变量复制到本地内存B中，使得线程B在读取变量时更快
Java内存模型中，所有的变量都存储在主内存中，每条线程还有自己的工作内存（与高速缓存类比），线程对变量的所有操作都必须在工作内存中进行，不能直接读写主内存中的变量；不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需通过主内存完成。
如果将Java内存模型和Java堆、栈比较，主内存对应Java堆中的对象实例部分，工作内存对应虚拟机栈中的部分。
主内存和工作内存之间需要交互，Java内存模型中有8种原子操作：
- lock：作用于主内存变量，将其标识为线程独占。
- unlock：作用于主内存变量，将其从锁定状态释放，释放后才可被其他线程锁定。
- read：作用于主内存的变量，将一个变量从主内存中传输到工作内存中，以便随后的load动作使用。
- load：作用于工作内存中的变量，把read操作从主内存中得到的变量值放入工作内存的变量副本中。
- use：作用于工作内存的变量，把工作内存中的一个变量的值传递给执行引擎，当虚拟机需要使用到变量的值的字节码指令时会执行这个操作。
- assign：作用于工作内存的变量，把一个从执行引擎接受到的值赋给工作内存中的变量。当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
- store：作用于工作内存中的变量，把工作内存中的一个变量的值传送到主内存中，以便之后write操作使用。
- write：作用于主内存中的变量，把store操作从工作内存中得到的变量值放入主内存的变量中。
如果一个变量从主内存复制到工作内存，必须先执行read然后执行load操作（read和load之间允许插入其他操作，只要保证这个顺序即可）；如果要把变量从工作内存同步回主内存中，需要先执行store操作然后执行write操作（store和write之间允许插入其他操作，只要保证这个顺序即可）。
最后来看一个线程不安全的例子
package com.shy.concurrency;
import com.shy.concurrency.annotations.NotThreadSafe;
import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;
/**
* @author Haiyu
* @date 2018/12/16 16:08
*/
@Slf4j
@NotThreadSafe
public class ConcurrencyTest {
// 请求总数
public static int requestTotal = 5000;
// 并发量，同时进入临界区的线程数量
public static int concurrentTotal = 20;
// 计数器
public static int count = 0;
@NotThreadSafe
private static void add() {
count++;
}
public static void main(String[] args) throws InterruptedException {
ExecutorService executorService = Executors.newCachedThreadPool();
// 信号量，控制并发数
final Semaphore semaphore = new Semaphore(concurrentTotal);
// 倒计数器，在这里用来阻塞主线程直到计数器为0
final CountDownLatch countDownLatch = new CountDownLatch(requestTotal);
// requestTotal次请求，每一次请求自增1，按理说最后count的值是requestTotal
// 但是在并发下，多个线程同时执行了add()使得多次自增值只增加了1，导致最后的结果比requestTotal小
for (int i = 0; i < requestTotal; i++) {
executorService.execute(() -> {
try {
semaphore.acquire();
// 最多可同时concurrentTotal个线程同时执行
add();
semaphore.release();
} catch (InterruptedException e) {
log.error("exception", e);
}
// 每自增一次，计数器减1
countDownLatch.countDown();
});
}
// 主线程在countdownLatch上等待，等计数器为0后才能执行
countDownLatch.await();
log.info("count:{}", count);
executorService.shutdown();
}
}
总共发起5000次请求（5000个线程），每次请求对count变量做自增操作。显然在并发下，主线程等5000个线程执行完毕后count一般是小于5000的。原因如下：
以两个线程为例，它们在同一时刻从主内存中读取count的值并装载到各自的工作内存中，此时count的值是一样的，假设都是10。此时线程A先自增，将自增后的值更新到工作内存，最后刷回主内存，count变成了11；而在线程B也进行同样的自增操作，注意之前线程B已经读取过count的值了，此时在B的工作内存中的count还是等于10的，接着B也更新count，最后刷回主内存中，count变成11。也就是说明明执行了两次自增，最后count只增大了1。因此在并发下，多次add可能只会有一次自增。
semaphore信号量用于控制并发量，即同时进入临界区的操作同一个共享资源的线程数。
semaphore.acquire(); // 可以认为是获得锁
// other code
semaphore.release(); // 可以认为是释放了锁
semaphore.acquire()和semaphore.release()之间的代码可以认为是临界区，这里指定了可以同时20个线程进入临界区，换种说法就是并发量是20。
如果将semaphore允许的并发量改成1，那么就相当于任意时刻只能有一个线程执行add操作，5000个线程井然有序的按照先后顺序执行add，不存在同时执行的情况，这种情况下最后的结果总是5000，某种意义上变成了串行。
解决上面的线程不安全问题，除了可以将semaphore的并发量控制为1；还可以使用重入锁，synchronized关键字，原子变量AtomicInteger等。
