Java高并发编程详解学习笔记（五）

桃扇骨 2022-12-07 04:29 236阅读 0赞

前言：要秋招了，复习一下应对秋招，纠结该先看啥，最后决定先学习《Java高并发编程详解》，此博客为看书所写的笔记，因为是笔记，所以会只记比较重要的东西，**不适合初学者。**

**参考：**

https://www.jianshu.com/p/ab2c8fce878b

[https://blog.csdn.net/u010862794/article/details/72892300][https_blog.csdn.net_u010862794_article_details_72892300]

[https://www.cnblogs.com/waterystone/p/4920797.html][https_www.cnblogs.com_waterystone_p_4920797.html]

[https://www.cnblogs.com/fengzheng/p/9153720.html][https_www.cnblogs.com_fengzheng_p_9153720.html]

**目录**

第一章 volatile关键字介绍

1.1 机器硬件CPU

1.1.1 缓存一致性的问题

1.2 Java内存模型

第二章 深入volatile关键字

2.1 并发编程的三个重要特性

2.1.1 原子性

2.1.2 可见性

2.1.3 有序性

2.2 JMM如何保证三大特性

2.2.1 原子性

2.2.2 可见性

2.2.3 有序性

2.3 volatile关键字深入解析

2.3.1 volatile关键字的语义

2.3.2 volatile的原理和实现机制

2.3.3 volatile的使用场景

第三章 CAS

3.1 CAS典型应用

第四章 AQS

--------------------

# 第一章 volatile关键字介绍 #

当开启两个线程同时操作某个数据时，一个对线程对数据进行读操作，一个对数据进行写操作，一个线程可能会感知不到另一个线程对数据做的修改，即在一个线程中修改某个数的值，另一个线程感知不到。这样是为什么呢，可以看下面的解释。

## 1.1 机器硬件CPU ##

在计算机中，所有的运算操作都是由CPU的寄存器来完成的，CPU指令的执行过程需要涉及数据的读取和写入操作，CPU所能访问的所有数据只能是计算机的主存，虽然CPU的发展频率不断地得到提升，但受制于制造工艺以及成本等的限制，计算机内存的访问速度倒是没有多大的突破.因此CPU的处理速度和内存的访问速度之间的差距越拉越大，通常这种差距可以达到上千倍。

于是就有了在CPU和主内存之间增加缓存的涉及，现在的缓存数量已经加到3级了，最靠近CPU的缓存称为L1，然后依次是L2，L3，然后是主内存。

缓存的出现是为了解决CPU直接访问内存效率低下的问题，程序在运行的过程中，会将运算所需的数据从主存复制一份到CPU 缓存中，这样CPU进行计算的时候就可以直接对缓存中的数据进行读取和写入，当运算结束后，再将CPU Cache中的最新数据刷新到主内存当中，有了缓存之后，极大的提高了CPU的吞吐能力。

### 1.1.1 缓存一致性的问题 ###

当两个线程都对主存中的变量i=1进行加1操作，因为每个线程都有自己的工作内存，所以变量i会在多个线程的本地内存中都存有一个副本，线程本地内存中进行加1操作后，再写入主内存中，可能写入的都是2，这就是典型的缓存不一致问题。

为了解决缓存不一致性问题，通常主流的方法有两种：

1.通过总线加锁的方式

第一种常见于早期的CPU当中，而且是一种悲观的实现方式，CPU和其他组件的通信通过总线来进行的，如果采用总线加锁的方式，则会阻塞其它CPU对其他组件的访问，从而使得只有一个CPU（抢到总线锁）能够访问这个变量的内存。

2.通过缓存一致性协议

其中最出名的是Intel的MESI协议，MESI协议保证了每一个缓存中使用的共享变量副本都是一致的，它的大致思想是：当CPU在操作缓存中的数据时，如果发现该变量是一个共享变量，也就是在其它的缓存中也有一个副本，那么进行如下操作

（1）读取操作，不做任何处理，只是将Cache中的数据读取到寄存器。

（2）写入操作，发出信号通知其他CPU将该变量的缓存置为无效状态，其它CPU在进行该变量读取的时候不得不到主内存中再次获取。

## 1.2 Java内存模型 ##

JMM制定了Java虚拟机如何与计算机的主存进行工作，JMM决定了一个线程对共享变量的写入何时对其他线程可见，Java内存模型定义了线程和主内存之间的抽象关系，具体如下：

共享变量存储于主内存之中，每个线程都可以访问。

每个线程都私有的工作内存称为本地内存。

工作内存只能存储该线程对共享变量的副本。

线程不能直接操作主内存，只有先操作了工作内存之后才能写入主内存。

工作内存和Java内存模型一样也是一个抽象的概念，它其实并不存在，它涵盖了缓存、寄存器、编译器优化以及硬件等。

假设主内存的共享变量是0，线程1和线程2分别拥有共享变量X的副本，假设线程1此时将工作内存中的X修改为1，同时刷新到主内存中，当线程2想要去使用副本x的时候，就会发现该变量已经失效了，必须到主内存中再次获取然后存入自己的工作内存之中，这一点和CPU与缓存之间的关系十分相似。

# 第二章 深入volatile关键字 #

## 2.1 并发编程的三个重要特性 ##

### 2.1.1 原子性 ###

指在一次或者多次操作中，要么所有的操作全部得到了执行并且不会受到任何因素的干扰而中断，要么所有的操作都不执行。

两个原子性的操作在一起未必还是原子性的，比如i++(其中get i ,i+1,和set i=x,三者都是原子性操作，但是不代表i++就是原子性操作)

volatile不保证数据的原子性，synchronized关键字保证。

### 2.1.2 可见性 ###

可见性是指，当一个线程对共享变量做了修改，那么另外的线程可以立即看到修改后的最新值。

### 2.1.3 有序性 ###

所谓有序性指的是代码在执行过程中的先后顺序，由于java在编译器以及运行期间的优化，导致了代码的执行顺序未必就是开发者编写代码时的顺序。

如

int x = 10;

int y = 0;

x++;

y=20;

上面这段代码定义了两个int类型的变量x和y，对x进行自增操作，对y进行赋值操作，从编写程序的角度来看上面的代码肯定是顺序执行下来的，但是JVM真正运行这段代码的时候未必会是这样的，比如y=20可能会在x++语句的前面得到执行，这种情况是我们通常所说的指令重排序。

在单线程情况下，无论怎样的重排序都会保证程序的执行结

果和代码顺序执行的结果是完全一致的，但是在多线程情况下，如果有序性得不到保证，那么很有可能就会出现非常大的问题。

## 2.2 JMM如何保证三大特性 ##

### 2.2.1 原子性 ###

对基本数据类型的变量读取赋值操作都是原子性的，对引用类型的变量读取和赋值的操作也是原子性的，因此诸如此类的操作是不可中断的，要么执行，要么不执行，要想使某些代码片段具备原子性，需要使用关键字synchronized，volatile不具备原子性。

### 2.2.2 可见性 ###

如果某个线程首次读取共享变量，则首先到主内存中获取该变量，然后存入工作内存中，以后只需要在工作内存中读取该变量即可，如果对该变量执行了修改的操作，则先将新值写入工作内存，然后再刷新至主内存中，但是什么时候刷新至主内存中是不太确定的。

Java提供了三种方式来保证可见性

使用volatile，当一个变量被volatile关键字修饰时，对于共享资源的读操作会直接在主内存中进行（当然也会缓存到工作内存中，当其他线程对该共享资源进行了修改，会导致当前线程在工作内存中的共享资源失效，所以必须从主内存中再次获取），对于共享资源的写操作当然是先要修改工作内存，但是修改结束后会立刻将其刷新到主内存中。

通过synchronized关键字能够保证可见性，synchronized能够保证同一时刻只有一个线程获得锁，然后执行同步方法，并且会确保在释放锁之前，会将对变量的修改刷新到主内存中。

通过JUC提供的显示锁Lock也能够保证可见性，具体机制和synchronized差不多。

volatile具有保证可见性的语义。

### 2.2.3 有序性 ###

在java内存模型中，允许编译器和处理器对指令进行重排，在单线程情况下，没什么问题，但是在多线程情况下，重排序会影响到程序的正确运行。

Java提供了三种保证有序性的方式，具体如下：

使用volatile关键字来保证有序性

使用synchronized关键字来保证有序性

使用显示锁lock来保证有序性

synchronized与显示锁lock都是把程序变成单线程的，自然是没有问题。

volatile直接禁止JVM和处理器对volatile涉及到的关键指令重排，也实现了有序性。

此外，Java内存模型具备一些天生的有序性规则，不需要任何同步手段就能够保证有序性，这个规则被称为happens-before原则，如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就无法保证有序性，也就是说虚拟机或者处理器可以随意对它们进行重排序处理。

具体的happens-before原则这里不再赘述，可以看这里。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70][]

## 2.3 volatile关键字深入解析 ##

### 2.3.1 volatile关键字的语义 ###

理解可见性;

reader线程从主内存中获取init\_value的值为0，并且缓存到本地工作内存中。

update线程将init\_value的值在本地工作内存中修改为1，然后立即刷新到主内存中。

reader线程在本地工作内存中的init\_value失效（反应到硬件上就是CPU的L1或L2的Cache Line失效）。

由于Reader线程工作内存中的init\_value失效，因此需要到主内存中重新读取init\_value的值。

理解保证顺序性：

volatile直接禁止JVM和处理器对volatile涉及到的关键指令重排，也实现了有序性。

### 2.3.2 volatile的原理和实现机制 ###

打开unsafe.cpp的源码阅读，会发现被volatile修改的变量存在于一个lcock的前缀。

lock相当于一个内存屏障，该内存屏障会为指令的执行提供如下几个保证。

确保指令重排序时不会将其后面的代码排到内存屏障之前。

确保指令重排序时不会将其前面的代码排到内存屏障之后。

确保在执行到内存屏障时前面的代码全部完成。

强制将线程工作内存中的值刷新至主内存中。

如果是写操作，则会导致其他线程工作内存中的缓存数据失效。

### 2.3.3 volatile的使用场景 ###

作为开关控制器。

状态标记利用顺序性。

# 第三章 CAS #

CAS：Compare and Swap，即比较再交换。

jdk5增加了并发包java.util.concurrent.\*,其下面的类使用CAS算法实现了区别于synchronouse同步锁的一种乐观锁。JDK 5之前Java语言是靠synchronized关键字保证同步的，这是一种独占锁，也是是悲观锁

CAS（比较并交换）是CPU指令级的操作，只有一步原子操作，所以非常快

例子：

t1，t2线程是同时更新同一变量56的值

因为t1和t2线程都同时去访问同一变量56，所以他们会把主内存的值完全拷贝一份到自己的工作内存空间，所以t1和t2线程的预期值都为56。

假设t1在与t2线程竞争中线程t1能去更新变量的值，而其他线程都失败。（失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次发起尝试）。t1线程去更新变量值改为57，然后写到内存中。此时对于t2来说，内存值变为了57，与预期值56不一致，就操作失败了（想改的值不再是原来的值）。

就是指当两者进行比较时，如果相等，则证明共享数据没有被修改，替换成新值，然后继续往下运行；如果不相等，说明共享数据已经被修改，放弃已经所做的操作，然后重新执行刚才的操作。

## 3.1 CAS典型应用 ##

可以看到下面是AtomicInteger的源码，compareAndSet为CAS操作，当需要更新值时调用getAndSet函数，会不断的进行比较，直到与与预期值相等时再进行修改，不然会一直循环。

public class AtomicInteger extends Number implements java.io.Serializable {
        private static final long serialVersionUID = 6214790243416807050L;
    
        // setup to use Unsafe.compareAndSwapInt for updates
        private static final Unsafe unsafe = Unsafe.getUnsafe();
    
        private volatile int value;// 初始int大小
        // 省略了部分代码...
    
        // 带参数构造函数，可设置初始int大小
        public AtomicInteger(int initialValue) {
            value = initialValue;
        }
        // 不带参数构造函数,初始int大小为0
        public AtomicInteger() {
        }
    
        // 获取当前值
        public final int get() {
            return value;
        }
    
        // 设置值为 newValue
        public final void set(int newValue) {
            value = newValue;
        }
    
        //返回旧值，并设置新值为　newValue
        public final int getAndSet(int newValue) {
            /**
            * 这里使用for循环不断通过CAS操作来设置新值
            * CAS实现和加锁实现的关系有点类似乐观锁和悲观锁的关系
            * */
            for (;;) {
                int current = get();
                if (compareAndSet(current, newValue))
                    return current;
            }
        }
    
        // 原子的设置新值为update, expect为期望的当前的值
        public final boolean compareAndSet(int expect, int update) {
            return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
        }
    
        // 获取当前值current，并设置新值为current+1
        public final int getAndIncrement() {
            for (;;) {
                int current = get();
                int next = current + 1;
                if (compareAndSet(current, next))
                    return current;
            }
        }
    
        // 此处省略部分代码，余下的代码大致实现原理都是类似的
    }

# 第四章 AQS #

网上参考了半天别人的博客，说一下自己的理解。

AQS是一个框架，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch.

框架内维护了一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。

![format_png][]

框架还提供了一些供我们自己实现的方法

*  isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。
 *  tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。
 *  tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。
 *  tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
 *  tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回false。

那这个框架的具体流程是怎样的呢？

比如我要获取共享资源调用tryAcquire方法，当能获取成功时（即返回true），执行我们的线程，当不成功时，将调用tryAcquire的线程加入到我们上面的队列中并阻塞，直到tryRelease方法调用后，等待队列里的下一个线程会被唤醒，然后被执行，如果下一个线程执行了完了，下下个线程会被唤醒执行。

所以这里需要我们自己定义获取资源tryAcquire和释放资源tryRelease的方式，这样我们的线程就能根据我们自己定义的方式来进行阻塞或者运行了。

这里有一个CountDownLatch实现AQS的源码讲解，写的不错，可以看看

[https://www.cnblogs.com/fengzheng/p/9153720.html][https_www.cnblogs.com_fengzheng_p_9153720.html]

[https_blog.csdn.net_u010862794_article_details_72892300]: https://blog.csdn.net/u010862794/article/details/72892300
[https_www.cnblogs.com_waterystone_p_4920797.html]: https://www.cnblogs.com/waterystone/p/4920797.html
[https_www.cnblogs.com_fengzheng_p_9153720.html]: https://www.cnblogs.com/fengzheng/p/9153720.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70]: /images/20221123/b142cd7f109548a28a21a52f97ede61a.png
[format_png]: /images/20221123/63dd773373334ad99cf78dc57173f882.png