Java高并发--CPU多级缓存与Java内存模型

Java高并发--CPU多级缓存与Java内存模型

主要是学习慕课网实战视频《Java并发编程入门与高并发面试》的笔记

CPU多级缓存

为什么需要CPU缓存:CPU的频率太快,以至于主存跟不上,这样在处理器时钟周期内,CPU常常需要等待主存,浪费了资源。所有缓存的出现是为了缓解CPU和主存之间速度不匹配的问题——将运算所需数据复制到缓存中,使得运算能快速进行;当运算结束后再将缓存同步回内存中,这样处理器无需等待缓慢的内存读写。

image

缓存并非存储了所有的数据,那么它存在的意义是什么?

  • 时间局部性:如果某个数据被访问,那么它在不久的将来有可能被再次访问
  • 空间局部性:如果某个数据被访问,那么与它相邻的数据很快可能被访问

Java内存模型

下图中是JVM中堆和栈的关系,在不同的线程中,可能有多个变量,它们指向的是堆上的同一个对象,这些变量都是该对象的“私有拷贝”。私有表示仅在当前线程可访问,拷贝是说这是该对象的一个引用。

image

线程A和线程B之间如果要通信的话,必须经历以下两个步骤:

  • 线程A将本地内存(工作内存)中的变量刷新到主内存中
  • 主内存将变量复制到本地内存B中,使得线程B在读取变量时更快
image

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之间允许插入其他操作,只要保证这个顺序即可)。

image

最后来看一个线程不安全的例子

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等。

推荐阅读更多精彩内容