由于并行程序设计比串行程序复杂得多。因此，我强烈建议大家可以熟悉和了解一些常见的设计方法。就好像练习武术一样，一招一式都是要经过学习的。如果自己胡乱打一气，效果不见得好。前人会总结一些武术套路，对于初学者来说，不需要发挥自己的想象力，只要按照武术套路出拳就可以了。等到练到了一定的高度，就可以以无招胜有招了，而不必拘泥于套路。这些武术套路和招数，对应到软件开发中来，就是设计模式。在这一章中，我将重点向大家介绍一些有关并行的设计模式以及算法。这些都是前人的经验总结和智慧的结晶。大家可以在熟知其思想和原理的基础之上，再根据自己的需求进行扩展，可能会达到更好的效果。
5.1 探讨单例模式
单例模式是设计模式中使用最为普遍的模式之一。它是一种对象创建模式，用于产生一个对象的具体实例，它可以确保系统中一个类只产生一个实例。在Java中，这样的行为能带来两大好处：
对于频繁使用的对象，可以省略new操作花费的时间，这对于那些重量级对象而言，是非常可观的一笔系统开销；
由于new操作的次数减少，因而对系统内存的使用频率也会降低，这将减轻GC压力，缩短GC停顿时间。
严格来说，单例模式与并行没有直接的关系。这里我希望讨论这个模式，是因为它实在是太常见了。并且，我们不可避免的，会在多线程环境中使用它们。并且，系统中使用单例的地方可能非常频繁，因此，我们非常迫切需要一种高效的单例实现。
下面给出了一个单例的实现，这个实现是非常简单的，但无疑是一个正确并且良好的实现。
1 public class Singleton { 2 private Singleton(){ 3 System.out.println("Singleton is create"); 4 } 5 private static Singleton instance = new Singleton(); 6 public static Singleton getInstance() { 7 return instance; 8 } 9 }
使用以上方式创建单例有几点必须特别注意。因为我们要保证系统中不会有人意外创建多余的实例，因此，我们把Singleton的构造函数设置为private。这点非常重要，这就警告所有的开发人员，不能随便创建这个类的实例，从而有效避免该类被错误的创建。
第二点，instance对象必须是private并且static的。如果不是private，那么instance的安全性无法得到保证。一个小小的意外就可能使得instance变成null。其次，因为工厂方法getInstance()必须是static的，因此对应的instance也必须是static。
这个单例的性能是非常好的，因为getInstance()方法只是简单地返回instance，并没有任何锁操作，因此它在并行程序中，会有良好的表现。
但是这种方式有一点明显不足，就是Singleton构造函数，或者说Singleton实例在什么时候创建是不受控制的。对于静态成员instance，它会在类第一次初始化的时候被创建。这个时刻并不一定是getInstance()方法第一次被调用的时候。
比如，如果你的单例像是这样的：
public class Singleton { public static int STATUS=1; private Singleton(){ System.out.println("Singleton is create"); } private static Singleton instance = new Singleton(); public static Singleton getInstance() { return instance; } }
注意，这个单例还包含一个表示状态的静态成员STATUS。此时，在相同任何地方引用这个STATUS都会导致instance实例被创建（任何对Singleton方法或者字段的引用，都会导致类初始化，并创建instance实例，但是类初始化只有一次，因此instance实例永远只会被创建一次）。比如：
System.out.println(Singleton.STATUS);
上述println会打印出：
Singleton is create 1
可以看到，即使系统没有要求创建单例，new Singleton()也会被调用。
如果大家觉得这个小小的不足并不重要，我认为这种单例模式是一种不错的选择。它容易实现，代码易读而且性能优越。
但如果你想精确控制instance的创建时间，那么这种方式就不太友善了。我们需要寻找一种新的方法，一种支持延迟加载的策略，它只会在instance被第一次使用时，创建对象。具体实现如下：
01 public class LazySingleton { 02 private LazySingleton() { 03 System.out.println("LazySingleton is create"); 04 } 05 private static LazySingleton instance = null; 06 public static synchronized LazySingleton getInstance() { 07 if (instance == null) 08 instance = new LazySingleton(); 09 return instance; 10 } 11 }
这个LazySingleton的核心思想如下：最初，我们并不需要实例化instance，而当getInstance()方法被第一次调用时，创建单例对象。为了防止对象被多次创建，我们不得不使用synchronized进行方法同步。这种实现的好处是，充分利用了延迟加载，只在真正需要时创建对象。但坏处也很明显，并发环境下加锁，竞争激烈的场合对性能可能产生一定的影响。但总体上，这是一个非常易于实现和理解的方法。
此外，还有一种被称为双重检查模式的方法可以用于创建单例。但我并不打算在这里介绍它，因为这是一种非常丑陋、复杂的方法，甚至在低版本的JDK中都不能保证正确性。因此，绝不推荐大家使用。如果大家阅读到相关文档，我也强烈建议大家不要在这种方法上花费太多时间。
在上述介绍的两种单例实现中，可以说是各有千秋。有没有一种方法可以结合二者之优势呢？答案是肯定的：
01 public class StaticSingleton { 02 private StaticSingleton(){ 03 System.out.println("StaticSingleton is create"); 04 } 05 private static class SingletonHolder { 06 private static StaticSingleton instance = new StaticSingleton(); 07 } 08 public static StaticSingleton getInstance() { 09 return SingletonHolder.instance; 10 } 11 }
上述代码实现了一个单例，并且同时拥有前两种方式的有点。首先getInstance()方法中没有锁，这使得在高并发环境下性能优越。其次，只有在getInstance()方法被第一次调用时，StaticSingleton的实例才会被创建。因为这种方法巧妙地使用了内部类和类的初始化方式。内部类SingletonHolder被申明为private，这使得我们不可能在外部访问并初始化它。而我们只可能在getInstance()内部对SingletonHolder类进行初始化，利用虚拟机的类初始化机制创建单例。
5.2 不变模式
在并行软件开发过程中，同步操作似乎是必不可少的。当多线程对同一个对象进行读写操作时，为了保证对象数据的一致性和正确性，有必要对对象进行同步。而同步操作对系统性能是有相当的损耗。为了能尽可能地去除这些同步操作，提高并行程序性能，可以使用一种不可改变的对象，依靠对象的不变性，可以确保其在没有同步操作的多线程环境中依然始终保持内部状态的一致性和正确性。这就是不变模式。
不变模式天生就是多线程友好的，它的核心思想是，一个对象一旦被创建，则它的内部状态将永远不会发生改变。所以，没有一个线程可以修改其内部状态和数据，同时其内部状态也绝不会自行发生改变。基于这些特性，对不变对象的多线程操作不需要进行同步控制。
同时还需要注意，不变模式和只读属性是有一定的区别的。不变模式是比只读属性具有更强的一致性和不变性。对只读属性的对象而言，对象本身不能被其他线程修改，但是对象的自身状态却可能自行修改。
比如，一个对象的存活时间（对象创建时间和当前时间的时间差）是只读的，因为任何一个第三方线程都不能修改这个属性，但是这是一个可变的属性，因为随着时间的推移，存活时间时刻都在发生变化。而不变模式则要求，无论出于什么原因，对象自创建后，其内部状态和数据保持绝对的稳定。
因此，不变模式的主要使用场景需要满足以下2个条件：
当对象创建后，其内部状态和数据不再发生任何变化。
对象需要被共享，被多线程频繁访问。
在Java语言中，不变模式的实现很简单。为确保对象被创建后，不发生任何改变，并保证不变模式正常工作，只需要注意以下4点：
去除setter方法以及所有修改自身属性的方法。
将所有属性设置为私有，并用final标记，确保其不可修改。
确保没有子类可以重载修改它的行为。
有一个可以创建完整对象的构造函数。
以下代码实现了一个不变的产品对象，它拥有序列号、名称和价格三个属性。
public final class Product { //确保无子类 private final String no; //私有属性，不会被其他对象获取 private final String name; //final保证属性不会被2次赋值 private final double price; public Product(String no, String name, double price) { //在创建对象时，必须指定数据 super(); //因为创建之后，无法进行修改 this.no = no; this.name = name; this.price = price; } public String getNo() { return no; } public String getName() { return name; } public double getPrice() { return price; } }
在不变模式的实现中，final关键字起到了重要的作用。对属性的final定义确保所有数据只能在对象被构造时赋值1次。之后，就永远不再发生改变。而对class的final确保了类不会有子类。根据里氏代换原则，子类可以完全的替代父类。如果父类是不变的，那么子类也必须是不变的，但实际上我们并无法约束这点，为了防止子类做出一些意外的行为，这里就干脆把子类都禁用了。
在JDK中，不变模式的应用非常广泛。其中，最为典型的就是java.lang.String类。此外，所有的元数据类包装类，都是使用不变模式实现的。主要的不变模式类型如下：
java.lang.String
java.lang.Boolean
java.lang.Byte
java.lang.Character
java.lang.Double
java.lang.Float
java.lang.Integer
java.lang. Long
java.lang.Short
由于基本数据类型和String类型在实际的软件开发中应用极其广泛，使用不变模式后，所有实例的方法均不需要进行同步操作，保证了它们在多线程环境下的性能。
注意：不变模式通过回避问题而不是解决问题的态度来处理多线程并发访问控制。不变对象是不需要进行同步操作的。由于并发同步会对性能产生不良的影响，因此，在需求允许的情况下，不变模式可以提高系统的并发性能和并发量。
5.3 生产者-消费者模式
生产者-消费者模式是一个经典的多线程设计模式，它为多线程间的协作提供了良好的解决方案。在生产者-消费者模式中，通常有两类线程，即若干个生产者线程和若干个消费者线程。生产者线程负责提交用户请求，消费者线程则负责具体处理生产者提交的任务。生产者和消费者之间则通过共享内存缓冲区进行通信。
如图5.1所示，展示了生产者-消费者模式的基本结构。三个生产者线程将任务提交到共享内存缓冲区，消费者线程并不直接与生产者线程通信，而在共享内存缓冲区中获取任务，并进行处理。
图5.1 生产者-消费者模式架构图
注意：生产者-消费者模式中的内存缓存区的主要功能是数据在多线程间的共享，此外，通过该缓冲区，可以缓解生产者和消费者间的性能差。
生产者-消费者模式的核心组件是共享内存缓存区，它作为生产者和消费者间的通信桥梁，避免了生产者和消费者的直接通信，从而将生产者和消费者进行解耦。生产者不需要知道消费者的存在，消费者也不需要知道生产者的存在。
同时，由于内存缓冲区的存在，允许生产者和消费者在执行速度上存在时间差，无论是生产者在某一局部时间内速度高于消费者，还是消费者在局部时间内高于生产者，都可以通过共享内存缓冲区得到缓解，确保系统正常运行。
生产者-消费者模式的主要角色如表5.1所示。
表5.1 生产者-消费者模式主要角色
图5.2显示了生产者-消费者模式一种实现的具体结构。
图5.2 生产者-消费者实现类图
其中，BlockigQueue充当了共享内存缓冲区，用于维护任务或数据队列（PCData对象）。我强烈建议大家先回顾一下第3章有关BlockingQueue的相关知识，对于理解整个生产者和消费者结构有重要的帮助。PCData对象表示一个生产任务，或者相关任务的数据。生产者对象和消费者对象均引用同一个BlockigQueue实例。生产者负责创建PCData对象，并将它加入BlockigQueue中，消费者则从BlockigQueue队列中获取PCData。
基于图5.2所示结构，实现一个基于生产者-消费者模式的求整数平方的并行程序。
首先，生产者线程的实现如下，它构建PCData对象，并放入BlockingQueue队列中。
public class Producer implements Runnable { private volatile boolean isRunning = true; private BlockingQueue＜PCData＞ queue; //内存缓冲区 private static AtomicInteger count = new AtomicInteger(); //总数，原子操作 private static final int SLEEPTIME = 1000; public Producer(BlockingQueue＜PCData＞ queue) { this.queue = queue; } public void run() { PCData data = null; Random r = new Random(); System.out.println("start producer id="+Thread.currentThread().getId()); try { while (isRunning) { Thread.sleep(r.nextInt(SLEEPTIME)); data = new PCData(count.incrementAndGet()); //构造任务数据 System.out.println(data+" is put into queue"); if (!queue.offer(data, 2, TimeUnit.SECONDS)) { //提交数据到缓冲区中 System.err.println("failed to put data：" + data); } } } catch (InterruptedException e) { e.printStackTrace(); Thread.currentThread().interrupt(); } } public void stop() { isRunning = false; } }
对应的消费者的实现如下。它从BlockingQueue队列中取出PCData对象，并进行相应的计算。
public class Consumer implements Runnable { private BlockingQueue＜PCData＞ queue; //缓冲区 private static final int SLEEPTIME = 1000; public Consumer(BlockingQueue＜PCData＞ queue) { this.queue = queue; } public void run() { System.out.println("start Consumer id=" + Thread.currentThread().getId()); Random r = new Random(); //随机等待时间 try { while(true){ PCData data = queue.take(); //提取任务 if (null != data) { int re = data.getData() * data.getData(); //计算平方 System.out.println(MessageFormat.format("{0}*{1}={2}", data.getData(), data.getData(), re)); Thread.sleep(r.nextInt(SLEEPTIME)); } } } catch (InterruptedException e) { e.printStackTrace(); Thread.currentThread().interrupt(); } } }
PCData作为生产者和消费者之间的共享数据模型，定义如下：
public final class PCData { //任务相关的数据 private final int intData; //数据 public PCData(int d){ intData=d; } public PCData(String d){ intData=Integer.valueOf(d); } public int getData(){ return intData; } @Override public String toString(){ return "data:"+intData; } }
在主函数中，创建三个生产者和三个消费者，并让它们协作运行。在主函数的实现中，定义LinkedBlockingQueue作为BlockingQueue的实现类。
public class Main { public static void main(String[] args) throws InterruptedException { //建立缓冲区 BlockingQueue＜PCData＞ queue = new LinkedBlockingQueue＜PCData＞(10); Producer producer1 = new Producer(queue); //建立生产者 Producer producer2 = new Producer(queue); Producer producer3 = new Producer(queue); Consumer consumer1 = new Consumer(queue); //建立消费者 Consumer consumer2 = new Consumer(queue); Consumer consumer3 = new Consumer(queue); ExecutorService service = Executors.newCachedThreadPool(); //建立线程池 service.execute(producer1); //运行生产者 service.execute(producer2); service.execute(producer3); service.execute(consumer1); //运行消费者 service.execute(consumer2); service.execute(consumer3); Thread.sleep(10 * 1000); producer1.stop(); //停止生产者 producer2.stop(); producer3.stop(); Thread.sleep(3000); service.shutdown(); } }
注意：生产者-消费者模式很好地对生产者线程和消费者线程进行解耦，优化了系统整体结构。同时，由于缓冲区的作用，允许生产者线程和消费者线程存在执行上的性能差异，从一定程度上缓解了性能瓶颈对系统性能的影响。
5.4 高性能的生产者-消费者：无锁的实现
BlockigQueue用于实现生产者和消费者一个不错的选择。它可以很自然地实现作为生产者和消费者的内存缓冲区。但是BlockigQueue并不是一个高性能的实现，它完全使用锁和阻塞等待来实现线程间的同步。在高并发场合，它的性能并不是特别的优越。就像之前我已经提过的：ConcurrentLinkedQueue是一个高性能的队列，但是BlockingQueue只是为了方便数据共享。
而ConcurrentLinkedQueue的秘诀就在于大量使用了无锁的CAS操作。同理，如果我们使用CAS来实现生产者-消费者模式，也同样可以获得可观的性能提升。不过正如大家所见，使用CAS进行编程是非常困难的，但有一个好消息是，目前有一个现成的Disruptor框架，它已经帮助我们实现了这一个功能。
5.4.1 无锁的缓存框架：Disruptor
Disruptor框架是由LMAX公司开发的一款高效的无锁内存队列。它使用无锁的方式实现了一个环形队列，非常适合于实现生产者和消费者模式，比如事件和消息的发布。在Disruptor中，别出心裁地使用了环形队列（RingBuffer）来代替普通线性队列，这个环形队列内部实现为一个普通的数组。对于一般的队列，势必要提供队列同步head和尾部tail两个指针，用于出队和入队，这样无疑就增加了线程协作的复杂度。但如果队列是环形的，则只需要对外提供一个当前位置cursor，利用这个指针既可以进入入队也可以进行出队操作。由于环形队列的缘故，队列的总大小必须事先指定，不能动态扩展。为了能够快速从一个序列（sequence）对应到数组的实际位置（每次有元素入队，序列就加1），Disruptor要求我们必须将数组的大小设置为2的整数次方。这样通过sequence &(queueSize-1)就能立即定位到实际的元素位置index。这个要比取余（%）操作快得多。
如果大家不理解上面的sequence &(queueSize-1)，我在这里再简单说明一下。如果queueSize是2的整数次幂，则这个数字的二进制表示必然是10、100、1000、10000等形式。因此，queueSize-1的二进制则是一个全1的数字。因此它可以将sequence限定在queueSize-1范围内，并且不会有任何一位是浪费的。
如图5.3所示，显示了RingBuffer的结构。生产者向缓冲区中写入数据，而消费者从中读取数据。生产者写入数据时，使用CAS操作，消费者读取数据时，为了防止多个消费者处理同一个数据，也使用CAS操作进行数据保护。
图5.3 Disruptor的RingBuffer结构
这种固定大小的环形队列的另外一个好处就是可以做到完全的内存复用。在系统的运行过程中，不会有新的空间需要分配或者老的空间需要回收。因此，可以大大减少系统分配空间以及回收空间的额外开销。
5.4.2 用Disruptor实现生产者-消费者案例
现在我们已经基本了解了Disruptor的基本实现。在本节，我们将展示一下Disruptor的基本使用和API，这里，我们使用的版本是disruptor-3.3.2，不同版本的disruptor可能会有细微的差别，也请大家留意。
这里，我们的生产者不断产生整数，消费者读取生产者的数据，并计算其平方。
首先，我们还是需要一个代表数据的PCData：
public class PCData { private long value; public void set(long value) { this.value = value; } public long get(){ return value; } }
消费者实现为WorkHandler接口，它来自Disruptor框架：
public class Consumer implements WorkHandler＜PCData＞ { @Override public void onEvent(PCData event) throws Exception { System.out.println(Thread.currentThread().getId() + ":Event: --" + event.get() * event.get() + "--"); } }
消费者的作用是读取数据进行处理。这里，数据的读取已经由Disruptor进行封装，onEvent()方法为框架的回调方法。因此，这里只需要简单地进行数据处理即可。
还需要一个产生PCData的工厂类。它会在Disruptor系统初始化时，构造所有的缓冲区中的对象实例（之前说过Disruptor会预先分配空间）：
public class PCDataFactory implements EventFactory＜PCData＞ { public PCData newInstance() { return new PCData(); } }
接着，让我们来看一下生产者，它比前面几个类稍微复杂一点：
01 public class Producer 02 { 03 private final RingBuffer＜PCData＞ ringBuffer; 04 05 public Producer(RingBuffer＜PCData＞ ringBuffer) 06 { 07 this.ringBuffer = ringBuffer; 08 } 09 10 public void pushData(ByteBuffer bb) 11 { 12 long sequence = ringBuffer.next(); // Grab the next sequence 13 try 14 { 15 PCData event = ringBuffer.get(sequence); // Get the entry in the Disruptor 16 // for the sequence 17 event.set(bb.getLong(0)); // Fill with data 18 } 19 finally 20 { 21 ringBuffer.publish(sequence); 22 } 23 } 24 }
生产者需要一个RingBuffer的引用，也就是环形缓冲区。它有一个重要的方法pushData()将产生的数据推入缓冲区。方法pushData()接收一个ByteBuffer对象。在ByteBuffer中可以用来包装任何数据类型。这里用来存储long整数，pushData()的功能就是将传入的ByteBuffer中的数据提取出来，并装载到环形缓冲区中。
上述第12行代码，通过next()方法得到下一个可用的序列号。通过序列号，取得下一个空闲可用的PCData，并且将PCData的数据设为期望值，这个值最终会传递给消费者。最后，在第21行，进行数据发布。只有发布后的数据才会真正被消费者看见。
至此，我们的生产者、消费者和数据都已经准备就绪。只差一个统筹规划的主函数将所有的内容整合起来：
01 public static void main(String[] args) throws Exception 02 { 03 Executor executor = Executors.newCachedThreadPool(); 04 PCDataFactory factory = new PCDataFactory(); 05 // Specify the size of the ring buffer, must be power of 2. 06 int bufferSize = 1024; 07 Disruptor＜PCData＞ disruptor = new Disruptor＜PCData＞(factory, 08 bufferSize, 09 executor, 10 ProducerType.MULTI, 11 new BlockingWaitStrategy() 12 ); 13 disruptor.handleEventsWithWorkerPool( 14 new Consumer(), 15 new Consumer(), 16 new Consumer(), 17 new Consumer()); 18 disruptor.start(); 19 20 RingBuffer＜PCData＞ ringBuffer = disruptor.getRingBuffer(); 21 Producer producer = new Producer(ringBuffer); 22 ByteBuffer bb = ByteBuffer.allocate(8); 23 for (long l = 0; true; l++) 24 { 25 bb.putLong(0, l); 26 producer.pushData(bb); 27 Thread.sleep(100); 28 System.out.println("add data "+l); 29 } 30 }
上述代码第6行，设置缓冲区大小为1024。显然是2的整数次幂——一个合理的大小。第7～12创建了disruptor对象。它封装了整个disruptor库的使用，提供了一些便捷的API。第13～17行，设置了用于处理数据的消费者。这里设置了4个消费者实例，系统会为将每一个消费者实例映射到一个线程中，也就是这里提供了4个消费者线程。第18行，启动并初始化disruptor系统。在第23～29行中，由一个生产者不断地向缓冲区中存入数据。
系统执行后，你就可以得到类似以下的输出：
8:Event: --0-- add data 0 11:Event: --1-- add data 1 10:Event: --4-- add data 2 9:Event: --9-- add data 3
生产者和消费者正常工作。根据Disruptor的官方报告，Disruptor的性能要比BlockingQueue至少高一个数量级以上。如此诱人的性能，当然值得我们去尝试！
5.4.3 提高消费者的响应时间：选择合适的策略
当有新数据在Disruptor的环形缓冲区中产生时，消费者如何知道这些新产生的数据呢？或者说，消费者如何监控缓冲区中的信息呢？为此，Disruptor提供了几种策略，这些策略由WaitStrategy接口进行封装，主要有以下几种实现。
BlockingWaitStrategy：这是默认的策略。使用BlockingWaitStrategy和使用BlockingQueue是非常类似的，它们都使用锁和条件（Condition）进行数据的监控和线程的唤醒。因为涉及到线程的切换，BlockingWaitStrategy策略是最节省CPU，但是在高并发下性能表现最糟糕的一种等待策略。
SleepingWaitStrategy：这个策略也是对CPU使用率非常保守的。它会在循环中不断等待数据。它会先进行自旋等待，如果不成功，则使用Thread.yield()让出CPU，并最终使用LockSupport.parkNanos(1)进行线程休眠，以确保不占用太多的CPU数据。因此，这个策略对于数据处理可能产生比较高的平均延时。它比较适合于对延时要求不是特别高的场合，好处是它对生产者线程的影响最小。典型的应用场景是异步日志。
YieldingWaitStrategy：这个策略用于低延时的场合。消费者线程会不断循环监控缓冲区变化，在循环内部，它会使用Thread.yield()让出CPU给别的线程执行时间。如果你需要一个高性能的系统，并且对延时有较为严格的要求，则可以考虑这种策略。使用这种策略时，相当于你的消费者线程变身成为了一个内部执行了Thread.yield()的死循环。因此，你最好有多于消费者线程数量的逻辑CPU数量（这里的逻辑CPU，我指的是“双核四线程”中的那个四线程，否则，整个应用程序恐怕都会受到影响。
BusySpinWaitStrategy：这个是最疯狂的等待策略了。它就是一个死循环！消费者线程会尽最大努力疯狂监控缓冲区的变化。因此，它会吃掉所有的CPU资源。你只有在对延迟非常苛刻的场合可以考虑使用它（或者说，你的系统真的非常繁忙）。因为在这里你等同开启了一个死循环监控，所以，你的物理CPU数量必须要大于消费者线程数。注意，我这里说的是物理CPU，如果你在一个物理核上使用超线程技术模拟两个逻辑核，另外一个逻辑核显然会受到这种超密集计算的影响而不能正常工作。
在上面的例子中，使用的是BlockingWaitStrategy（第11行）。读者可以替换这个实现，体验一下不同等待策略的效果。
5.4.4 CPU Cache的优化：解决伪共享问题
除了使用CAS和提供了各种不同的等待策略来提高系统的吞吐量外。Disruptor大有将优化进行到底的气势，它甚至尝试解决CPU缓存的伪共享问题。
什么是伪共享问题呢？我们知道，为了提高CPU的速度，CPU有一个高速缓存Cache。在高速缓存中，读写数据的最小单位为缓存行（Cache Line），它是从主存（memory）复制到缓存（Cache）的最小单位，一般为32字节到128字节。
如果两个变量存放在一个缓存行中时，在多线程访问中，可能会相互影响彼此的性能。如图5.4所示，假设X和Y在同一个缓存行。运行在CPU1上的线程更新了X，那么CPU2上的缓存行就会失效，同一行的Y即使没有修改也会变成无效，导致Cache无法命中。接着，如果在CPU2上的线程更新了Y，则导致CPU1上的缓存行又失效（此时，同一行的X又变得无法访问）。这种情况反反复复发生，无疑是一个潜在的性能杀手。如果CPU经常不能命中缓存，那么系统的吞吐量就会急剧下降。
