理解Java多线程之并发编程

今天深度学习一下《Java并发编程的艺术》的第1章并发编程的挑战，深入理解Java多线程，看看多线程中的坑。

注意，哈肯的程序员读书笔记并不是抄书，而是将书中精华内容和哈肯的开发经验相结合，给你系统地讲述我对相关知识理解。如果你发现哈肯讲的内容跟书中内容差异很大也不足为奇。

1 多线程的使用场景

在实际的商业系统中，为了提升程序的性能，我们经常会使用到多线程。java多线程也是后台开发岗、Android开发岗招聘面试和笔试时的热门问题。至少，到目前为止我面试过的200多位开发同学时，以及我曾经的几次求职被面试时，多半都会问java多线程并发相关的问题。

2 多线程的缺点

多线程能充分利用多核CPU的特性，但并不意味着多线程就一定比单线程更快，并发编程也存在许多限制和挑战，例如多线程间的上下文切换会有开销、多线程中的数据一致性问题、线程死锁问题、系统资源限制。

2.1 上下文切换的开销

（1）上下文切换的开销

CPU使用时间片算法，将处理时间轮着分配给不同的线程，所以即使是单核CPU也支持多线程，这个时间片非常短，一般是几十毫秒（ms），CPU不停的切换线程执行，让我们感觉多个线程是同时执行的。CPU在切换线程前会保存上一个任务的状态，以便下次切换回这个线程时，可以正常继续执行。我们把线程的状态保存到再加载的过程称为一次上下文切换。

《Java并发编程的艺术》作者写了一段程序，让2个线程同时不断地做变量自增操作，结果证明用2个线程并行甚至比单线程串行更慢一些。通过使用Lmbench3测量上下文切换的时长，发现上述多线程代码中每秒高达1000多次的线程上下文切换。因此不是多线程就一定更快，还要看在线程中干了什么。

（2）如何减少上下文切换

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

• 无锁并发编程。多线程竞争锁时，会引起上下文切换，通过避免使用锁，可以减少线程的切换，例如将数据用ID分段，不同的线程处理不同段的数据。

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

• 减少不必要的线程。当任务很少时，尽量减少不必要的线程，避免造成大量线程都处于等待状态。

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

2.2 多线程中的数据一致性问题

（1）线程中访问外部数据的过程

每个线程都有自己的栈，保存线程中创建的局部变量，如果线程中使用到外部的变量，则线程通常会把改外部变量复制一份到线程栈中，当修改完后，再将数据同步回外部。

（2）线程内操作的原子性问题

一个操作会由多个cpu指令构造。例如，创建对象操作大致分为几步：为对象分配内存、成员变量的值初始化、调用构造方法、返回对象的引用；又例如，线程中对一个外部变量的赋值（修改）操作大致分为几步：在当前线程栈创建变量副本，修改变量值，将变量值的修改同步回外部，由于CPU的时间片机制，每个线程获得时间片后，能执行的指令数量是有限的，可能一个操作还未完成，而时间片到了，需要保存上下文并切换到下一个线程。因此，无法保证操作的原子性。

（3）共享数据的可见性问题

观察上述的原子性问题中的例子，线程中对一个外部变量的赋值，可能线程A中刚创建了外部变量的副本，而线程B已经对该外部变量进行了修改，但线程A中是不知道的。即，一个线程对共享数据的修改，不能立刻被其他线程所看见，这就引起了数据一致性的问题。

（4）有序性问题

CPU单个核中，包含多个ALU单元（Arithmetic Logic Unit，即算术逻辑单元），用来执行算数运算和逻辑运算。目前Intel的Haswell架构的CPU（ * 酷睿处理器开始）有4个ALU单元。所以单核CPU在同一时刻是同时执行多个指令的。CPU会把多条指令进行重排序，把没有依赖关系的指令同时放到各ALU中执行。例如3个操作按如下顺序写代码 a=1; b=2; c=a+b; 由于a=1和b=2不存在依赖关系，2个指令可能会被重排序，而c=a+b存在依赖关系，这个指令一定会在前2个指令执行完后再执行，最终一定是c=3。请看如下代码：

public class VolatileTest {
   private int a = 1;
   private boolean status = false;

public void setStatus() {
       a = 2;
       status = true;
   }

public void test() {
       if (status) {
           int b = a + 1;
           System.out.print(b);
       }
   }
}

（5）如何解决多线程的数据一致性问题

由于以上4点，引发了多线程中数据的一致性问题。解决办法主要有2个：

• 使用volatile关键字。相对synchronized来说，volatile是一种轻量级的同步机制，有2个作用：一是保证共享变量对所有线程的可见性，即本地副本修改后会强制刷新回外部；二是禁止指令重排序优化。但要注意volatile只对单个变量读/写操作具有原子性，对i++这种复合操作（取值、加1、赋值）是无法保证其原子性的。要保证多线程中i++这种复合操作的原子性，可以改用CAS的实现类，例如用AtomicInteger代替int。

• 加锁。通过锁来实现同一时间只有1个线程可以访问共享变量。

2.3 线程死锁问题

死锁产生需要同时满足4个条件：

• 资源的互斥使用，即当资源被一个线程占有时，别的线程不能用。

• 不可抢占，即资源请的求者不能从使用者手上强制夺取资源，只能等待对方释放。

• 请求和保持，即在请求其他资源的同时还保持对现有资源的占有。

• 循环等待，例如线程1持有资源A，请求资源B，而线程2持有资源B，请求资源A。

下面的代码演示对资源的请求和保持，持有res1不释放，同时对res2进行请求：

synchronized (res1) {
  ... // 执行一些操作
  synchronized (res2) {
     ...
  }
}

解决死锁的方法

只要让产生死锁的4个条件中任何一个不成立，就可以避免死锁。具体做法通常有：

• 使用Lock接口的tryLock()。

• 避免一个线程中同时获得多个锁。例如上面代码所示，同时获得res1和res2的锁才能完成执行。

• 避免一个锁中占用多个资源，即要缩小锁的范围。

Lock接口包含4个给对象加锁的方法，如下所示：

public interface Lock {
    /**阻塞，直到另外一个线程释放锁*/
   void lock();

/**以可被中断的方式获取锁。调用正在等待获得锁的线程的interrupt()方法可中断*/
   void lockInterruptibly() throws InterruptedException;

/**非阻塞，尝试的获取锁，如果获取到则返回true，否则返回false*/
   boolean tryLock();
   /**阻塞，试图获取锁，最多阻塞等待指定时间，如果获取到则返回true，否则返回false*/
   boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

void unlock();
   ...
}

Lock lock = new ReentrantLock();
if(lock.tryLock()) {
   //成功获得锁
   try{
       ...
   } catch(Exception ex){

} finally{
        lock.unlock();   //释放锁
   }
} else {
   //不能获取锁
   ...
}

class Account {
   private int money;
   synchronized boolean transfer(Account target, int money){
       if (this.money > money) {
           this.money -= money;
           target.money += money;
           return true;
       }
       return false;
   }
}

class Account {
   private int money;
   boolean transfer(Account target, int money){
       synchronized(Account.class) {
           if (this.money > money) {
             this.money -= money;
             target.money += money;
             return true;
           }
       }
       return false;
   }
}

2.4 系统资源限制

系统的资源总是有限的，无节制地创建大量的线程，只会造成大量的线程上下文切换的开销，并不能实际提高程序的效率。按照大家的常规经验，如果是IO密集型，则线程池的核心线程数宜为2N+1；如果是
CPU密集型，则线程池核心线程数宜为N+1；其中N为CPU核数。

来源：https://blog.51cto.com/u_13146445/6031966