今天深度学习一下《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);
}
}
}如果有2个线程，线程A先执行setStatus()，然后线程B执行test()，那边打印出来的b的值，一定等于3吗？不一定！可能还是2。因为a=2和status=true没有依赖关系，所以会被重排序，并行派给不同ALU单元执行，导致可能status=true先执行完成，这是a=2还未执行完，此时a还是1，引起最终打印的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) {
...
}
}如果此时有另外的线程持有了res2不释放，而请求res1，则会出现死锁。
解决死锁的方法
只要让产生死锁的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();
...
}可见tryLock()可以尝试非阻塞地获取锁，或指定最长等待时间阻塞地获取锁，可以有效避免死锁。
Lock lock = new ReentrantLock();
if(lock.tryLock()) {
//成功获得锁
try{
...
} catch(Exception ex){
} finally{
lock.unlock(); //释放锁
}
} else {
//不能获取锁
...
}
我们再看看下面的代码，transfer()方法实现从当前Account转钱到目标Account，你发现问题了吗？
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;
}
}在方法中使用synchronized关键字，其使用的是this对象进行加锁。所以上述代码只保证了this.money的原子性，却无法保证target.money的原子性。依然存在数据一致性问题。对应这种资源间存在关联关系的情况，我们需要用一个更大范围的锁来将相关资源都覆盖住，如下所示：
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核数。