第2章 并发编程的其他基础知识

2.1 什么是多线程并发编程

并发：是指同一个时间段内多个任务同时都在执行，并且都没有执行结束。并发任务强调在一个时间段内同时执行，而一个时间段由多个单位时间累积而成，所以说并发的多个任务在单位时间内不一定同时在执行。在单CPU的时代多个任务都是并发执行的，这是因为单个CPU同时只能执行一个任务。在单CPU时代多任务是共享一个CPU的，当一个任务占用CPU运行时，其他任务就会被挂起，当占用CPU的任务时间片用完后，会把CPU让给其他任务来使用，所以在单CPU时代多线程编程是没有太大意义的，并且线程间频繁的上下文切换还会带来额外开销。

并行：是说在单位时间内多个任务同时在执行。

下图为单个CPU上运行两个线程，线程A和线程B是轮流使用CPU进行任务处理的，也就是在某个时间内单个CPU只执行一个线程上面的任务。当线程A的时间片用完后会进行线程上下文切换，也就是保存当前线程A的执行上下文，然后切换到线程B来占用CPU运行任务。

下图为双CPU配置，线程A和线程B各自在自己的CPU上执行任务，实现了真正的并行运行。

在多线程编程实践中，线程的个数往往多于CPU的个数，所以一般都称多线程并发编程而不是多线程并行编程。

2.2 为什么要进行多线程并发编程

(1)多核CPU时代的到来打破了单核CPU对多线程效能的限制。多个CPU意味着每个线程可以使用自己的CPU运行，这减少了线程上下文切换的开销。

(2)随着对应用系统性能和吞吐量要求的提高，出现了处理海量数据和请求的要求，这些都对高并发编程有着迫切的需求。

2.3 Java中的线程安全问题

谈到线程安全问题，我们先说说什么是共享资源。所谓共享资源，就是说该资源被多个线程所持有或者说多个线程都可以去访问该资源。线程安全问题是指当多个线程同时读写一个共享资源并且没有任何同步措施时，导致出现脏数据或者其他不可预见的结果的问题。

2.4 Java中共享变量的内存可见性问题

谈到内存可见性，我们首先来看看在多线程下处理共享变量时Java的内存模型。

Java内存模型规定，将所有的变量都存放在主内存中，当线程使用变量时，会把主内存里面的变量复制到自己的工作空间或者叫作工作内存，线程读写变量时操作的是自己工作内存中的变量。Java内存模型是一个抽象的概念，那么在实际实现中线程的工作内存是什么呢？如下图所示：

图中所示是一个双核CPU系统架构，每个核有自己的控制器和运算器，其中控制器包含一组寄存器和操作控制器，运算器执行算术逻辑运算。每个核都有自己的一级缓存，在有些架构里面还有一个所有CPU都共享的二级缓存。那么Java内存模型里面的工作内存，就对应这里的L1或者L2缓存或者CPU的寄存器。
当一个线程操作共享变量时，它首先从主内存复制共享变量到自己的工作内存，然后对工作内存里的变量进行处理，处理完后将变量值更新到主内存。
那么假如线程A和线程B同时处理一个共享变量，会出现什么情况？我们使用上图所示CPU架构，假设线程A和线程B使用不同CPU执行，并且当前两级Cache都为空，那么这时候由于Cache的存在，将会导致内存不可见问题，具体看下面的分析。

• 线程A首先获取共享变量X的值，由于两级Cache都没有命中，所以加载主内存中X的值，假如为0。然后把X=0的值缓存到两级缓存，线程A修改X的值为1，然后将其写入两级Cache，并且刷新到主内存。线程A操作完毕后，线程A所在的CPU的两级Cache内和主内存里面的X的值都是1。
• 线程B获取X的值，首先一级缓存没有命中，然后看二级缓存，二级缓存命中了，所以返回X= 1；到这里一切都是正常的，因为这时候主内存中也是X=1。然后线程B修改X的值为2，并将其存放到线程2所在的一级Cache和共享二级Cache中，最后更新主内存中X的值为2；到这里一切都是好的。
• 线程A这次又需要修改X的值，获取时一级缓存命中，并且X=1，到这里问题就出现了，明明线程B已经把X的值修改为了2，为何线程A获取的还是1呢？这就是共享变量的内存不可见问题，也就是线程B写入的值对线程A不可见。

使用Java中的volatile关键字可以解决内存不可见问题。

2.5 Java中的synchronized关键字

synchronized块是Java提供的一种原子性内置锁，Java中的每个对象都可以把它当作一个同步锁来使用，这些Java内置的使用者看不到的锁被称为内部锁，也叫作监视器锁。线程的执行代码在进入synchronized代码块前会自动获取内部锁，这时候其他线程访问该同步代码块时会被阻塞挂起。拿到内部锁的线程会在正常退出同步代码块或者抛出异常后或者在同步块内调用了该内置锁资源的wait系列方法时释放该内置锁。内置锁是排它锁，也就是当一个线程获取这个锁后，其他线程必须等待该线程释放锁后才能获取该锁。
另外，由于Java中的线程是与操作系统的原生线程一一对应的，所以当阻塞一个线程时，需要从用户态切换到内核态执行阻塞操作，这是很耗时的操作，而synchronized的使用就会导致上下文切换。

synchronized的一个内存语义可以解决共享变量内存可见性问题。进入synchronized块的内存语义是把在synchronized块内使用到的变量从线程的工作内存中清除，这样在synchronized块内使用到该变量时就不会从线程的工作内存中获取，而是直接从主内存中获取。退出synchronized块的内存语义是把在synchronized块内对共享变量的修改刷新到主内存。
其实这也是加锁和释放锁的语义，当获取锁后会清空锁块内本地内存中将会被用到的共享变量，在使用这些共享变量时从主内存进行加载，在释放锁时将本地内存中修改的共享变量刷新到主内存。除可以解决共享变量内存可见性问题外，synchronized经常被用来实现原子性操作。另外请注意，synchronized关键字会引起线程上下文切换并带来线程调度开销。

2.6 Java中的volatile关键字

使用锁的方式可以解决共享变量内存可见性问题，但是使用锁太笨重，因为它会带来线程上下文的切换开销。对于解决内存可见性问题，Java还提供了一种弱形式的同步，也就是使用volatile关键字。该关键字可以确保对一个变量的更新对其他线程马上可见。当一个变量被声明为volatile时，线程在写入变量时不会把值缓存在寄存器或者其他地方，而是会把值刷新回主内存。当其他线程读取该共享变量时，会从主内存重新获取最新值，而不是使用当前线程的工作内存中的值。

**volatile虽然提供了可见性保证，但并不保证操作的原子性。**那么一般在什么时候才使用volatile关键字呢？

• 写入变量值不依赖变量的当前值时。因为如果依赖当前值，将是获取—计算—写入三步操作，这三步操作不是原子性的，而volatile不保证原子性。
• 读写变量值时没有加锁。因为加锁本身已经保证了内存可见性，这时候不需要把变量声明为volatile的。

2.7 Java中的原子性操作

所谓原子性操作，是指执行一系列操作时，这些操作要么全部执行，要么全部不执行，不存在只执行其中一部分的情况。如果不能保证某个过程是原子性的，那么就会出现线程安全问题。

使用synchronized关键字可以实现线程安全性，即内存可见性和原子性。

2.8 Java中的CAS操作

在Java中，锁在并发处理中占据了一席之地，但是使用锁有一个不好的地方，就是当一个线程没有获取到锁时会被阻塞挂起，这会导致线程上下文的切换和重新调度开销。Java提供了非阻塞的volatile关键字来解决共享变量的可见性问题，这在一定程度上弥补了锁带来的开销问题，但是volatile只能保证共享变量的可见性，不能解决读—改—写等的原子性问题。CAS即Compare and Swap，其是JDK提供的非阻塞原子性操作，它通过硬件保证了比较—更新操作的原子性。JDK里面的Unsafe类提供了一系列的compareAndSwap*方法。

// compareAndSwap的意思是比较并交换。CAS有四个操作数，分别为：对象内存位置、对象中的变量的偏移量、变量预期值和新的值。其操作含义是，如果对象obj中内存偏移量为valueOffset的变量值为expect，则使用新的值update替换旧的值expect。这是处理器提供的一个原子性指令。
boolean compareAndSwapLong（Object obj, long valueOffset, long expect, longupdate

2.9 Unsafe类

2.9.1 Unsafe类中的重要方法

JDK的rt.jar包中的Unsafe类提供了硬件级别的原子性操作，Unsafe类中的方法都是native方法，它们使用JNI的方式访问本地C++ 实现库。下面我们来了解一下Unsafe提供的几个主要的方法以及编程时如何使用Unsafe类做一些事情。

// 返回指定的变量在所属类中的内存偏移地址，该偏移地址仅仅在Unsafe类中的指定函数中访问指定对象时使用。
long objectFieldOffset（Field field）

// 如下代码使用Unsafe类获取变量value在AtomicLong对象中的内存偏移。
static{
    try {
        valueOffset = unsafe.objectFieldOffset(AtomicLong.class.getDeclaredField("value"));
    } catch(Exception ex) {
        throw new Error(ex);
    }
}

字段偏移量
每个对象在内存都有一个内存地址，通过内存地址+类型，我们就可以取出对象的值;对于对象里的字段，也是相似操作。地址的值一般来讲也是比较长的，如果每个对象的字段地址也都是用真实的地址值， 会比较浪费内存;所以Java里采用了字段偏移量来实现，可以理解为相对于对象起始位置的距离，要获取字段的真实地址只需要FieldAddress = ObjectAddress + objectFieldOffset，由于Java里字段又分为类字段(静态的， 跟类相关)和实例字段(非静态， 跟对象相关)， 对于静态字段
StaticFieldAddress = ClassAddress + staticFieldOffset
我们可以通过Unsafe.objectFieldOffset(Field)来获取一个对象的字段偏移量， 通过Unsafe.staticFieldOffset(Field)来获取一个类的字段偏移量

2.9.2 如何使用Unsafe类

// 通过该种方式获得Unsafe实例时会抛出异常，因为在该方法中会获取调用getUnsafe这个方法的对象的Class对象，然后判断是不该类是不是由Bootstrap类加载器进行加载的，如果不是直接抛出异常。因为Unsafe类可以直接操作内存，这是不安全的，所以JDK开发组特意做了这个限制，不让开发人员在正规渠道使用Unsafe类，而是在rt.jar包里面的核心类中使用Unsafe功能。
Unsafe unsafe = Unsafe.getUnsafe();

通过反射来获取Unsafe实例，然后调用其中的方法。

package com.ww.threadApi;

import sun.misc.Unsafe;

import java.lang.reflect.Field;

/**
 * @author: Sun
 * @create: 2020-05-09 11:17
 * @version: v1.0
 */
public class UseUnsafe {

    static Unsafe UNSAFE_INSTANCE;
    static long valueOffset;
    private volatile long value;


    static {
        try {
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            field.setAccessible(true);
            UNSAFE_INSTANCE = (Unsafe) field.get(null);
            valueOffset = UNSAFE_INSTANCE.objectFieldOffset(UseUnsafe.class.getDeclaredField("value"));

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public UseUnsafe(long value) {
        this.value = value;
    }

    @Override
    public String toString() {
        return "UseUnsafe{" +
                "value=" + value +
                '}';
    }

    public static void main(String[] args) {
        UseUnsafe useUnsafe1 = new UseUnsafe(666);
        System.out.println("useUnsafe1:" + UseUnsafe.valueOffset);
        UNSAFE_INSTANCE.compareAndSwapLong(useUnsafe1, UseUnsafe.valueOffset, 666, 66666);
        System.out.println(useUnsafe1);

        UseUnsafe useUnsafe2 = new UseUnsafe(888);
        System.out.println("useUnsafe2:" + UseUnsafe.valueOffset);
        UNSAFE_INSTANCE.compareAndSwapLong(useUnsafe2, UseUnsafe.valueOffset, 888, 88888);
        System.out.println(useUnsafe2);
    }
}

2.10 Java指令重排序

Java内存模型允许编译器和处理器对指令重排序以提高运行性能，并且只会对不存在数据依赖性的指令重排序。在单线程下重排序可以保证最终执行的结果与程序顺序执行的结果一致，但是在多线程下就会存在问题。

重排序在多线程下会导致非预期的程序执行结果，而使用volatile修饰ready就可以避免重排序和内存可见性问题。写volatile变量时，可以确保volatile写之前的操作不会被编译器重排序到volatile写之后。读volatile变量时，可以确保volatile读之后的操作不会被编译器重排序到volatile读之前。

2.11 伪共享

2.11.1 什么是伪共享？

当CPU访问某个变量时，首先会去看CPU Cache内是否有该变量，如果有则直接从中获取，否则就去主内存里面获取该变量，然后把该变量所在内存区域的一个Cache行大小的内存复制到Cache中。由于存放到Cache行的是内存块而不是单个变量，所以可能会把多个变量存放到一个Cache行中。当多个线程同时修改一个Cache行里面的多个变量时，由于同时只能有一个线程操作Cache行，所以相比将每个变量放到一个缓存行，性能会有所下降，这就是伪共享。

2.11.2 为何会出现伪共享?

伪共享的产生是因为多个变量被放入了一个缓存行中，并且多个线程同时去写入同一缓存行中不同的变量。

2.11.3 如何避免伪共享?

在JDK 8之前一般都是通过字节填充的方式来避免该问题，也就是创建一个变量时使用填充字段填充该变量所在的缓存行，这样就避免了将多个变量存放在同一个缓存行中，例如：

/**
 * 假如缓存行为64字节，那么我们在FilledLong类里面填充了6个long类型的变量，每个long类型变量占用8字节，
 * 加上value变量的8字节总共56字节。另外，这里FilledLong是一个类对象，而类对象的字节码的对象头占用8字节，
 * 所以一个FilledLong对象实际会占用64字节的内存，这正好可以放入一个缓存行。
 */
public final class FiledLong{
  public volatile long value = 0L;
  public long p1, p2, p3, p4, p5, p6;
}

JDK 8提供了一个sun.misc.Contended注解，用来解决伪共享问题。该注解可以用来修饰类，也可以修饰变量。需要注意的是，在默认情况下，@Contended注解只用于Java核心类，比如rt包下的类。如果用户类路径下的类需要使用这个注解，则需要添加JVM参数：-XX:-RestrictContended。填充的宽度默认为128，要自定义宽度则可以设置-XX:ContendedPaddingWidth参数。将上面代码修改为如下。

@sun.misc.Contended
public final class FiledLong{ 
	public volatile long value = 0L;
}

2.12 锁的概述

2.12.1 乐观锁与悲观锁

乐观锁和悲观锁是在数据库中引入的名词。

悲观锁指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。悲观锁的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。

// 使用悲观锁来避免多线程同时对一个记录进行修改。
public int updateEntry(long id) {
  // (1)使用悲观锁获取指定记录
  EntryObject entry = query("select * from table1 where id = #{id} for update", id);
  // (2) 修改记录内容，根据计算修改entry记录的属性
  String name = generatorName(entry);
  entry.setName(name);
  // (3) update操作
  int count = update("update table1 set name = #{name}, age = #{age} where id = #{id}", entry);

  return count;
}

对于如上代码，假设updateEntry、query、update方法都使用了事务切面的方法，并且事务传播性被设置为required。执行updateEntry方法时如果上层调用方法里面没有开启事务，则会即时开启一个事务，然后执行代码(1)。代码(1)调用了query方法，其根据指定id从数据库里面查询出一个记录。由于事务传播性为requried，所以执行query时没有开启新的事务，而是加入了updateEntry开启的事务，也就是在updateEntry方法执行完毕提交事务时，query方法才会被提交，就是说记录的锁定会持续到updateEntry执行结束。代码(2)则对获取的记录进行修改，代码(3)把修改的内容写回数据库，同样代码(3)的update方法也没有开启新的事务，而是加入了updateEntry的事务。也就是updateEntry、query、update方法共用同一个事务。

当多个线程同时调用updateEntry方法，并且传递的是同一个id时，只有其中一个线程执行代码(1)会成功，其他线程则会被阻塞，这是因为在同一时间只有一个线程可以获取对应记录的锁，在获取锁的线程释放锁前(updateEntry执行完毕，提交事务前)，其他线程必须等待，也就是在同一时间只有一个线程可以对该记录进行修改。

乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在操作访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。具体来说，根据update返回的行数让用户决定如何去做。

// 将上面的例子改为使用乐观锁的代码如下。
public int updateEntry(long id) {
  // (1)使用乐观锁获取指定记录
  EntryObject entry = query("select * from table1 where id = #{id}", id);
  // (2) 修改记录内容，version字段不能被修改
  String name = generatorName(entry);
  entry.setName(name);
  // (3) update操作
  int count = update("update table1 set name = #{name}, age = #{age}, version = ${version} + 1 where id = #{id} and version = #{version}", entry);

  return count;
}

在如上代码中，当多个线程调用updateEntry方法并且传递相同的id时，多个线程可以同时执行代码(1)获取id对应的记录并把记录放入线程本地栈里面，然后可以同时执行代码(2)对自己栈上的记录进行修改，多个线程修改后各自的entry里面的属性应该都不一样了。然后多个线程可以同时执行代码(3)，代码(3)中的update语句的where条件里面加入了version=#{version}条件，并且set语句中多了version=${version}+1表达式，该表达式的意思是，如果数据库里面id=#{id} and version=#{version}的记录存在，则更新该记录，这有点CAS操作的意思。

假设多个线程同时执行updateEntry并传递相同的id，那么它们执行代码(1)时获取的Entry是同一个，获取的Entry里面的version值都是相同的(这里假设version=0)。当多个线程执行代码(3)时，由于update语句本身是原子性的，假如线程A执行update成功了，那么这时候id对应的记录的version值由原始version值变为了1。其他线程执行代码(3)更新时发现数据库里面已经没有了version=0的语句，所以会返回影响行号0。在业务上根据返回值为0就可以知道当前更新没有成功，那么接下来有两个做法，如果业务发现更新失败了，下面可以什么都不做，也可以选择重试，如果选择重试，则updateEntry的代码可以修改为如下。

// 乐观锁更新失败后重试
public int updateEntry(long id) {
  boolean result = false;
  int retryNum = 5;
  
  while(retryNum > 0) {
    // (1)使用乐观锁获取指定记录
    EntryObject entry = query("select * from table1 where id = #{id}", id);
    // (2) 修改记录内容，version字段不能被修改
    String name = generatorName(entry);
    entry.setName(name);
    // (3) update操作
    int count = update("update table1 set name = #{name}, age = #{age}, version = ${version} + 1 where id = #{id} and version = #{version}", entry);
    if(count == 1) {
      retult = true;
      break;
    }
    
    retryNum--;
  }
  
  return count;
}

如上代码使用retryNum设置更新失败后的重试次数，如果代码(3.1)执行后返回0，则说明代码(1.1)获取的记录已经被修改了，则循环一次，重新通过代码(1.1)获取最新的数据，然后再次执行代码(3.1)尝试更新。这类似CAS的自旋操作，只是这里没有使用死循环，而是指定了尝试次数。

2.12.2 公平锁与非公平锁

根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁，公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的，也就是最早请求锁的线程将最早获取到锁。而非公平锁则在运行时闯入，也就是先来不一定先得。

ReentrantLock提供了公平和非公平锁的实现。

// 公平锁
ReentrantLock pairLock = new ReentrantLock（true）
// 非公平锁 (如果构造函数不传递参数，则默认是非公平锁。)
ReentrantLock pairLock = new ReentrantLock（false）

例如，假设线程A已经持有了锁，这时候线程B请求该锁其将会被挂起。当线程A释放锁后，假如当前有线程C也需要获取该锁，如果采用非公平锁方式，则根据线程调度策略，线程B和线程C两者之一可能获取锁，这时候不需要任何其他干涉，而如果使用公平锁则需要把C挂起，让B获取当前锁。

2.12.3 独占锁与共享锁

根据锁只能被单个线程持有还是能被多个线程共同持有，锁可以分为独占锁和共享锁。

独占锁保证任何时候都只有一个线程能得到锁，ReentrantLock就是以独占方式实现的。共享锁则可以同时由多个线程持有，例如ReadWriteLock读写锁，它允许一个资源可以被多线程同时进行读操作。独占锁是一种悲观锁，由于每次访问资源都先加上互斥锁，这限制了并发性，因为读操作并不会影响数据的一致性，而独占锁只允许在同一时间由一个线程读取数据，其他线程必须等待当前线程释放锁才能进行读取。共享锁则是一种乐观锁，它放宽了加锁的条件，允许多个线程同时进行读操作。

2.12.4 什么是可重入锁

当一个线程要获取一个被其他线程持有的独占锁时，该线程会被阻塞；当一个线程再次获取它自己已经获取的锁时如果不被阻塞，那么我们说该锁是可重入的。也就是只要该线程获取了该锁，那么可以无限次数(严格来说是有限次数)地进入被该锁锁住的代码。

下面看一个例子，看看在什么情况下会使用可重入锁。

public class Hello {
  public synchronized void helloA() {
    System.out.println("helloA");
  }
  public synchronized void helloB() {
    System.out.println("helloB");
    helloA();
  }  
}

在如上代码中，调用helloB方法前会先获取内置锁，然后打印输出。之后调用helloA方法，在调用前会先去获取内置锁，如果内置锁不是可重入的，那么调用线程将会一直被阻塞。

实际上，synchronized内部锁是可重入锁。可重入锁的原理是在锁内部维护一个线程标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为0，说明该锁没有被任何线程占用。当一个线程获取了该锁时，线程标识填充为当前线程并且计数器的值会变成1，这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加+1，当释放锁后计数器值-1。当计数器值为0时，锁里面的线程标示被重置为null，这时候被阻塞的线程会被唤醒来竞争获取该锁。

2.12.5 自旋锁

由于Java中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁(比如独占锁)失败后，会被切换到内核状态而被挂起。当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU使用权的情况下，多次尝试获取(默认次数是10，可以使用-XX:PreBlockSpinsh参数设置该值)，很有可能在后面几次尝试中其他线程已经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用CPU时间换取线程阻塞与调度的开销，但是很有可能这些CPU时间白白浪费了。