第2章 并发编程的其他基础知识
2.1 什么是多线程并发编程
首先要澄清并发和并行的概念，并发是指同一个时间段内多个任务同时都在执行，并且都没有执行结束，而并行是说在单位时间内多个任务同时在执行。并发任务强调在一个时间段内同时执行，而一个时间段由多个单位时间累积而成，所以说并发的多个任务在单位时间内不一定同时在执行。在单CPU的时代多个任务都是并发执行的，这是因为单个CPU同时只能执行一个任务。在单CPU时代多任务是共享一个CPU的，当一个任务占用CPU运行时，其他任务就会被挂起，当占用CPU的任务时间片用完后，会把CPU让给其他任务来使用，所以在单CPU时代多线程编程是没有太大意义的，并且线程间频繁的上下文切换还会带来额外开销。
图2-1所示为在单个CPU上运行两个线程，线程A和线程B是轮流使用CPU进行任务处理的，也就是在某个时间内单个CPU只执行一个线程上面的任务。当线程A的时间片用完后会进行线程上下文切换，也就是保存当前线程A的执行上下文，然后切换到线程B来占用CPU运行任务。
图2-1
图2-2所示为双CPU配置，线程A和线程B各自在自己的CPU上执行任务，实现了真正的并行运行。
图2-2
而在多线程编程实践中，线程的个数往往多于CPU的个数，所以一般都称多线程并发编程而不是多线程并行编程。
2.2 为什么要进行多线程并发编程
多核CPU时代的到来打破了单核CPU对多线程效能的限制。多个CPU意味着每个线程可以使用自己的CPU运行，这减少了线程上下文切换的开销，但随着对应用系统性能和吞吐量要求的提高，出现了处理海量数据和请求的要求，这些都对高并发编程有着迫切的需求。
2.3 Java中的线程安全问题
谈到线程安全问题，我们先说说什么是共享资源。所谓共享资源，就是说该资源被多个线程所持有或者说多个线程都可以去访问该资源。
线程安全问题是指当多个线程同时读写一个共享资源并且没有任何同步措施时，导致出现脏数据或者其他不可预见的结果的问题，如图2-3所示。
图2-3
在图2-3中，线程A和线程B可以同时操作主内存中的共享变量，那么线程安全问题和共享资源之间是什么关系呢？是不是说多个线程共享了资源，当它们都去访问这个共享资源时就会产生线程安全问题呢？答案是否定的，如果多个线程都只是读取共享资源，而不去修改，那么就不会存在线程安全问题，只有当至少一个线程修改共享资源时才会存在线程安全问题。最典型的就是计数器类的实现，计数变量count本身是一个共享变量，多个线程可以对其进行递增操作，如果不使用同步措施，由于递增操作是获取—计算—保存三步操作，因此可能导致计数不准确，如下所示。
假如当前count=0，在t1时刻线程A读取count值到本地变量countA。然后在t2时刻递增countA的值为1，同时线程B读取count的值0到本地变量countB，此时countB的值为0（因为countA的值还没有被写入主内存）。在t3时刻线程A才把countA的值1写入主内存，至此线程A一次计数完毕，同时线程B递增CountB的值为1。在t4时刻线程B把countB的值1写入内存，至此线程B一次计数完毕。这里先不考虑内存可见性问题，明明是两次计数，为何最后结果是1而不是2呢？其实这就是共享变量的线程安全问题。那么如何来解决这个问题呢？这就需要在线程访问共享变量时进行适当的同步，在Java中最常见的是使用关键字synchronized进行同步，下面会有具体介绍。
2.4 Java中共享变量的内存可见性问题
谈到内存可见性，我们首先来看看在多线程下处理共享变量时Java的内存模型，如图2-4所示。
图2-4
Java内存模型规定，将所有的变量都存放在主内存中，当线程使用变量时，会把主内存里面的变量复制到自己的工作空间或者叫作工作内存，线程读写变量时操作的是自己工作内存中的变量。Java内存模型是一个抽象的概念，那么在实际实现中线程的工作内存是什么呢？请看图2-5。
图2-5
图中所示是一个双核CPU系统架构，每个核有自己的控制器和运算器，其中控制器包含一组寄存器和操作控制器，运算器执行算术逻辑运算。每个核都有自己的一级缓存，在有些架构里面还有一个所有CPU都共享的二级缓存。那么Java内存模型里面的工作内存，就对应这里的L1或者L2缓存或者CPU的寄存器。
当一个线程操作共享变量时，它首先从主内存复制共享变量到自己的工作内存，然后对工作内存里的变量进行处理，处理完后将变量值更新到主内存。
那么假如线程A和线程B同时处理一个共享变量，会出现什么情况？我们使用图2-5所示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关键字
2.5.1 synchronized关键字介绍
synchronized块是Java提供的一种原子性内置锁，Java中的每个对象都可以把它当作一个同步锁来使用，这些Java内置的使用者看不到的锁被称为内部锁，也叫作监视器锁。线程的执行代码在进入synchronized代码块前会自动获取内部锁，这时候其他线程访问该同步代码块时会被阻塞挂起。拿到内部锁的线程会在正常退出同步代码块或者抛出异常后或者在同步块内调用了该内置锁资源的wait系列方法时释放该内置锁。内置锁是排它锁，也就是当一个线程获取这个锁后，其他线程必须等待该线程释放锁后才能获取该锁。
另外，由于Java中的线程是与操作系统的原生线程一一对应的，所以当阻塞一个线程时，需要从用户态切换到内核态执行阻塞操作，这是很耗时的操作，而synchronized的使用就会导致上下文切换。
2.5.0 synchronized的内存语义
前面介绍了共享变量内存可见性问题主要是由于线程的工作内存导致的，下面我们来讲解synchronized的一个内存语义，这个内存语义就可以解决共享变量内存可见性问题。进入synchronized块的内存语义是把在synchronized块内使用到的变量从线程的工作内存中清除，这样在synchronized块内使用到该变量时就不会从线程的工作内存中获取，而是直接从主内存中获取。退出synchronized块的内存语义是把在synchronized块内对共享变量的修改刷新到主内存。
其实这也是加锁和释放锁的语义，当获取锁后会清空锁块内本地内存中将会被用到的共享变量，在使用这些共享变量时从主内存进行加载，在释放锁时将本地内存中修改的共享变量刷新到主内存。
除可以解决共享变量内存可见性问题外，synchronized经常被用来实现原子性操作。另外请注意，synchronized关键字会引起线程上下文切换并带来线程调度开销。
2.6 Java中volatile关键字
上面介绍了使用锁的方式可以解决共享变量内存可见性问题，但是使用锁太笨重，因为它会带来线程上下文的切换开销。对于解决内存可见性问题，Java还提供了一种弱形式的同步，也就是使用volatile关键字。该关键字可以确保对一个变量的更新对其他线程马上可见。当一个变量被声明为volatile时，线程在写入变量时不会把值缓存在寄存器或者其他地方，而是会把值刷新回主内存。当其他线程读取该共享变量时，会从主内存重新获取最新值，而不是使用当前线程的工作内存中的值。volatile的内存语义和synchronized有相似之处，具体来说就是，当线程写入了volatile变量值时就等价于线程退出synchronized同步块（把写入工作内存的变量值同步到主内存），读取volatile变量值时就相当于进入同步块（先清空本地内存变量值，再从主内存获取最新值）。
下面看一个使用volatile关键字解决内存可见性问题的例子。如下代码中的共享变量value是线程不安全的，因为这里没有使用适当的同步措施。
public class ThreadNotSafeInteger {
private int value;
public int get() {
return value;
}
public void set(int value) {
this.value = value;
}
}
首先来看使用synchronized关键字进行同步的方式。
public class ThreadSafeInteger {
private int value;
public synchronized int get() {
return value;
}
public synchronized void set(int value) {
this.value = value;
}
}
然后是使用volatile进行同步。
public class ThreadSafeInteger {
private volatile int value;
public int get() {
return value;
}
public void set(int value) {
this.value = value;
}
} 在这里使用synchronized和使用volatile是等价的，都解决了共享变量value的内存可见性问题，但是前者是独占锁，同时只能有一个线程调用get（）方法，其他调用线程会被阻塞，同时会存在线程上下文切换和线程重新调度的开销，这也是使用锁方式不好的地方。而后者是非阻塞算法，不会造成线程上下文切换的开销。
但并非在所有情况下使用它们都是等价的，volatile虽然提供了可见性保证，但并不保证操作的原子性。
那么一般在什么时候才使用volatile关键字呢？
● 写入变量值不依赖变量的当前值时。因为如果依赖当前值，将是获取—计算—写入三步操作，这三步操作不是原子性的，而volatile不保证原子性。
● 读写变量值时没有加锁。因为加锁本身已经保证了内存可见性，这时候不需要把变量声明为volatile的。
2.7 Java中的原子性操作
所谓原子性操作，是指执行一系列操作时，这些操作要么全部执行，要么全部不执行，不存在只执行其中一部分的情况。在设计计数器时一般都先读取当前值，然后+1，再更新。这个过程是读—改—写的过程，如果不能保证这个过程是原子性的，那么就会出现线程安全问题。如下代码是线程不安全的，因为不能保证++value是原子性操作。
public class ThreadNotSafeCount {
private Long value;
public Long getCount() {
return value;
}
public void inc() {
++value;
}
}
使用Javap -c命令查看汇编代码，如下所示。
public void inc();
Code:
0: aload_0
1: dup
2: getfield #2 // Field value:J
5: lconst_1
6: ladd
7: putfield #2 // Field value:J
10: return 由此可见，简单的++value由2、5、6、7四步组成，其中第2步是获取当前value的值并放入栈顶，第5步把常量1放入栈顶，第6步把当前栈顶中两个值相加并把结果放入栈顶，第7步则把栈顶的结果赋给value变量。因此，Java中简单的一句++value被转换为汇编后就不具有原子性了。
那么如何才能保证多个操作的原子性呢？最简单的方法就是使用synchronized关键字进行同步，修改代码如下。
public class ThreadSafeCount {
private Long value;
public synchronized Long getCount() {
return value;
}
public synchronized void inc() {
++value;
}
}使用synchronized关键字的确可以实现线程安全性，即内存可见性和原子性，但是synchronized是独占锁，没有获取内部锁的线程会被阻塞掉，而这里的getCount方法只是读操作，多个线程同时调用不会存在线程安全问题。但是加了关键字synchronized后，同一时间就只能有一个线程可以调用，这显然大大降低了并发性。你也许会问，既然是只读操作，那为何不去掉getCount方法上的synchronized关键字呢？其实是不能去掉的，别忘了这里要靠synchronized来实现value的内存可见性。那么有没有更好的实现呢？答案是肯定的，下面将讲到的在内部使用非阻塞CAS算法实现的原子性操作类AtomicLong就是一个不错的选择。
2.8 Java中的CAS操作
在Java中，锁在并发处理中占据了一席之地，但是使用锁有一个不好的地方，就是当一个线程没有获取到锁时会被阻塞挂起，这会导致线程上下文的切换和重新调度开销。Java提供了非阻塞的volatile关键字来解决共享变量的可见性问题，这在一定程度上弥补了锁带来的开销问题，但是volatile只能保证共享变量的可见性，不能解决读—改—写等的原子性问题。CAS即Compare and Swap，其是JDK提供的非阻塞原子性操作，它通过硬件保证了比较—更新操作的原子性。JDK里面的Unsafe类提供了一系列的compareAndSwap*方法，下面以compareAndSwapLong方法为例进行简单介绍。
● boolean compareAndSwapLong（Object obj, long valueOffset, long expect, long update）方法：其中compareAndSwap的意思是比较并交换。CAS有四个操作数，分别为：对象内存位置、对象中的变量的偏移量、变量预期值和新的值。其操作含义是，如果对象obj中内存偏移量为valueOffset的变量值为expect，则使用新的值update替换旧的值expect。这是处理器提供的一个原子性指令。
关于CAS操作有个经典的ABA问题，具体如下：假如线程I使用CAS修改初始值为A的变量X，那么线程I会首先去获取当前变量X的值（为A），然后使用CAS操作尝试修改X的值为B，如果使用CAS操作成功了，那么程序运行一定是正确的吗？其实未必，这是因为有可能在线程I获取变量X的值A后，在执行CAS前，线程II使用CAS修改了变量X的值为B，然后又使用CAS修改了变量X的值为A。所以虽然线程I执行CAS时X的值是A，但是这个A已经不是线程I获取时的A了。这就是ABA问题。
ABA问题的产生是因为变量的状态值产生了环形转换，就是变量的值可以从A到B，然后再从B到A。如果变量的值只能朝着一个方向转换，比如A到B, B到C，不构成环形，就不会存在问题。JDK中的AtomicStampedReference类给每个变量的状态值都配备了一个时间戳，从而避免了ABA问题的产生。
2.9 Unsafe类
2.9.1 Unsafe类中的重要方法
JDK的rt.jar包中的Unsafe类提供了硬件级别的原子性操作，Unsafe类中的方法都是native方法，它们使用JNI的方式访问本地C++ 实现库。下面我们来了解一下Unsafe提供的几个主要的方法以及编程时如何使用Unsafe类做一些事情。
● long objectFieldOffset（Field field）方法：返回指定的变量在所属类中的内存偏移地址，该偏移地址仅仅在该Unsafe函数中访问指定字段时使用。如下代码使用Unsafe类获取变量value在AtomicLong对象中的内存偏移。
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicLong.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
● int arrayBaseOffset（Class arrayClass）方法：获取数组中第一个元素的地址。
● int arrayIndexScale（Class arrayClass）方法：获取数组中一个元素占用的字节。
● boolean compareAndSwapLong（Object obj, long offset, long expect, long update）方法：比较对象obj中偏移量为offset的变量的值是否与expect相等，相等则使用update值更新，然后返回true，否则返回false。
● public native long getLongvolatile（Object obj, long offset）方法：获取对象obj中偏移量为offset的变量对应volatile语义的值。
● void putLongvolatile（Object obj, long offset, long value）方法：设置obj对象中offset偏移的类型为long的field的值为value，支持volatile语义。
● void putOrderedLong（Object obj, long offset, long value）方法：设置obj对象中offset偏移地址对应的long型field的值为value。这是一个有延迟的putLongvolatile方法，并且不保证值修改对其他线程立刻可见。只有在变量使用volatile修饰并且预计会被意外修改时才使用该方法。
● void park（boolean isAbsolute, long time）方法：阻塞当前线程，其中参数isAbsolute等于false且time等于0表示一直阻塞。time大于0表示等待指定的time后阻塞线程会被唤醒，这个time是个相对值，是个增量值，也就是相对当前时间累加time后当前线程就会被唤醒。如果isAbsolute等于true，并且time大于0，则表示阻塞的线程到指定的时间点后会被唤醒，这里time是个绝对时间，是将某个时间点换算为ms后的值。另外，当其他线程调用了当前阻塞线程的interrupt方法而中断了当前线程时，当前线程也会返回，而当其他线程调用了unPark方法并且把当前线程作为参数时当前线程也会返回。
● void unpark（Object thread）方法：唤醒调用park后阻塞的线程。
下面是JDK8新增的函数，这里只列出Long类型操作。
● long getAndSetLong（Object obj, long offset, long update）方法：获取对象obj中偏移量为offset的变量volatile语义的当前值，并设置变量volatile语义的值为update。
public final long getAndSetLong(Object obj, long offset, long update) {
long l;
do{
l = getLongvolatile(obj, offset); //(1)
} while (! compareAndSwapLong(obj, offset, l, update));
return l;
} 由以上代码可知，首先（1）处的getLongvolatile获取当前变量的值，然后使用CAS原子操作设置新值。这里使用while循环是考虑到，在多个线程同时调用的情况下CAS失败时需要重试。
● long getAndAddLong（Object obj, long offset, long addValue）方法：获取对象obj中偏移量为offset的变量volatile语义的当前值，并设置变量值为原始值+addValue。
public final long getAndAddLong(Object obj, long offset, long addValue){
long l;
do{
l = getLongvolatile(obj, offset);
} while (! compareAndSwapLong(obj, offset, l, l + addValue));
return l;
}类似getAndSetLong的实现，只是这里进行CAS操作时使用了原始值+传递的增量参数addValue的值。
2.9.2 如何使用Unsafe类
看到Unsafe这个类如此厉害，你肯定会忍不住试一下下面的代码，期望能够使用Unsafe做点事情。
public class TestUnSafe {
//获取Unsafe的实例（2.2.1）
static final Unsafe unsafe = Unsafe.getUnsafe();
//记录变量state在类TestUnSafe中的偏移值（2.2.2）
static final long stateOffset;
//变量(2.2.3)
private volatile long state=0;
static {
try {
//获取state变量在类TestUnSafe中的偏移值(2.2.4)
stateOffset = unsafe.objectFieldOffset(TestUnSafe.class.
getDeclaredField("state"));
} catch (Exception ex) {
System.out.println(ex.getLocalizedMessage());
throw new Error(ex);
}
}
public static void main(String[] args) {
//创建实例，并且设置state值为1(2.2.5)
TestUnSafe test = new TestUnSafe();
//(2.2.6)
Boolean sucess = unsafe.compareAndSwapInt(test, stateOffset, 0, 1);
System.out.println(sucess);
}
} 在如上代码中，代码（2.2.1）获取了Unsafe的一个实例，代码（2.2.3）创建了一个变量state并初始化为0。
代码（2.2.4）使用unsafe.objectFieldOffset获取TestUnSafe类里面的state变量，在TestUnSafe对象里面的内存偏移量地址并将其保存到stateOffset变量中。
代码（2.2.6）调用创建的unsafe实例的compareAndSwapInt方法，设置test对象的state变量的值。具体意思是，如果test对象中内存偏移量为stateOffset的state变量的值为0，则更新该值为1。
运行上面的代码，我们期望输出true，然而执行后会输出如下结果。
为找出原因，必然要查看getUnsafe的代码。
private static final Unsafe theUnsafe = new Unsafe();
public static Unsafe getUnsafe(){
//（2.2.7）
Class localClass = Reflection.getCallerClass();
//（2.2.8)
if (! VM.isSystemDomainLoader(localClass.getClassLoader())) {
throw new SecurityException("Unsafe");
}
return theUnsafe;
}
//判断paramClassLoader是不是BootStrap类加载器(2.2.9)
public static boolean isSystemDomainLoader(ClassLoader paramClassLoader){
return paramClassLoader == null;
} 代码（2.2.7）获取调用getUnsafe这个方法的对象的Class对象，这里是TestUnSafe. class。
代码（2.2.8）判断是不是Bootstrap类加载器加载的localClass，在这里是看是不是Bootstrap加载器加载了TestUnSafe.class。很明显由于TestUnSafe.class是使用AppClassLoader加载的，所以这里直接抛出了异常。
思考一下，这里为何要有这个判断？我们知道Unsafe类是rt.jar包提供的，rt.jar包里面的类是使用Bootstrap类加载器加载的，而我们的启动main函数所在的类是使用AppClassLoader加载的，所以在main函数里面加载Unsafe类时，根据委托机制，会委托给Bootstrap去加载Unsafe类。
如果没有代码（2.2.8）的限制，那么我们的应用程序就可以随意使用Unsafe做事情了，而Unsafe类可以直接操作内存，这是不安全的，所以JDK开发组特意做了这个限制，不让开发人员在正规渠道使用Unsafe类，而是在rt.jar包里面的核心类中使用Unsafe功能。
如果开发人员真的想要实例化Unsafe类，那该如何做？
方法有多种，既然从正规渠道访问不了，那么就玩点黑科技，使用万能的反射来获取Unsafe实例方法。
public class TestUnSafe {
static final Unsafe unsafe;
static final long stateOffset;
private volatile long state = 0;
static {
try {
//使用反射获取Unsafe的成员变量theUnsafe
Field field = Unsafe.class.getDeclaredField("theUnsafe");
// 设置为可存取
field.setAccessible(true);
// 获取该变量的值
unsafe = (Unsafe) field.get(null);
//获取state在TestUnSafe中的偏移量
stateOffset = unsafe.objectFieldOffset(TestUnSafe.class.
getDeclaredField("state"));
} catch (Exception ex) {
System.out.println(ex.getLocalizedMessage());
throw new Error(ex);
}
}
public static void main(String[] args) {
TestUnSafe test = new TestUnSafe();
Boolean sucess = unsafe.compareAndSwapInt(test, stateOffset, 0, 1);
System.out.println(sucess);
}
} 在如上代码中，通过代码（2.2.10）、代码（2.2.11）和代码（2.2.12）反射获取unsafe的实例，运行后输出结果如下。
2.10 Java指令重排序
Java内存模型允许编译器和处理器对指令重排序以提高运行性能，并且只会对不存在数据依赖性的指令重排序。在单线程下重排序可以保证最终执行的结果与程序顺序执行的结果一致，但是在多线程下就会存在问题。
下面看一个例子。
int a = 1; (1)
int b = 2; (2)
int c= a + b; (3) 在如上代码中，变量c的值依赖a和b的值，所以重排序后能够保证（3）的操作在（2）（1）之后，但是（1）（2）谁先执行就不一定了，这在单线程下不会存在问题，因为并不影响最终结果。
下面看一个多线程的例子。
public static class ReadThread extends Thread {
public void run() {
while(! Thread.currentThread().isInterrupted()){
if(ready){//(1)
System.out.println(num+num); //(2)
}
System.out.println("read thread....");
}
}
}
public static class Writethread extends Thread {
public void run() {
num = 2; //(3)
ready = true; //(4)
System.out.println("writeThread set over...");
}
}
private static int num =0;
private static boolean ready = false;
public static void main(String[] args) throws InterruptedException {
ReadThread rt = new ReadThread();
rt.start();
Writethread wt = new Writethread();
wt.start();
Thread.sleep(10);
rt.interrupt();
System.out.println("main exit");
} 首先这段代码里面的变量没有被声明为volatile的，也没有使用任何同步措施，所以在多线程下存在共享变量内存可见性问题。这里先不谈内存可见性问题，因为通过把变量声明为volatile的本身就可以避免指令重排序问题。
这里先看看指令重排序会造成什么影响，如上代码在不考虑内存可见性问题的情况下一定会输出4？答案是不一定，由于代码（1）（2）（3）（4）之间不存在依赖关系，所以写线程的代码（3）（4）可能被重排序为先执行（4）再执行（3），那么执行（4）后，读线程可能已经执行了（1）操作，并且在（3）执行前开始执行（2）操作，这时候输出结果为0而不是4。
重排序在多线程下会导致非预期的程序执行结果，而使用volatile修饰ready就可以避免重排序和内存可见性问题。
写volatile变量时，可以确保volatile写之前的操作不会被编译器重排序到volatile写之后。读volatile变量时，可以确保volatile读之后的操作不会被编译器重排序到volatile读之前。
2.11 伪共享
2.11.1 什么是伪共享
为了解决计算机系统中主内存与CPU之间运行速度差问题，会在CPU与主内存之间添加一级或者多级高速缓冲存储器（Cache）。这个Cache一般是被集成到CPU内部的，所以也叫CPU Cache，图2-6所示是两级Cache结构。
图2-6
在Cache内部是按行存储的，其中每一行称为一个Cache行。Cache行（如图2-7所示）是Cache与主内存进行数据交换的单位，Cache行的大小一般为2的幂次数字节。
图2-7
当CPU访问某个变量时，首先会去看CPU Cache内是否有该变量，如果有则直接从中获取，否则就去主内存里面获取该变量，然后把该变量所在内存区域的一个Cache行大小的内存复制到Cache中。由于存放到Cache行的是内存块而不是单个变量，所以可能会把多个变量存放到一个Cache行中。当多个线程同时修改一个缓存行里面的多个变量时，由于同时只能有一个线程操作缓存行，所以相比将每个变量放到一个缓存行，性能会有所下降，这就是伪共享，如图2-8所示。
图2-8
在该图中，变量x和y同时被放到了CPU的一级和二级缓存，当线程1使用CPU1对变量x进行更新时，首先会修改CPU1的一级缓存变量x所在的缓存行，这时候在缓存一致性协议下，CPU2中变量x对应的缓存行失效。那么线程2在写入变量x时就只能去二级缓存里查找，这就破坏了一级缓存。而一级缓存比二级缓存更快，这也说明了多个线程不可能同时去修改自己所使用的CPU中相同缓存行里面的变量。更坏的情况是，如果CPU只有一级缓存，则会导致频繁地访问主内存。
2.11.2 为何会出现伪共享
伪共享的产生是因为多个变量被放入了一个缓存行中，并且多个线程同时去写入缓存行中不同的变量。那么为何多个变量会被放入一个缓存行呢？其实是因为缓存与内存交换数据的单位就是缓存行，当CPU要访问的变量没有在缓存中找到时，根据程序运行的局部性原理，会把该变量所在内存中大小为缓存行的内存放入缓存行。
long a;
long b;
long c;
long d;
如上代码声明了四个long变量，假设缓存行的大小为32字节，那么当CPU访问变量a时，发现该变量没有在缓存中，就会去主内存把变量a以及内存地址附近的b、c、d放入缓存行。也就是地址连续的多个变量才有可能会被放到一个缓存行中。当创建数组时，数组里面的多个元素就会被放入同一个缓存行。那么在单线程下多个变量被放入同一个缓存行对性能有影响吗？其实在正常情况下单线程访问时将数组元素放入一个或者多个缓存行对代码执行是有利的，因为数据都在缓存中，代码执行会更快，请对比下面代码的执行。
代码（1）
public class TestForContent {
static final int LINE_NUM = 1024;
static final int COLUM_NUM = 1024;
public static void main(String[] args) {
long [][] array = new long[LINE_NUM][COLUM_NUM];
long startTime = System.currentTimeMillis();
for(int i =0; i<LINE_NUM; ++i){
for(int j=0; j<COLUM_NUM; ++j){
array[i][j] = i＊2+j;
}
}
long endTime = System.currentTimeMillis();
long cacheTime = endTime - startTime;
System.out.println("cache time:" + cacheTime);
}
}
代码（2）
public class TestForContent2 {
static final int LINE_NUM = 1024;
static final int COLUM_NUM = 1024;
public static void main(String[] args) {
long [][] array = new long[LINE_NUM][COLUM_NUM];
long startTime = System.currentTimeMillis();
for(int i =0; i<COLUM_NUM; ++i){
for(int j=0; j<LINE_NUM; ++j){
array[j][i] = i＊2+j;
}
}
long endTime = System.currentTimeMillis();
System.out.println("no cache time:" + (endTime - startTime));
}
} 在笔者的mac电脑上执行代码（1）多次，耗时均在10ms以下，执行代码（2）多次，耗时均在10ms以上。显然代码（1）比代码（2）执行得快，这是因为数组内数组元素的内存地址是连续的，当访问数组第一个元素时，会把第一个元素后的若干元素一块放入缓存行，这样顺序访问数组元素时会在缓存中直接命中，因而就不会去主内存读取了，后续访问也是这样。也就是说，当顺序访问数组里面元素时，如果当前元素在缓存没有命中，那么会从主内存一下子读取后续若干个元素到缓存，也就是一次内存访问可以让后面多次访问直接在缓存中命中。而代码（2）是跳跃式访问数组元素的，不是顺序的，这破坏了程序访问的局部性原则，并且缓存是有容量控制的，当缓存满了时会根据一定淘汰算法替换缓存行，这会导致从内存置换过来的缓存行的元素还没等到被读取就被替换掉了。
所以在单个线程下顺序修改一个缓存行中的多个变量，会充分利用程序运行的局部性原则，从而加速了程序的运行。而在多线程下并发修改一个缓存行中的多个变量时就会竞争缓存行，从而降低程序运行性能。
2.11.3 如何避免伪共享
在JDK 8之前一般都是通过字节填充的方式来避免该问题，也就是创建一个变量时使用填充字段填充该变量所在的缓存行，这样就避免了将多个变量存放在同一个缓存行中，例如如下代码。
public final static class FilledLong {
public volatile long value = 0L;
public long p1, p2, p3, p4, p5, p6;
} 假如缓存行为64字节，那么我们在FilledLong类里面填充了6个long类型的变量，每个long类型变量占用8字节，加上value变量的8字节总共56字节。另外，这里FilledLong是一个类对象，而类对象的字节码的对象头占用8字节，所以一个FilledLong对象实际会占用64字节的内存，这正好可以放入一个缓存行。
JDK 8提供了一个sun.misc.Contended注解，用来解决伪共享问题。将上面代码修改为如下。
@sun.misc.Contended
public final static class FilledLong {
public volatile long value = 0L;
}
在这里注解用来修饰类，当然也可以修饰变量，比如在Thread类中。
/＊＊ The current seed for a ThreadLocalRandom ＊/
@sun.misc.Contended("tlr")
long threadLocalRandomSeed;
/＊＊ Probe hash value; nonzero if threadLocalRandomSeed initialized ＊/
@sun.misc.Contended("tlr")
int threadLocalRandomProbe;
/＊＊ Secondary seed isolated from public ThreadLocalRandom sequence ＊/
@sun.misc.Contended("tlr")
int threadLocalRandomSecondarySeed; Thread类里面这三个变量默认被初始化为0，这三个变量会在ThreadLocalRandom类中使用，后面章节会专门讲解ThreadLocalRandom的实现原理。
需要注意的是，在默认情况下，@Contended注解只用于Java核心类，比如rt包下的类。如果用户类路径下的类需要使用这个注解，则需要添加JVM参数：-XX:-RestrictContended。填充的宽度默认为128，要自定义宽度则可以设置-XX:ContendedPaddingWidth参数。
2.11.4 小结
本节讲述了伪共享是如何产生的，以及如何避免，并证明在多线程下访问同一个缓存行的多个变量时才会出现伪共享，在单线程下访问一个缓存行里面的多个变量反而会对程序运行起到加速作用。本节的这些知识为后面高级篇讲解的LongAdder的实现原理奠定了基础。
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=${versi
on}+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}的记录存在，则更新version的值为原来的值加1，这有点CAS操作的意思。
假设多个线程同时执行updateEntry并传递相同的id，那么它们执行代码（1）时获取的Entry是同一个，获取的Entry里面的version值都是相同的（这里假设version=0）。当多个线程执行代码（3）时，由于update语句本身是原子性的，假如线程A执行update成功了，那么这时候id对应的记录的version值由原始version值变为了1。其他线程执行代码（3）更新时发现数据库里面已经没有了version=0的语句，所以会返回影响行号0。在业务上根据返回值为0就可以知道当前更新没有成功，那么接下来有两个做法，如果业务发现更新失败了，下面可以什么都不做，也可以选择重试，如果选择重试，则updateEntry的代码可以修改为如下。
public boolean updateEntry(long id){
boolean result = false;
int retryNum = 5;
while(retryNum>0){
//(1.1)使用乐观锁获取指定记录
EntryObject entry = query("select ＊ from table1 where id = #{id}", id);
//(2.1)修改记录内容，version字段不能被修改
String name = generatorName(entry);
entry.setName(name);
。。。。
//(3.1)update操作
int count = update("update table1 set name=#{name}, age=#{age}, version=${versi
on}+1 where id =#{id} and version=#{version}", entry);
if(count == 1){
result = true;
break;
}
retryNum--;
}
return result;
} 如上代码使用retryNum设置更新失败后的重试次数，如果代码（3.1）执行后返回0，则说明代码（1.1）获取的记录已经被修改了，则循环一次，重新通过代码（1.1）获取最新的数据，然后再次执行代码（3.1）尝试更新。这类似CAS的自旋操作，只是这里没有使用死循环，而是指定了尝试次数。
乐观锁并不会使用数据库提供的锁机制，一般在表中添加version字段或者使用业务状态来实现。乐观锁直到提交时才锁定，所以不会产生任何死锁。
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("hello");
}
public synchronized void helloB(){
System.out.println("hello B");
helloA();
}
} 在如上代码中，调用helloB方法前会先获取内置锁，然后打印输出。之后调用helloA方法，在调用前会先去获取内置锁，如果内置锁不是可重入的，那么调用线程将会一直被阻塞。
实际上，synchronized内部锁是可重入锁。可重入锁的原理是在锁内部维护一个线程标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为0，说明该锁没有被任何线程占用。当一个线程获取了该锁时，计数器的值会变成1，这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。
但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加+1，当释放锁后计数器值-1。当计数器值为0时，锁里面的线程标示被重置为null，这时候被阻塞的线程会被唤醒来竞争获取该锁。
2.12.5 自旋锁
由于Java中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁（比如独占锁）失败后，会被切换到内核状态而被挂起。当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU使用权的情况下，多次尝试获取（默认次数是10，可以使用-XX:PreBlockSpinsh参数设置该值），很有可能在后面几次尝试中其他线程已经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用CPU时间换取线程阻塞与调度的开销，但是很有可能这些CPU时间白白浪费了。
2.13 总结
本章主要介绍了并发编程的基础知识，为后面在高级篇讲解并发包源码打下了基础，并结合图示形象地讲述了为什么要使用多线程编程，多线程编程存在的线程安全问题，以及什么是内存可见性问题。然后讲解了synchronized和volatile关键字，并且强调前者既保证内存的可见性又保证原子性，而后者则主要保证内存可见性，但是二者的内存语义很相似。最后讲解了什么是CAS和线程间同步以及各种锁的概念，这些都为后面讲解JUC包源码奠定了基础。
