1 前言

在 JDK5 之前 ，Java 多线程以及其性能一直是个软肋， 只有 synchronized、Thread.sleep()、Object.wait/notify 这样有限的方法，而 synchronized 的效率还特别地低，开销比较大。

在 JDK5 之后 ，相对于前面版本有了重大改进，不仅在 Java 语法上有了很多改进，包括：泛型、装箱、for 循环、变参等，在多线程上也有了彻底提高，其引进了并发编程大师 Doug Lea 的 java.util.concurrent 包(后面简称 J.U.C)， 支持了现代 CPU 的 CAS 原语，不仅在性能上有了很大提升，在自由度上也有了更多的选择，此时J.U.C 的效率在高并发环境下的效率远优于 synchronized。

在 JDK6（Mustang 野马）中 ，对 synchronized 的内在机制做了大量显著的优化， 加入了 CAS 的概念以及偏向锁、轻量级锁，使得 synchronized 的效率与 J.U.C 不相上下 ，并且官方说后面该关键字还有继续优化的空间，所以在现 在 JDK7 时代，synchronized 已经成为一般情况下的首选，在某些特殊场景：可中断的锁、条件锁、等待获得锁一段时间如果失败则停止，J.U.C 是适用的 ，所以对于 多线程研究来说，了解其原理以及各自的适用场景是必要的。

2 基本概念

2.1 线程

线程是依附于进程的，进程是分配资源的最小单位，一个进程可以生成多个线程，这些线程拥有共享的进程资源 。就每个线程而言，只有很少的独有资源， 如：控制线程运行的线程控制块，保留局部变量和少数参数的栈空间等。线程有就绪、阻塞和运行三种状态，并可以在这之间切换。也正因为多个线程会共享进程资源，所以当它们对同一个共享变量 / 对象进行操作的时候，线程的冲突和不一致性就产生了。

多线程并发环境下，本质上要解决地是这两个问题：

概括起来说就是：线程之间如何正确地通信。虽然说的是在 Java 层面如何保证，但会涉及到Java 虚拟机、Java 内存模型，以及 Java 这样的高级语言最终是要映射到 CPU 来执行（关键原因：如今的 CPU 有缓存、并且是多核的），虽然有些难懂，但对于深刻把握多线程是至关重要的，所以需要多花一些时间。

2.2 锁

当多个线程对同一个共享变量 / 对象进行操作，即使是最简单的操作，如：i++，在处理上实际也涉及到读取、自增、赋值这三个操作，也就是说 这中间存在时间差，导致多个线程没有按照如程序编写者所设想的去顺序执行，出现错位，从而导致最终结果与预期不一致。

Java 中的多线程同步是通过锁的概念来体现。锁不是一个对象、不是一个具体的东西，而是一种机制的名称。锁机制需要保证如下两种特性：

2.3 挂起、休眠、阻塞与非阻塞

挂起（Suspend）：当线程被挂起的时候，其会失去 CPU 的使用时间，直到被其他线程（用户线程或调度线程）唤醒。

休眠（Sleep）：同样是会失去 CPU 的使用时间，但是在过了指定的休眠时间之后，它会自动激活，无需唤醒（整个唤醒表面看是自动的，但实际上也得有守护线程去唤醒，只是不需编程者手动干预）。

阻塞（Block）：在线程执行时，所需要的资源不能得到，则线程被挂起，直到满足可操作的条件。

非阻塞 (Block)：在线程执行时， 所需要的资源不能得到，则线程不是被挂起等待 ，而是继续执行其余事情，待条件满足了之后， 收到了通知（同样是守护线程去做）再执行。

在 Java 中显式的挂起之前是通过 Thread 的 suspend 方法来体现，现在此概念已经消失，原因是 suspend/resume 方法已经被废弃，它们容易产生死锁，在 suspend 方法的注释里有这么一段话：当 suspend 的线程持有某个对象锁，而 resume 它的线程又正好需要使用此锁的时候，死锁就产生了。

所以，现在的 JDK 版本中，挂起是 JVM 的系统行为，程序员无需干涉 。休眠的过程中也不会释放锁，但它一定会在某个时间后被唤醒，所以不会死锁。 现在我们所说的挂起，往往并非指编写者的程序里主动挂起，而是由操作系统的线程调度器去控制。

所以，我们常常说的“线程在申请锁失败后会被挂起、然后等待调度”这样有一定歧义，因为这里的“挂起”是操作系统级别的挂起，其实是在申请资源失败时的阻塞，和 Java 中的线程的挂起（可能已经获得锁，也可能没有锁，总之和锁无关）不是一个概念，很容易混淆，所以在后文中说的挂起，一般指的是操作系统的操作，而不是 Thread 中的 suspend()。

相应地有必要提下 java.lang.Object 的 wait/notify，这两个方法同样是等待 / 通知，但它们的 前提是已经获得了锁，且在 wait（等待）期间会释放锁 。在 wait 方法的注释里明确提到： 线程要调用 wait 方法，必须先获得该对象的锁，在调用 wait 之后，当前线程释放该对象锁并进入休眠 （这里到底是进入休眠还是挂起？文档没有细说， 从该方法能指定等待时间来看，更可能是休眠，没有指定等待时间的，则可能是挂起，不管如何，在休眠 / 挂起之前，JVM 都会从当前线程中把该对象锁释放掉 ），只有以下几种情况下会被唤醒： 其他线程调用了该对象的 notify 或 notifyAll、当前线程被中断、调用 wait 时指定的时间已到。

2.4 内核态与用户态

这是两个操作系统的概念，但理解它们对我们理解 Java 的线程机制有着一定帮助。

有一些系统级的调用，比如：清除时钟、创建进程等这些系统指令，如果这些底层系统级指令能够被应用程序任意访问的话，那么后果是危险的，系统随时可能崩溃，所以CPU 将所执行的指令设置为多个特权级别，在硬件执行每条指令时都会校验指令的特权，比如：Intel x86 架构的 CPU 将特权分为 0 - 3 四个特权级，0 级的权限最高，3 权限最低。

而操作系统根据这系统调用的安全性分为两种：内核态和用户态 。 内核态执行的指令的特权是 0，用户态执行的指令的特权是 3 。

明白了内核态和用户态的概念之后，那么在这两种状态之间切换会造成什么样的效率影响？

那操作系统的这两种形态和我们的线程主题有什么关系呢？这里是关键。Java 并没有自己的线程模型，而是使用了操作系统的原生线程！

如果要实现自己的线程模型，那么有些问题就特别复杂，难以解决，比如：如何处理阻塞、如何在多 CPU 之间合理地分配线程、如何锁定，包括创建、销毁线程这些，都需要 Java 自己来做，在 JDK1.2 之前 Java 曾经使用过自己实现的线程模型，后来放弃了，转向使用操作系统的线程模型，因此创建、销毁、调度、阻塞等这些事都交由操作系统来做，而 线程方面的事在操作系统来说属于系统级的调用，需要在内核态完成，所以如果频繁地执行线程挂起、调度，就会频繁造成在内核态和用户态之间切换，影响效率（当然，操作系统的线程操作是不允许外界（包括 Java 虚拟机）直接访问的，而是开放了叫“轻量级进程”的接口供外界使用，其与内核线程在 Window 和 Linux 上是一对一的关系，这里不多叙述）。

3 线程优势

尽管面临很多挑战，多线程有一些优点使得它一直被使用。这些优点是：

3.1 资源利用率更好

CPU 能够在等待 IO 的时候做一些其他的事情。这个不一定就是磁盘 IO。它也可以是网络的 IO，或者用户输入。通常情况下，网络和磁盘的 IO 比 CPU 和内存的 IO 慢的多。

3.2 程序设计更简单

在单线程应用程序中，如果你想编写程序手动处理多个 IO 的读取和处理的顺序，你必须记录每个文件读取和处理的状态。相反，你可以启动两个线程，每个线程处理一个文件的读取和处理操作。线程会在等待磁盘读取文件的过程中被阻塞 。 在等待的时候，其他的线程能够使用 CPU 去处理已经读取完的文件。其结果就是，磁盘总是在繁忙地读取不同的文件到内存中。这会带来磁盘和 CPU 利用率的提升。而且每个线程只需要记录一个文件，因此这种方式也很容易编程实现。

3.3 程序响应更快速

将一个单线程应用程序变成多线程应用程序的另一个常见的目的是 实现一个响应更快的应用程序。设想一个服务器应用，它在某一个端口监听进来的请求。当一个请求到来时，它去处理这个请求，然后再返回去监听。

如果一个请求需要占用大量的时间来处理，在这段时间内新的客户端就无法发送请求给服务端。只有服务器在监听的时候，请求才能被接收。

另一种设计是，监听线程把请求传递给工作者线程池(worker thread pool)，然后立刻返回去监听。而工作者线程则能够处理这个请求并发送一个回复给客户端。

4 线程代价

使用多线程往往可以 获得更大的吞吐率和更短的响应时间 ，但是， 使用多线程不一定就比单线程程序跑的快 ，这取决于我们程序设计者的能力以及应用场景的不同。不要为了多线程而多线程，而应考虑具体的应用场景和开发实力， 使用多线程就是希望能够获得更快的处理速度和利用闲置的处理能力 ，如果没带来任何好处还带来了复杂性和一些定时炸弹，那就傻逼了？ 只有在使用多线程给我们带来的好处远大于我们付出的代价时，才考虑使用多线程。有时候可能引入多线程带来的性能提升抵不过多线程而引入的开销，一个没有经过良好并发设计得程序也可能比使用单线程还更慢。

4.1 设计更复杂

多线程程序在访问共享可变数据的时候往往需要我们很小心的处理，否则就会出现难以发现的 BUG，一般地，多线程程序往往比单线程程序设计会更加复杂（尽管有些单线程处理程序可能比多线程程序要复杂），而且错误很难重现（因为线程调度的无序性，某些 bug 的出现依赖于某种特定的线程执行时序）。

4.2 上下文切换开销

当 CPU 从执行一个线程切换到执行另外一个线程的时候，需要先存储当前线程的本地的数据，程序指针等，然后载入另一个线程的本地数据，程序指针等，最后才开始执行。这种切换称为“上下文切换”(“context switch”)。CPU 会在一个上下文中执行一个线程，然后切换到另外一个上下文中执行另外一个线程。

4.3 增加资源消耗

线程在运行的时候需要从计算机里面得到一些资源。除了 CPU，线程还需要一些内存来维持它本地的堆栈。它也需要占用操作系统中一些资源来管理线程。我们可以尝试编写一个程序，让它创建 100 个线程，这些线程什么事情都不做，只是在等待，然后看看这个程序在运行的时候占用了多少内存。

5 创建运行

编写线程运行时执行的代码有两种方式：一种是创建 Thread 子类的一个实例并重写 run 方法，第二种是创建类的时候实现 Runnable 接口。

5.1 创建 Thread 的子类

创建 Thread 子类的一个实例并重写 run 方法，run 方法会在调用 start()方法之后被执行。例子如下：

可以用如下方式创建并运行上述 Thread 子类:

一旦线程启动后 start 方法就会立即返回，而不会等待到 run 方法执行完毕才返回。就好像 run 方法是在另外一个 cpu 上执行一样。当 run 方法执行后，将会打印出字符串 MyThread running。

5.2 实现 Runnable 接口

第二种编写线程执行代码的方式是新建一个实现了 java.lang.Runnable 接口的类的实例，实例中的方法可以被线程调用。下面给出例子：

为了使线程能够执行 run()方法，需要在 Thread 类的构造函数中传入 MyRunnable 的实例对象。示例如下：

当线程运行时，它将会调用实现了 Runnable 接口的 run 方法。上例中将会打印出”MyRunnable running”。

5.3 创建子类还是实现 Runnable 接口？

对于这两种方式哪种好并没有一个确定的答案，它们都能满足要求。就个人意见，更倾向于实现 Runnable 接口这种方法。因为线程池可以有效的管理实现了 Runnable 接口的线程，如果线程池满了，新的线程就会排队等候执行，直到线程池空闲出来为止。而如果线程是通过实现 Thread 子类实现的，这将会复杂一些。

有时我们要同时融合实现 Runnable 接口和 Thread 子类两种方式。例如，实现了 Thread 子类的实例可以执行多个实现了 Runnable 接口的线程。一个典型的应用就是线程池。

5.4 常见错误：调用 run()方法而非 start()方法

创建并运行一个线程所犯的常见错误是调用线程的 run()方法而非 start()方法，如下所示：

起初你并不会感觉到有什么不妥，因为 run()方法的确如你所愿的被调用了。但是，事实上，run()方法并非是由刚创建的新线程所执行的，而是被创建新线程的当前线程所执行了 。也就是被执行上面两行代码的线程所执行的。 想要让创建的新线程执行 run()方法，必须调用新线程的 start()方法。

5.5 线程名

当创建一个线程的时候，可以给线程起一个名字。它有助于我们区分不同的线程。例如：如果有多个线程写入 System.out，我们就能够通过线程名容易的找出是哪个线程正在输出。例子如下：

需要注意的是，因为 MyRunnable 并非 Thread 的子类，所以 MyRunnable 类并没有 getName()方法。可以通过以下方式得到当前线程的引用：

因此，通过如下代码可以得到当前线程的名字：

首先输出执行 main()方法线程名字。这个线程 JVM 分配的。然后开启 10 个线程，命名为 1~10。每个线程输出自己的名字后就退出。

需要注意的是，尽管启动线程的顺序是有序的，但是执行的顺序并非是有序的。也就是说，1 号线程并不一定是第一个将自己名字输出到控制台的线程。这是因为线程是并行执行而非顺序的。JVM 和操作系统一起决定了线程的执行顺序，他和线程的启动顺序并非一定是一致的。

5.6 Main 线程与子线程关系

Main 线程是个非守护线程，不能设置成守护线程

这是因为，Main 线程是由 Java 虚拟机在启动的时候创建的 。main 方法开始执行的时候，主线程已经创建好并在运行了。对于运行中的线程， 调用 Thread.setDaemon()会抛出异常 Exception in thread “main”    java.lang.IllegalThreadStateException。

2.Main 线程结束，其他线程一样可以正常运行

主线程，只是个普通的非守护线程，用来启动应用程序，不能设置成守护线程；除此之外，它跟其他非守护线程没有什么不同。主线程执行结束，其他线程一样可以正常执行。

这样其实是很合理的，按照操作系统的理论，进程是资源分配的基本单位，线程是 CPU 调度的基本单位。对于 CPU 来说，其实并不存在 java 的主线程和子线程之分，都只是个普通的线程 。进程的资源是线程共享的，只要进程还在，线程就可以正常执行， 换句话说线程是强依赖于进程的。也就是说：

3.Main 线程结束，其他线程也可以立刻结束，当且仅当这些子线程都是守护线程

Java 虚拟机（相当于进程）退出的时机是：虚拟机中所有存活的线程都是守护线程 。只要还有存活的非守护线程虚拟机就不会退出，而是等待非守护线程执行完毕；反之， 如果虚拟机中的线程都是守护线程，那么不管这些线程的死活 java 虚拟机都会退出。

6 再聊并发与并行

并发和并行的区别就是 一个处理器同时处理多个任务 和多个处理器或者是多核的处理器同时处理多个不同的任务 。 前者是逻辑上的同时发生（simultaneous），而后者是物理上的同时发生。

上图反映了一个包含 8 个操作的任务在一个有两核心的 CPU 中创建四个线程运行的情况。假设每个核心有两个线程，那么每个 CPU 中两个线程会交替并发，两个 CPU 之间的操作会并行运算。单就一个 CPU 而言两个线程可以解决线程阻塞造成的不流畅问题，其本身运行效率并没有提高，多 CPU 的并行运算才真正解决了运行效率问题，这也正是并发和并行的区别。