java多线程实战篇（Java并发编程的艺术开篇）

目录：

一、多线程概念

并发与并行

进程与线程

二. 并发编程的挑战

上下文切换

死锁

资源限制的挑战

一、多线程概念1. 并发与并行

“并发”指的是程序的结构，“并行”指的是程序运行时的状态

即使不看详细解释，也请记住这句话。下面来具体说说：

并行（parallelism）

这个概念很好理解。所谓并行，就是同时执行的意思，无需过度解读。判断程序是否处于并行的状态，就看同一时刻是否有超过一个“工作单位”在运行就好了。所以，单线程永远无法达到并行状态。

要达到并行状态，最简单的就是利用多线程和多进程。但是 Python 的多线程由于存在著名的 GIL，无法让两个线程真正“同时运行”，所以实际上是无法到达并行状态的。

并发（concurrency）

要理解“并发”这个概念，必须得清楚，并发指的是程序的“结构”。当我们说这个程序是并发的，实际上，这句话应当表述成“这个程序采用了支持并发的设计”。好，既然并发指的是人为设计的结构，那么怎样的程序结构才叫做支持并发的设计？

正确的并发设计的标准是：使多个操作可以在重叠的时间段内进行

(two tasks can start, run, and complete in overlapping time periods)。

这句话的重点有两个。我们先看“（操作）在重叠的时间段内进行”这个概念。它是否就是我们前面说到的并行呢？是，也不是。并行，当然是在重叠的时间段内执行，但是另外一种执行模式，也属于在重叠时间段内进行。这就是协程。

使用协程时，程序的执行看起来往往是这个样子：

task1, task2 是两段不同的代码，比如两个函数，其中黑色块代表某段代码正在执行。注意，这里从始至终，在任何一个时间点上都只有一段代码在执行，但是，由于 task1 和 task2 在重叠的时间段内执行，所以这是一个支持并发的设计。与并行不同，单核单线程能支持并发。

经常看到这样一个说法，叫做并发执行。现在我们可以正确理解它。有两种可能：

1. 原本想说的是“并行执行”，但是用错了词

2. 指多个操作可以在重叠的时间段内进行，即，真的并行，或是类似上图那样的执行模式。

我的建议是尽可能不使用这个词，容易造成误会，尤其是对那些并发并行不分的人。但是读到这里的各位显然能正确区分，所以下面为了简便，将使用并发执行这个词。

第二个重点是“可以在重叠的时间段内进行”中的“可以”两个字。“可以”的意思是，正确的并发设计使并发执行成为可能，但是程序在实际运行时却不一定会出现多个任务执行时间段 overlap 的情形。比如：我们的程序会为每个任务开一个线程或者协程，只有一个任务时，显然不会出现多个任务执行时间段重叠的情况，有多个任务时，就会出现了。这里我们看到，并发并不描述程序执行的状态，它描述的是一种设计，是程序的结构，比如上面例子里“为每个任务开一个线程”的设计。并发设计和程序实际执行情况没有直接关联，但是正确的并发设计让并发执行成为可能。反之，如果程序被设计为执行完一个任务再接着执行下一个，那就不是并发设计了，因为做不到并发执行。

那么，如何实现支持并发的设计？两个字：拆分。

之所以并发设计往往需要把流程拆开，是因为如果不拆分也就不可能在同一时间段进行多个任务了。这种拆分可以是平行的拆分，比如抽象成同类的任务，也可以是不平行的，比如分为多个步骤。

并发和并行的关系

Different concurrent designs enable different ways to parallelize.

这句话来自著名的talk: Concurrency is not parallelism。它足够concise，以至于不需要过多解释。但是仅仅引用别人的话总是不太好，所以我再用之前文字的总结来说明：并发设计让并发执行成为可能，而并行是并发执行的一种模式。

2. 线程与进程

2.1 什么是进程？为什么要有进程？

一个在内存中运行的应用程序。每个进程都有自己独立的一块内存空间，一个进程可以有多个线程，比如在Windows系统中，一个运行的xx.exe就是一个进程。

进程有一个相当精简的解释：进程是对操作系统上正在运行程序的一个抽象。

这个概念确实挺抽象，仔细想想却也挺精准。

我们平常使用计算机，都会在同一时间做许多事，比如边看电影，边微信聊天，顺便打开浏览器百度搜索一下，我们所做的这么多事情背后都是一个个正在运行中的软件程序；这些软件想要运行起来，首先在磁盘上需要有各自的程序代码，然后将代码加载到内存中，cpu会去执行这些代码，运行中会产生很多数据需要存放，也可能需要和网卡、显卡、键盘等外部设备交互，这背后其实就涉及到程序对计算机资源的使用，存在这么多程序，我们当然需要想办法管理程序资源的使用。并且CPU如果只有一个，那么还需要操作系统调度CPU分配给各个程序使用，让用户感觉这些程序在同时运行，不影响用户体验。

理所当然，操作系统会把每个运行中的程序封装成独立的实体，分配各自所需要的资源，再根据调度算法切换执行。这个抽象程序实体就是进程。

所以很多对进程的官方解释中都会提到：进程是操作系统进行资源分配和调度的一个基本单位。

2.2 什么是线程？为什么要有线程？

在早期的操作系统中并没有线程的概念，进程是拥有资源和独立运行的最小单位，也是程序执行的最小单位。任务调度采用的是时间片轮转的抢占式调度方式，而进程是任务调度的最小单位，每个进程有各自独立的内存空间，使得各个进程之间内存地址相互隔离。

后来，随着计算机行业的发展，程序的功能设计越来越复杂，我们的应用中同时发生着多种活动，其中某些活动随着时间的推移会被阻塞，比如网络请求、读写文件（也就是IO操作），我们自然而然地想着能不能把这些应用程序分解成更细粒度、能 准并行运行 多个顺序执行实体，并且这些细粒度的执行实体可以共享进程的地址空间，也就是可以共享程序代码、数据、内存空间等，这样程序设计模型会变得更加简单。

其实很多计算机世界里的技术演变，都是模拟现实世界。比如我们把一个进程当成一个项目，当项目任务变得复杂时，自然想着能不能将项目按照业务、产品、工作方向等分成一个个任务模块，分派给不同人员各自并行完成，再按照某种方式组织起各自的任务成果，最终完成项目。

需要多线程还有一个重要的理由就是：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器，线程之间切换的开销小。所以线程的创建、销毁、调度性能远远优于进程。

在引入多线程模型后，进程和线程在程序执行过程中的分工就相当明确了，进程负责分配和管理系统资源，线程负责CPU调度运算，也是CPU切换时间片的最小单位。对于任何一个进程来讲，即便我们没有主动去创建线程，进程也是默认有一个主线程的。进程中的一个执行任务（控制单元），负责当前进程中程序的执行。一个进程至少有一个线程，一个进程可以运行多个线程，多个线程可共享数据。

与进程不同的是同类的多个线程共享进程的堆和方法区资源，但每个线程有自己的程序计数器、虚拟机栈和本地方法栈，所以系统在产生一个线程，或是在各个线程之间作切换工作时，负担要比进程小得多，也正因为如此，线程也被称为轻量级进程。

Java 程序天生就是多线程程序，我们可以通过 JMX 来看一下一个普通的 Java 程序有哪些线程，代码如下。

public class MultiThread { public static void main(String[] args) { // 获取 java 线程管理 MXBean ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); // 不需要获取同步的 monitor 和 synchronizer 信息，仅获取线程和线程堆栈信息 ThreadInfo[] threadInfos = threadMXBean.dumpAllThreads(false, false); // 遍历线程信息，仅打印线程 ID 和线程名称信息 for (ThreadInfo threadInfo : threadInfos) { System.out.println("[" threadInfo.getThreadId() "] " threadInfo.getThreadName()); } } }

上述程序输出如下（输出内容可能不同，不用太纠结下面每个线程的作用，只用知道 main 线程执行 main 方法即可）：

[6] Monitor Ctrl-Break //监听线程转储或“线程堆栈跟踪”的线程

[5] Attach Listener //负责接收到外部的命令，而对该命令进行执行的并且把结果返回给发送者

[4] Signal Dispatcher // 分发处理给 JVM 信号的线程

[3] finalizer //在垃圾收集前，调用对象 finalize 方法的线程

[2] Reference Handler //用于处理引用对象本身（软引用、弱引用、虚引用）的垃圾回收的线程

[1] main //main 线程,程序入口

从上面的输出内容可以看出：一个 Java 程序的运行是 main 线程和多个其他线程同时运行。

2.3 它们在Linux内核中实现方式有何不同？

在Linux 里面，无论是进程，还是线程，到了内核里面，我们统一都叫任务（Task），由一个统一的结构 task_struct 进行管理，这个task_struct 数据结构非常复杂，囊括了进程管理生命周期中的各种信息。

在Linux操作系统内核初始化时会创建第一个进程，即0号创始进程。随后会初始化1号进程（用户进程祖宗：/usr/lib/systemd/systemd），2号进程（内核进程祖宗：[kthreadd]），其后所有的进程线程都是在他们的基础上fork出来的。

我们一般都是通过fork系统调用来创建新的进程，fork 系统调用包含两个重要的事件，一个是将 task_struct 结构复制一份并且初始化，另一个是试图唤醒新创建的子进程。

我们说无论是进程还是线程，在内核里面都是task，管起来不是都一样吗？到底如何区分呢？其实，线程不是一个完全由内核实现的机制，它是由内核态和用户态合作完成的。

创建进程的话，调用的系统调用是 fork，会将五大结构 files_struct、fs_struct、sighand_struct、signal_struct、mm_struct 都复制一遍，从此父进程和子进程各用各的数据结构。而创建线程的话，调用的是系统调用 clone，五大结构仅仅是引用计数加一，也即线程共享进程的数据结构。

2.4 并发与并行的区别？

功能： 进程是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位

开销： 每个进程都有独立的内存空间，存放代码和数据段等，程序之间的切换会有较大的开销；线程可以看做轻量级的进程，共享内存空间，每个线程都有自己独立的运行栈和程序计数器，线程之间切换的开销小。

运行环境： 在操作系统中能同时运行多个进程；而在同一个进程（程序）中有多个线程同时执行（通过CPU调度，在每个时间片中只有一个线程执行）

创建过程： 在创建新进程的时候，会将父进程的所有五大数据结构复制新的，形成自己新的内存空间数据，而在创建新线程的时候，则是引用进程的五大数据结构数据，但是线程会有自己的私有数据、栈空间。

进程和线程其实在cpu看来都是task_struct结构的一个封装，执行不同task即可，而且在cpu看来就是在执行这些task时候遵循对应的调度策略以及上下文资源切换定义，包括寄存器地址切换，内核栈切换。所以对于cpu而言，进程和线程是没有区别的。

并发编程的挑战

并发编程的目的是为了让程序运行得更快，但是，并不是启动更多的线程就能让程序最大限度地并发执行。在进行并发编程时，如果希望通过多线程执行任务让程序运行得更快，会面临非常多的挑战，比如上下文切换的问题、死锁的问题，以及受限于硬件和软件的资源限制问题，本章会介绍几种并发编程的挑战以及解决方案。

上下文切换

即使是单核处理器也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程是同时执行的，时间片一般是几十毫秒（ms）。

CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。

这就像我们同时读两本书，当我们在读一本英文的技术书时，发现某个单词不认识，于是便打开中英文字典，但是在放下英文技术书之前，大脑必须先记住这本书读到了多少页的第多少行，等查完单词之后，能够继续读这本书。这样的切换是会影响读书效率的，同样上下文切换也会影响多线程的执行速度。

多线程一定快吗？

下面的代码演示串行和并发执行并累加操作的时间，请分析：下面的代码并发执行一定比串行执行快吗？

public class ConcurrencyTest { private static final long count = 10000l; public static void main(String[] args) throws InterruptedException { concurrency(); serial(); } private static void concurrency() throws InterruptedException { long start = System.currentTimeMillis(); Thread thread = new Thread(new Runnable() { @Override public void run() { int a = 0; for (long i = 0; i < count; i ) { a = 5; } } }); thread.start(); int b = 0; for (long i = 0; i < count; i ) { b--; } long time = System.currentTimeMillis() - start; thread.join(); System.out.println("concurrency :" time "ms,b=" b); } private static void serial() { long start = System.currentTimeMillis(); int a = 0; for (long i = 0; i < count; i ) { a = 5; } int b = 0; for (long i = 0; i < count; i ) { b--; } long time = System.currentTimeMillis() - start; System.out.println("serial:" time "ms,b=" b ",a=" a); } }

上述问题的答案是“不一定”，测试结果如表1-1所示。

表1-1 测试结果

表1-1 测试结果

从表1-1可以发现，当并发执行累加操作不超过百万次时，速度会比串行执行累加操作要慢。那么，为什么并发执行的速度会比串行慢呢？这是因为线程有创建和上下文切换的开销。

测试上下文切换次数和时长

下面我们来看看有什么工具可以度量上下文切换带来的消耗。

使用Lmbench3[1]可以测量上下文切换的时长。

使用vmstat可以测量上下文切换的次数。

下面是利用vmstat测量上下文切换次数的示例。

$ vmstat 1

proCS -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

r	b	swpd	free	buff	cache	si	so	bi	bo	in	cs	us	sy	id	wa	st
0	0	0	127876	398928	2297092	0	0	0	4	2	2	0	0	99	0	0
0	0	0	127868	398928	2297092	0	0	0	0	595	1171	0	1	99	0	0
0	0	0	127868	398928	2297092	0	0	0	0	590	1180	1	0	100	0	0

CS（Content Switch）表示上下文切换的次数，从上面的测试结果中我们可以看到，上下文每1秒切换1000多次。

如何减少上下文切换

减少上下文切换的方法有无锁并发编程、CAS算法、使用最少线程和使用协程。

·无锁并发编程。多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash算法取模分段，不同的线程处理不同段的数据。

·CAS算法。Java的Atomic包使用CAS算法来更新数据，而不需要加锁。

·使用最少线程。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。

·协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

减少上下文切换实战

通过减少线上大量WAITING的线程，来减少上下文切换次数。

第一步：用jstack命令dump线程信息，看看pid为3117的进程里的线程都在做什么。

sudo -u admin /opt/ifeve/java/bin/jstack 31177 > /home/tengfei.fangtf/dump17

第二步：统计所有线程分别处于什么状态，发现300多个线程处于WAITING（onobject- monitor）状态。

[tengfei.fangtf@ifeve ~]$ grep java.lang.Thread.State dump17 | awk '{print $2$3$4$5}'

| sort | uniq -c

39 RUNNABLE

21 TIMED_WAITING(onobjectmonitor)

6 TIMED_WAITING(parking)

51 TIMED_WAITING(sleeping)

305 WAITING(onobjectmonitor)

3 WAITING(parking)

第三步：打开dump文件查看处于WAITING（onobjectmonitor）的线程在做什么。发现这些线程基本全是JBOSS的工作线程，在await。说明JBOSS线程池里线程接收到的任务太少，大量线程都闲着。

"http-0.0.0.0-7001-97" daemon prio=10 tid=0x000000004f6a8000 nid=0x555e in Object.wait() [0x0000000052423000]

java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method)

-waiting on <0x00000007969b2280> (a org.apache.tomcat.util.AprEndpoint$Worker) at java.lang.Object.wait(Object.java:485)

at org.apache.tomcat.util.AprEndpoint$Worker.await(AprEndpoint.java:1464)

-locked <0x00000007969b2280> (a org.apache.tomcat.util.AprEndpoint$Worker) at org.apache.tomcat.util.AprEndpoint$Worker.run(AprEndpoint.java:1489)

at java.lang.Thread.run(Thread.java:662)

第四步：减少JBOSS的工作线程数，找到JBOSS的线程池配置信息，将maxThreads降到

100。

<maxThreads="250" maxHttpHeaderSize="8192" emptySessionPath="false" minSpareThreads="40" maxSpareThreads="75"

maxPostSize="512000" protocol="HTTP/1.1"

enableLookups="false" redirectPort="8443" acceptCount="200" bufferSize="16384" connectionTimeout="15000" disableUploadTimeout="false" useBodyEncodingForURI= "true">

第五步：重启JBOSS，再dump线程信息，然后统计WAITING（onobjectmonitor）的线程，发现减少了175个。WAITING的线程少了，系统上下文切换的次数就会少，因为每一次从WAITTING到RUNNABLE都会进行一次上下文的切换。读者也可以使用vmstat命令测试一下。

[tengfei.fangtf@ifeve ~]$ grep java.lang.Thread.State dump17 | awk '{print $2$3$4$5}'

| sort | uniq -c

44 RUNNABLE

22 TIMED_WAITING(onobjectmonitor)

9 TIMED_WAITING(parking)

36 TIMED_WAITING(sleeping)

130 WAITING(onobjectmonitor)

1 WAITING(parking)

死锁

锁是个非常有用的工具，运用场景非常多，因为它使用起来非常简单，而且易于理解。但同时它也会带来一些困扰，那就是可能会引起死锁，一旦产生死锁，就会造成系统功能不可用。让我们先来看一段代码，这段代码会引起死锁，使线程t1和线程t2互相等待对方释放锁。

public class DeadLockDemo { privat static String A = "A"; private static String B = "B"; public static void main(String[] args) { new DeadLockDemo().deadLock(); } private void deadLock() { Thread t1 = new Thread(new Runnable() { @Override publicvoid run() { synchronized (A) { try { Thread.currentThread().sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } synchronized (B) { System.out.println("1"); } } } }); Thread t2 = new Thread(new Runnable() { @Override publicvoid run() { synchronized (B) { synchronized (A) { System.out.println("2"); } } } }); t1.start(); t2.start(); } }

这段代码只是演示死锁的场景，在现实中你可能不会写出这样的代码。但是，在一些更为

复杂的场景中，你可能会遇到这样的问题，比如t1拿到锁之后，因为一些异常情况没有释放锁

（死循环）。又或者是t1拿到一个数据库锁，释放锁的时候抛出了异常，没释放掉。

一旦出现死锁，业务是可感知的，因为不能继续提供服务了，那么只能通过dump线程查看到底是哪个线程出现了问题，以下线程信息告诉我们是DeadLockDemo类的第42行和第31行引起的死锁。

"Thread-2" prio=5 tid=7fc0458d1000 nid=0x116c1c000 waiting for monitor entry [116c1b00 java.lang.Thread.State: BLOCKED (on object monitor)

at com.ifeve.book.forkjoin.DeadLockDemo$2.run(DeadLockDemo.java:42)

-waiting to lock <7fb2f3ec0> (a java.lang.String)

-locked <7fb2f3ef8> (a java.lang.String) at java.lang.Thread.run(Thread.java:695)

"Thread-1" prio=5 tid=7fc0430f6800 nid=0x116b19000 waiting for monitor entry [116b1800 java.lang.Thread.State: BLOCKED (on object monitor)

at com.ifeve.book.forkjoin.DeadLockDemo$1.run(DeadLockDemo.java:31)

-waiting to lock <7fb2f3ef8> (a java.lang.String)

-locked <7fb2f3ec0> (a java.lang.String) at java.lang.Thread.run(Thread.java:695)

现在我们介绍避免死锁的几个常见方法。

·避免一个线程同时获取多个锁。

·避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源。

·尝试使用定时锁，使用lock.tryLock（timeout）来替代使用内部锁机制。

·对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况。

资源限制的挑战

（1）什么是资源限制

资源限制是指在进行并发编程时，程序的执行速度受限于计算机硬件资源或软件资源。例如，服务器的带宽只有2Mb/s，某个资源的下载速度是1Mb/s每秒，系统启动10个线程下载资 源，下载速度不会变成10Mb/s，所以在进行并发编程时，要考虑这些资源的限制。硬件资源限制有带宽的上传/下载速度、硬盘读写速度和CPU的处理速度。软件资源限制有数据库的连接数和socket连接数等。

（2）资源限制引发的问题

在并发编程中，将代码执行速度加快的原则是将代码中串行执行的部分变成并发执行， 但是如果将某段串行的代码并发执行，因为受限于资源，仍然在串行执行，这时候程序不仅不会加快执行，反而会更慢，因为增加了上下文切换和资源调度的时间。例如，之前看到一段程序使用多线程在办公网并发地下载和处理数据时，导致CPU利用率达到100%，几个小时都不能运行完成任务，后来修改成单线程，一个小时就执行完成了。

（3）如何解决资源限制的问题

对于硬件资源限制，可以考虑使用集群并行执行程序。既然单机的资源有限制，那么就让程序在多机上运行。比如使用ODPS、Hadoop或者自己搭建服务器集群，不同的机器处理不同的数据。可以通过“数据ID%机器数”，计算得到一个机器编号，然后由对应编号的机器处理这笔数据。

对于软件资源限制，可以考虑使用资源池将资源复用。比如使用连接池将数据库和Socket 连接复用，或者在调用对方webservice接口获取数据时，只建立一个连接。

（4）在资源限制情况下进行并发编程

如何在资源限制的情况下，让程序执行得更快呢？方法就是，根据不同的资源限制调整程序的并发度，比如下载文件程序依赖于两个资源——带宽和硬盘读写速度。有数据库操作时，涉及数据库连接数，如果SQL语句执行非常快，而线程的数量比数据库连接数大很多，则某些线程会被阻塞，等待数据库连接。

,