并发编程-系统学习篇

并发编程的掌握过程并不容易。我相信为了解决这个问题，你也听别人总结过：并发编程的第一原则，那就是不要写并发程序

这个原则在我刚毕业的那几年曾经是行得通的，那个时候多核服务器还是一种奢侈品，系统的并发量也很低，借助数据库和类似 Tomcat 这种中间件，我们基本上不用写并发程序。或者说，并发问题基本上都被中间件和数据库解决了

Java 经过这些年的发展， Java SDK 并发包提供了非常丰富的功能，对于初学者来说可谓是眼花缭乱，好多人觉得无从下手。但是，Java SDK 并发包乃是并发大师 Doug Lea 出品堪称经典，它内部一定是有章可循的。那它的章法在哪里呢？

其实并发编程可以总结为三个核心问题：

分工
同步
互斥

分工，指的是如何高效地拆解任务并分配给线程

同步，指的是线程之间如何协作，

互斥则是保证同一时刻只允许一个线程访问共享资源

Java SDK 并发包很大部分内容都是按照这三个维度组织的，例如 Fork/Join 框架就是一种分工模式， CountDownLatch 就是一种典型的同步方式，而可重入锁则是一种互斥手段。

当把并发编程核心的问题搞清楚，再回过头来看 Java SDK 并发包，你会感觉豁然开朗，它不过是针对并发问题开发出来的工具而已，此时的 SDK 并发包可以任你 “盘” 了。而且，这三个核心问题是跨语言的，你如果要学习其他语言的并发编程类库，完全可以顺着这三个问题按图索骥。 Java SDK 并发包其余的一部分则是并发容器和原子类，这些比较容易理解，属于辅助工具，其他语言里基本都能找到对应的

并发编程并不是一门相对独立的学科，而是一个综合学科。并发编程相关的概念和技术看上非常零散，相关度也很低，总给你一种这样的感觉：我已经学习很多相关技术了，可还是搞不定并发编程。那如何才能学习好并发编程呢？其实很简单，只要你能从两个方面突破一下就可以了。一个是“跳出来，看全景” ，另一个是“钻进去，看本质” 。

跳出来，看全景

我们先说“跳出来” 。你应该也知道，学习最忌讳的就是“盲人摸象” ，只看到局部，而没有看到全局。所以，你需要从一个个单一的知识和技术中 “跳出来” ，高屋建瓴地看并发编程。当然，这首要之事就是你建立起一张全景图

在我看来，并发编程领域可以抽象成三个核心问题：分工、同步和互斥。

1. 分工

所谓分工，类似于现实中一个组织完成一个项目，项目经理要拆分任务，安排合适的成员去完成。在并发编程领域，你就是项目经理，线程就是项目组成员。任务分解和分工对于项目成败非常关键，不过在并发领域里，分工更重要，它直接决定了并发程序的性能。在现实世界里，分工是很复杂的，著名数学家华罗庚曾用 “烧水泡茶” 的例子通俗地讲解了统筹方法（一种安排工作进程的数学方法）， “烧水泡茶” 这么简单的事情都这么多说道，更何况是并发编程里的工程问题呢。

既然分工很重要又很复杂，那一定有前辈努力尝试解决过，并且也一定有成果。的确，在并发编程领域这方面的成果还是很丰硕的。 Java SDK 并发包里的 Executor、 Fork/Join、 Future 本质上都是一种分工方法。除此之外，并发编程领域还总结了一些设计模式，基本上都是和分工方法相关的，例如生产者 - 消费者、 Thread-Per-Message、 Worker Thread 模式等都是用来指导你如何分工的。

学习这部分内容，最佳的方式就是和现实世界做对比。例如生产者 - 消费者模式，可以类比一下餐馆里的大厨和服务员，大厨就是生产者，负责做菜，做完放到出菜口，而服务员就是消费者，把做好的菜给你端过来。不过，我们经常会发现，出菜口有时候一下子出了好几个菜，服务员是可以把这一批菜同时端给你的。其实这就是生产者 - 消费者模式的一个优点， 生产者一个一个地生产数据，而消费者可以批处理，这样就提高了性能。

2. 同步

分好工之后，就是具体执行了。在项目执行过程中，任务之间是有依赖的，一个任务结束后，依赖它的后续任务就可以开工了，后续工作怎么知道可以开工了呢？这个就是靠沟通协作，在并发编程领域里的同步，主要指的就是线程间的协作，本质上和现实生活中的协作没区别，不过是 一个线程执行完了一个任务，如何通知执行后续任务的线程开工而已。协作一般是和分工相关的。 Java SDK 并发包里的 Executor、 Fork/Join、 Future 本质上都是分工方法，但同时也能解决线程协作的问题。例如，用 Future 可以发起一个异步调用，当主线程通过 get() 方法取结果时，主线程就会等待，当异步执行的结果返回时， get() 方法就自动返回了。主线程和异步线程之间的协作， Future 工具类已经帮我们解决了。除此之外， Java SDK 里提供的 CountDownLatch、 CyclicBarrier、 Phaser、 Exchanger 也都是用来解决线程协作问题的。不过还有很多场景，是需要你自己来处理线程之间的协作的。 工作中遇到的线程协作问题，基本上都可以描述为这样的一个问题： 当某个条件不满足时，线程需要等待，当某个条件满足时，线程需要被唤醒执行 。例如，在生产者 - 消费者模型里，也有类似的描述， “当队列满时，生产者线程等待，当队列不满时，生产者线程需要被唤醒执行；当队列空时，消费者线程等待，当队列不空时，消费者线程需要被唤醒执行。 ”

在 Java 并发编程领域，解决协作问题的核心技术是管程，上面提到的所有线程协作技术底层都是利用管程解决的。管程是一种解决并发问题的通用模型，除了能解决线程协作问题，还能解决下面我们将要介绍的互斥问题。可以这么说，管程是解决并发问题的万能钥匙 。

所以说，这部分内容的学习，关键是理解管程模型，学好它就可以解决所有问题。其次是了解 Java SDK 并发包提供的几个线程协作的工具类的应用场景，用好它们可以妥妥地提高你的工作效率。

3. 互斥

分工、同步主要强调的是性能，但并发程序里还有一部分是关于正确性的，用专业术语叫 “ 线程安全 ” 。并发程序里，当多个线程同时访问同一个共享变量的时候，结果是不确定的。不确定，则意味着可能正确，也可能错误，事先是不知道的。 而导致不确定的主要源头是可见性问题、有序性问题和原子性问题，为了解决这三个问题， Java 语言引入了内存模型，内存模型提供了一系列的规则，利用这些规则，我们可以避免可见性问题、有序性问题，但是还不足以完全解决线程安全问题。解决线程安全问题的核心方案还是互斥。 所谓互斥，指的是同一时刻，只允许一个线程访问共享变量

实现互斥的核心技术就是锁， Java 语言里 synchronized、 SDK 里的各种 Lock 都能解决互斥问题。虽说锁解决了安全性问题，但同时也带来了性能问题，那如何保证安全性的同时又尽量提高性能呢？可以分场景优化， Java SDK 里提供的 ReadWriteLock、 StampedLock 就可以优化读多写少场景下锁的性能。还可以使用无锁的数据结构，例如 Java SDK 里提供的原子类都是基于无锁技术实现的。除此之外，还有一些其他的方案，原理是不共享变量或者变量只允许读。这方面， Java 提供了 Thread Local 和 final 关键字，还有一种 Copy-on-write 的模式。

使用锁除了要注意性能问题外，还需要注意死锁问题。

这部分内容比较复杂，往往还是跨领域的，例如要理解可见性，就需要了解一些 CPU 和缓存的知识；要理解原子性，就需要理解一些操作系统的知识；很多无锁算法的实现往往也需要理解 CPU 缓存。这部分内容的学习，需要博览群书，在大脑里建立起 CPU、内存、 I /O 执行的模拟器。这样遇到问题就能得心应手了。跳出来，看全景，可以让你的知识成体系，所学知识也融汇贯通起来，由点成线，由线及面，画出自己的知识全景图。

钻进去，看本质

但是光跳出来还不够，还需要下一步，就是在某个问题上钻进去，深入理解，找到本质。就拿我个人来说，我已经烦透了去讲述或被讲述一堆概念和结论，而不分析这些概念和结论是怎么来的，以及它们是用来解决什么问题的。在大学里，这样的教材很流行，直接导致了芸芸学子成绩很高，但解决问题的能力很差。其实，知其然知其所以然，才算真的学明白了。

我属于理论派，我认为工程上的解决方案，一定要有理论做基础。所以在学习并发编程的过程中，我都会探索它背后的理论是什么。比如，当看到 Java SDK 里面的条件变量 Condition 的时候，我会下意识地问，“它是从哪儿来的？是 Java 的特有概念，还是一个通用的编程概念？” 当我知道它来自管程的时候，我又会问，“管程被提出的背景和解决的问题是什么？”这样一路探索下来，我发现 Java 语言里的并发技术基本都是有理论基础的，并且这些理论在其他编程语言里也有类似的实现。所以我认为，技术的本质是背后的理论模型

注：

从性能角度讲，我们为了提高执行一定计算机任务的效率，所以IO等待的时候不能让cpu闲着，所以我们把任务拆分交替执行，有了分时操作系统，出现了并发，后来cpu多核有了并行计算。这里也就是作者说的[分工]

分工以后我们为了进一步提升效率和更加灵活地达到目的，所以我们要对任务进行组织编排，也就是对线程组织编排。于是线程之间需要通信，于是操作系统提供了一些让进程，线程之间通信的方式。也就是作者说的[同步]