并发的挑战

在多核时代，多线程对系统的性能提升有着巨大的作用，但是多线程对系统也相应的产生了额外的开销，并不是启动更多的线程就能让程序最大限度地并发执行；线程本身的数据、线程的调度、线程的申请释放等都对系统的产生额外的负担。在进行并发编程时，如果希望通过多线程执行任务让程序运行得更快，会面临非常多的挑战，比如上下文切换的问题、死锁的问题，以及受限于硬件和软件的资源限制问题。遇到线程的活跃性问题的并发程序，被称为(Poor Concurrency)应用程序：

上下文切换带来的线程开销：线程虽然比进程轻量，但是线程的管理仍然需要消耗一定的系统资源。比如线程上下文切换，需要 5000~10000 个时钟周期，大约是几微秒，如果线程上下文切换过于频繁，就会对活跃性造成影响。
阻塞：当线程被不恰当地置为阻塞状态时，后续的指令得不到执行，于是就会出现活跃性问题。
死锁：死锁是最常见的活跃性风险。当两个线程互相等待对方持有的资源时，就会发生死锁。不恰当的加锁解锁顺序，以及错误的资源管理策略，都有可能导致死锁。死锁往往出现在最糟糕的时候：高负载的情形。
活锁：当线程不断地重试某个失败的操作时，就会发生活锁。此时线程虽然不会被阻塞，但也不能继续执行。

要避免线程活跃性问题，需要我们对并发机制有深刻了解，并养成良好的并发编程习惯。常见的解决并发活跃性问题的手段有:

避免使用锁。这是釜底抽薪、从源头解决的问题的办法。没有买卖就没有伤害，没有锁就不会陷入单线程执行模式，就不会有线程活跃性问题。可以使用上文提到的避免可变状态、避免共享状态等手段，来规避对锁的使用。
降低锁的粒度。如果加锁不可避免，那么可以尝试降低锁的粒度，只在确实需要使用锁的地方才使用它。比如可以在一个方法内部，只对其中的某几行代码，引入 synchornized 对代码块进行同步。
加上超时限制。并发程序可能会以出乎意料的方式，陷入长时间的锁等待，甚至是死锁。作为止血方案，可以使用显示锁(Lock 类)，并指定超时时限（Timeout），在超过该时间之后就返回一个失败信息，避免永久等待。

上下文切换

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

CPU 通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。这就像我们同时读两本书，当我们在读一本英文的技术书时，发现某个单词不认识，于是便打开中英文字典，但是在放下英文技术书之前，大脑必须先记住这本书读到了多少页的第多少行，等查完单词之后，能够继续读这本书。这样的切换是会影响读书效率的，同样上下文切换也会影响多线程的执行速度。

多线程不一定快

public class ConcurrencyTest {
    private static final long count = 10000 l;
    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);
    }
}

上述问题的答案是“不一定”，测试结果如下所示：

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

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

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

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

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

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

如何减少上下文切换

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

无锁并发编程。多线程竞争锁时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的 ID 按照 Hash 算法取模分段，不同的线程处理不同段的数据。
CAS 算法。Java 的 Atomic 包使用 CAS 算法来更新数据，而不需要加锁。
使用最少线程。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。
协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

死锁

锁是个非常有用的工具，运用场景非常多，因为它使用起来非常简单，而且易于理解。但同时它也会带来一些困扰，那就是可能会引起死锁，一旦产生死锁，就会造成系统功能不可用。让我们先来看一段代码，这段代码会引起死锁，使线程 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
            public void 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
            public void 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 [116c1b000]
    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 [116b18000]
    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）来替代使用内部锁机制。
对于数据库锁，加锁和解锁必须在一个数据库连接里，否则会出现解锁失败的情况。

资源限制的挑战

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

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

案例：并发下载

首先如果你真的在万兆网当中测试过的话，会发现只要配置得当，一个 TCP 连接也完全可以将一张万兆网卡的带宽占满了。所以“多线程下载一个大文件的速度更快”这句话本质上来说就是错误的。那为什么真实场景下用多线程下载似乎会快一些呢？

延迟高的情况下，一个 TCP 连接要占满线路带宽，需要有足够大的 TCP window，通常超过默认的 TCP window 上限，需要通过 TCP window scale 扩展来增加 window 大小。当年的操作系统对 window scale 的支持不太好，增加 TCP 连接数相当于变相增大 window。
操作系统的 TCP 流控实现不太合理的时候，遇到丢包可能速度会掉得很快，多个连接可以缓解这个问题，至少看到速度比较平缓，不会一下掉一半
某些网站限制了单个 TCP 连接的速度，或者本身因为实现问题单个 TCP 连接就有性能上限（比如错误地使用了很小的 buffer 来做 IO），多个连接也就可以增加性能。

应对资源限制

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

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

最近更新于 0001-01-01