并发的基础概念以及优缺点

一. 为什么要有并发

首先我们应该了解什么是并发，很多时候我们在工作的过程当中，习惯会以单线程的思维来进行项目开发，因为这种方式是最易于理解的，也是最不容易出错的。

当然，这种编程方式在项目简单，并且用户访问量并不大的情况下可以发挥较好的作用，但是只要项目迭代到某个高级阶段，或者说因为比较好的推广，项目得到了比较多用户的使用，这种时候，项目中单线程的处理方式一定会出现处理效率上的瓶颈，常见的问题就是响应速度变慢，也就是处理速度会变慢，那这个时候如果将原来单线程的任务改成多线程的方式处理，则可以大大地提升处理效率。

二. 并发与并行的区别

在这边，我们首先要理清并发与并行两者的区别。我们讲的并发其实主要是一段时间内，多个事件同时对一个任务进行处理，而并行则是同一个时间点，会有多个事件同时处理。

举个通俗点的例子：现在有一个客人订了3杯咖啡并且店里面有3个人，那完成这些咖啡有两个思路，第一个是，三个人每个人轮流沏一杯咖啡，直到一杯咖啡沏完，再接下去三个人同时轮流沏另一杯咖啡。第二个思路则是，三个人每人都自己沏自己的咖啡。

从图中其实可以看到，并发其实就是多个线程争抢一个任务，而并行则不会抢占资源，每一个任务都是由自己的线程单独处理的。

三. 并发编程的优点

并发编程也就是多线程编程，在实际使用中有许多的优点，毕竟如果没有优点也不会使用了。

1. 充分地利用多核 CPU 的好处

现代处理器上核心数量越来越多的情况下，计算机的并行计算能力被大大地加强了。而单线程只使用了一个处理器核心，其它的核心一直在空闲这，那多核的能力就无法得到充分地利用，处理器的使用率就远远达不到想象中的状态。

2. 提高系统的响应速度

并发编程在任务处理上的效率远远大于单线程，就像一个人可以分成许多个克隆人一起完成一个任务，人增加了，速度自然就提升上来了。

比如在下载文件的时候，在单线程的情况下，只能一行一行的进行文件内容数据的拼接与处理，而如果使用多线程，那系统就可以将一个文件中多行数据分配给不同的线程处理，最后再进行内容整合并展示给用户，大大的提高了单个任务的处理效率。如果将这种多线程的思想用到其它业务流程上，那系统的整体性能就会有一个飞跃性的提升。这也就是为什么复杂系统上，使用多线程处理任务一定会有着极大的使用率。

四. 并发编程的缺点

虽然在上面说道多线程会加快任务的处理，但是多线程一定会很快吗，也就是说多线程是否在某些情况下会比单线程的效率低？

答案是多线程并不一定会比单线程快。其中有两个有可能导致并发处理任务速度减慢或者失败的原因是：上下文切换和死锁。

1. 上下文切换

什么是上下文切换？CPU 通过时间片分配算法来循环执行任务，通过给每个线程分配 CPU 时间片来支持多线程的运行。时间片是 CPU 分配给每个线程的时间，一般时间片是几十毫秒，通过给每个线程分配时间片，并且在很短的时间内从一个任务切换到下一个任务，在切换之前会保存一次任务状态，并且下一次切换回这个任务时又加载状态并执行了这个任务，这一次过程就是上下文切换。

从定义中就可以猜想，是否是因为线程切换的原因导致了某些情况多线程比单线程处理任务的速度还要慢？在下面的代码中分别对单线程和多线程进行效率上的对比。

public class ThreadTest {  
  
    private static final long maxCount = 1000L;  
  
    /**  
     * 并发  
     */  
    public static long concurrency() {  
        long start = System.nanoTime();  
  
        // 新开一个线程执行任务  
        Thread thread = new Thread(() -> {  
            for (long i = 0; i < maxCount; i++) {  
                int x = 0;  
                x += 1;  
            }  
        });  
        thread.start();  
  
        // 原线程处理其他任务  
        int y = 0;  
        for (long i = 0; i < maxCount; i++) {  
            y += 1;  
        }  
  
        try {  
            // 等待新开启的线程结束任务  
            thread.join();  
        } catch (InterruptedException e) {  
            e.printStackTrace();  
        }  
  
        return System.nanoTime() - start;  
    }  
  
    /**  
     * 串行  
     */  
    public static long serial() {  
        long start = System.nanoTime();  
        int x = 0;  
        for (int i = 0; i < maxCount; i++) {  
            x += 1;  
        }  
  
        int y = 0;  
        for (long i = 0; i < maxCount; i++) {  
            y += 1;  
        }  
  
        return System.nanoTime() - start;  
    }  
  
    public static void main(String[] args) {  
        long concurrencyTime = concurrency();  
        long serialTime = serial();  
        System.out.println("concurrency:" + concurrencyTime + "ns");  
        System.out.println("serial:" + serialTime + "ns");  
        System.out.println("比例: " + (double) concurrencyTime / serialTime);  
    }  
}

由上面代码试验可以得出下边的表格：

循环次数	串行消耗 ns	并发消耗 ns	并发 / 串行
一千	17000	26866200	1580
一万	154600	27523600	178
十万	728000	28082300	38
一百万	1978200	27735400	14
一千万	7670800	30655900	3
一亿	60337400	56802800	0.94
十亿	560401600	317215700	0.566

可以从表格中看到，在循环次数不大的情况下，比如在循环一百万次之前，其实并发并没有很大的优势，相反还可能出现比串行还要慢。在循环次数一亿以上，并发的优势才能体现出来。当然展示的例子当中的任务比较简单，所以实际情况还要自己去验证。

所以从上面的例子中看到，并发中上下文的切换有时候消耗的资源远比想象中的要高，所以尽量在需要的情况下再去对任务进行并发优化。

既然上下文切换也会消耗资源，降低效率，那如何来减少上下文切换？有四种方法：使用无锁并发编程、CAS算法、协程以及减少线程。

• 无锁并发编程：一份数据分成多段，并且使用不同的线程处理分别处理这些数据。
• CAS 算法：Unsafe 类中有相关的 CAS 方法，可以不使用锁，java.util.concurrent.atomic包下有使用 CAS 的各种原子操作类。
• 协程：协程是一种比线程更加轻量级的存在，一个线程可以有多个协程。
• 减少线程：线程并不是越多越好，而是有一个合适的范围，需要根据硬件资源来决定，通常线程数量是 CPU 核心数量 + 1。

2. 死锁

在之后会讲到为了解决原子性问题会涉及到锁的使用，但是锁的使用也是会出现 BUG，比如著名的死锁问题。我们常说的 synchronized 和 Lock 都是加锁思想的不同体现，两者各有侧重点，虽然两者实现方式不一样，但其实都是解决同一个问题。

那什么是死锁？死锁从字面解释上来讲比较难以理解，那这时候可以借鉴现实的场景来理解死锁的概念。我们想象两个人想要泡咖啡，结果一个人拿水壶，一个人拿杯子，两个人僵持着谁也不先放弃，那这时候泡咖啡任务就不能完成，而且水壶和杯子被两个人持有但又不放开，这种就是死锁问题。

用伪代码表示出来就是：两个人就是两个线程，每个线程都持有了一个锁，然后互不想让，最终导致泡咖啡这件任务永远无法完成。

private Object 咖啡;  
  
void 泡咖啡() {  
    synchronized (杯子) {  
        synchronized (水壶) {  
            泡咖啡;  
        }  
    }  
}

五. 并发编程还会出现什么问题

在了解了并发的优缺点以后，并不是一劳永逸了，如果不能正确理解并发编程的底层原理，还是会出现很多 BUG。

并发编程出现 BUG 的源头

我们常遇到 BUG 的源头主要有三个：原子性、有序性、可见性。为了解决这三种情况，Java 自带了 synchronized、volatile、final关键词和 Happens-Before 的六项规则来解决这三个问题。

1. 可见性问题

多个线程共同修改一个共享变量时，一个线程修改的变量结果能马上被其他线程获取到。
导致原因：缓存

很多人都知道，我们目前的计算机体系里面，CPU、内存和硬盘之间一直有着明显的速度差异，就比如 CPU 的执行速度远远大于内存，那这时候为了缓解这中间的速度差异，CPU 中又增加了缓存。并且 CPU 中不同的线程的共享变量其实都是放在同一个缓存当中，每个线程如果想对共享变量进行操作，都要去同一个缓存中获取并修改。

在单核时代，不同的线程反正都源于一个 CPU，那这时候问题不大。但是，在多核 CPU 的时代下，每个 CPU 都有着自己的缓存，每个缓存又到同一个内存中去获取共享变量的值（当然我们这边暂时不考虑缓存有几级），那这时候每个缓存都保存了不同的值，如果一个 CPU 中的线程修改了自己的缓存，这时候其它 CPU 的线程无法获取到那个 CPU 中的变量的值，这时候就会出现可见性问题，也就是说一个 CPU 中的线程无法观察到另一个 CPU 中的操作。

2. 原子性问题

原子性比较好理解，就是一个操作或多个操作只能全部完成或者全部失败，而不能出现完成一半的情况。
导致原因：线程切换

在上面讲到上下文切换的时候提到 CPU 是通过给每个线程分配时间片来实现多线程的运行，那这时候就涉及到线程的切换，然而就是因为线程的切换，所以才导致了原子性问题的出现。

我们在平常编写的代码虽然看起来有时候是一条语句，但其实在 CPU 层面是分为多条指令执行的，比如 i += 1;，虽然我们的第一反应直接是 i 加上 1，但实际是三条指令：1. 获取内存中 i 变量的值，2. i 加上 1，3. 再将 i 的值写入内存。这种其实就是违背直觉的地方。

我们再将分配时间片和 CPU 指令结合来看，因为线程所分配时间片长度的不确定性，所以每一条线程具体执行到哪个地方其实我们是不知道的，这时候如果有两个线程去争抢三个指令的操作过程，就会有可能导致线程 A 获取到执行权并读取了第一步中 i 变量的值，这时候 CPU 又将操作权给了线程 B，线程 B 从又执行了第一中读取变量 i 的值，这时候两者读取的值同是 0，那最后两个线程各自执行第二步，每个线程中 i 的值都是 1，

所以我们解决原子性问题就是需要从高级语言层面来解决这种差异性，Java 中就是使用了 synchronized 和 Lock 接口来解决问题。

3. 有序性问题

程序的结果依赖代码的执行顺序，而编译器有可能会优化这一顺序，所以可能会导致程序的结果不符目标结果。
导致原因：编译优化

在平常编写的程序中，编译器并不一定会一定按照程序的语句执行，而是有可能对程序语句进行优化，虽然编译优化的原则是会对没有数据依赖关系的语句做重排序，但是，这只限制在单线程程序里面没有问题，而如果是多线程的程序，因为不同的线程在不同的 CPU 中，导致单独 CPU 中的程序重排序没问题，但是两个 CPU 结合来看，编译重排序就会出现程序的指令顺序不符合我们想要的顺序。