1.使用wait和notify

1.1.多线程协调

在Java程序中，synchronized解决了多线程竞争的问题。例如，对于一个任务管理器，多个线程同时往队列中添加任务，可以用synchronized加锁：

class TaskQueue {Queue<String> queue = new LinkedList<>();public synchronized void addTask(String s) {this.queue.add(s);}
}

但是synchronized并没有解决多线程协调的问题。
仍然以上面的TaskQueue为例，我们再编写一个getTask()方法取出队列的第一个任务：

class TaskQueue {Queue<String> queue = new LinkedList<>();public synchronized void addTask(String s) {this.queue.add(s);}public synchronized String getTask() {while (queue.isEmpty()) {}return queue.remove();}
}

上述代码看上去没有问题：getTask()内部先判断队列是否为空，如果为空，就循环等待，直到另一个线程往队列中放入了一个任务，while()循环退出，就可以返回队列的元素了。
但实际上while()循环永远不会退出。因为线程在执行while()循环时，已经在getTask()入口获取了this锁，其他线程根本无法调用addTask()，因为addTask()执行条件也是获取this锁。
因此，执行上述代码，线程会在getTask()中因为死循环而100%占用CPU资源。
如果深入思考一下，我们想要的执行效果是：

1. 线程1可以调用addTask()不断往队列中添加任务；
2. 线程2可以调用getTask()从队列中获取任务。如果队列为空，则getTask()应该等待，直到队列中至少有一个任务时再返回。

因此，多线程协调运行的原则就是：当条件不满足时，线程进入等待状态；当条件满足时，线程被唤醒，继续执行任务。

1.2.wait()和notify()

对于上述TaskQueue，我们先改造getTask()方法，在条件不满足时，线程进入等待状态：

public synchronized String getTask() {while (queue.isEmpty()) {this.wait();}return queue.remove();
}

当一个线程执行到getTask()方法内部的while循环时，它必定已经获取到了this锁，此时，线程执行while条件判断，如果条件成立（队列为空），线程将执行this.wait()，进入等待状态。
这里的关键是：wait()方法必须在当前获取的锁对象上调用，这里获取的是this锁，因此调用this.wait()。
调用wait()方法后，线程进入等待状态，wait()方法不会返回，直到将来某个时刻，线程从等待状态被其他线程唤醒后，wait()方法才会返回，然后，继续执行下一条语句。
有些仔细的童鞋会指出：即使线程在getTask()内部等待，其他线程如果拿不到this锁，照样无法执行addTask()，肿么办？
这个问题的关键就在于wait()方法的执行机制非常复杂。首先，它不是一个普通的Java方法，而是定义在Object类的一个native方法，也就是由JVM的C代码实现的。其次，必须在synchronized块中才能调用wait()方法，因为wait()方法调用时，会释放线程获得的锁，wait()方法返回后，线程又会重新试图获得锁。
因此，只能在锁对象上调用wait()方法。因为在getTask()中，我们获得了this锁，因此，只能在this对象上调用wait()方法：

public synchronized String getTask() {while (queue.isEmpty()) {// 释放this锁:this.wait();// 重新获取this锁}return queue.remove();
}

当一个线程在this.wait()等待时，它就会释放this锁，从而使得其他线程能够在addTask()方法获得this锁。
现在我们面临第二个问题：如何让等待的线程被重新唤醒，然后从wait()方法返回？答案是在相同的锁对象上调用notify()方法。我们修改addTask()如下：

public synchronized void addTask(String s) {this.queue.add(s);this.notify(); // 唤醒在this锁等待的线程
}

注意到在往队列中添加了任务后，线程立刻对this锁对象调用notify()方法，这个方法会唤醒一个正在this锁等待的线程（就是在getTask()中位于this.wait()的线程），从而使得等待线程从this.wait()方法返回。
使用notifyAll()将唤醒所有当前正在this锁等待的线程，而notify()只会唤醒其中一个（具体哪个依赖操作系统，有一定的随机性）。这是因为可能有多个线程正在getTask()方法内部的wait()中等待，使用notifyAll()将一次性全部唤醒。通常来说，notifyAll()更安全。有些时候，如果我们的代码逻辑考虑不周，用notify()会导致只唤醒了一个线程，而其他线程可能永远等待下去醒不过来了。
所以，正确编写多线程代码是非常困难的，需要仔细考虑的条件非常多，任何一个地方考虑不周，都会导致多线程运行时不正常。

1.3.小结

wait和notify用于多线程协调运行：

1. 在synchronized内部可以调用wait()使线程进入等待状态；
2. 必须在已获得的锁对象上调用wait()方法；
3. 在synchronized内部可以调用notify()或notifyAll()唤醒其他等待线程；
4. 必须在已获得的锁对象上调用notify()或notifyAll()方法；
5. 已唤醒的线程还需要重新获得锁后才能继续执行。

2.使用ReentrantLock

2.1.ReentrantLock介绍

从Java 5开始，引入了一个高级的处理并发的java.util.concurrent包，它提供了大量更高级的并发功能，能大大简化多线程程序的编写。
我们知道Java语言直接提供了synchronized关键字用于加锁，但这种锁一是很重，二是获取时必须一直等待，没有额外的尝试机制。
java.util.concurrent.locks包提供的ReentrantLock用于替代synchronized加锁，我们来看一下传统的synchronized代码：

public class Counter {private int count;public void add(int n) {synchronized(this) {count += n;}}
}

如果用ReentrantLock替代，可以把代码改造为：

public class Counter {private final Lock lock = new ReentrantLock();private int count;public void add(int n) {lock.lock();try {count += n;} finally {lock.unlock();}}
}

因为synchronized是Java语言层面提供的语法，所以我们不需要考虑异常，而ReentrantLock是Java代码实现的锁，我们就必须先获取锁，然后在finally中正确释放锁。
顾名思义，ReentrantLock是可重入锁，它和synchronized一样，一个线程可以多次获取同一个锁。
和synchronized不同的是，ReentrantLock可以尝试获取锁：

if (lock.tryLock(1, TimeUnit.SECONDS)) {try {...} finally {lock.unlock();}
}

上述代码在尝试获取锁的时候，最多等待1秒。如果1秒后仍未获取到锁，tryLock()返回false，程序就可以做一些额外处理，而不是无限等待下去。
所以，使用ReentrantLock比直接使用synchronized更安全，线程在tryLock()失败的时候不会导致死锁。

2.2.小结

1. ReentrantLock可以替代synchronized进行同步；
2. ReentrantLock获取锁更安全；
3. 必须先获取到锁，再进入try {…}代码块，最后使用finally保证释放锁；
4. 可以使用tryLock()尝试获取锁。

3.使用Condition

3.1.Condition介绍

使用ReentrantLock比直接使用synchronized更安全，可以替代synchronized进行线程同步。
但是，synchronized可以配合wait和notify实现线程在条件不满足时等待，条件满足时唤醒，用ReentrantLock我们怎么编写wait和notify的功能呢？
答案是使用Condition对象来实现wait和notify的功能。
我们仍然以TaskQueue为例，把前面用synchronized实现的功能通过ReentrantLock和Condition来实现：

class TaskQueue {private final Lock lock = new ReentrantLock();private final Condition condition = lock.newCondition();private Queue<String> queue = new LinkedList<>();public void addTask(String s) {lock.lock();try {queue.add(s);condition.signalAll();} finally {lock.unlock();}}public String getTask() {lock.lock();try {while (queue.isEmpty()) {condition.await();}return queue.remove();} finally {lock.unlock();}}
}

可见，使用Condition时，引用的Condition对象必须从Lock实例的newCondition()返回，这样才能获得一个绑定了Lock实例的Condition实例。
Condition提供的await()、signal()、signalAll()原理和synchronized锁对象的wait()、notify()、notifyAll()是一致的，并且其行为也是一样的：

1. await()会释放当前锁，进入等待状态；
2. signal()会唤醒某个等待线程；
3. signalAll()会唤醒所有等待线程；
4. 唤醒线程从await()返回后需要重新获得锁。

此外，和tryLock()类似，await()可以在等待指定时间后，如果还没有被其他线程通过signal()或signalAll()唤醒，可以自己醒来：

if (condition.await(1, TimeUnit.SECOND)) {// 被其他线程唤醒
} else {// 指定时间内没有被其他线程唤醒
}

可见，使用Condition配合Lock，我们可以实现更灵活的线程同步。

3.2.小结

1. Condition可以替代wait和notify；
2. Condition对象必须从Lock对象获取。

4.使用ReadWriteLock

4.1.ReadWriteLock介绍

前面讲到的ReentrantLock保证了只有一个线程可以执行临界区代码：

public class Counter {private final Lock lock = new ReentrantLock();private int[] counts = new int[10];public void inc(int index) {lock.lock();try {counts[index] += 1;} finally {lock.unlock();}}public int[] get() {lock.lock();try {return Arrays.copyOf(counts, counts.length);} finally {lock.unlock();}}
}

但是有些时候，这种保护有点过头。因为我们发现，任何时刻，只允许一个线程修改，也就是调用inc()方法是必须获取锁，但是，get()方法只读取数据，不修改数据，它实际上允许多个线程同时调用。
实际上我们想要的是：允许多个线程同时读，但只要有一个线程在写，其他线程就必须等待：

使用ReadWriteLock可以解决这个问题，它保证：

• 只允许一个线程写入（其他线程既不能写入也不能读取）；
• 没有写入时，多个线程允许同时读（提高性能）。

用ReadWriteLock实现这个功能十分容易。我们需要创建一个ReadWriteLock实例，然后分别获取读锁和写锁：

public class Counter {private final ReadWriteLock rwlock = new ReentrantReadWriteLock();private final Lock rlock = rwlock.readLock();private final Lock wlock = rwlock.writeLock();private int[] counts = new int[10];public void inc(int index) {wlock.lock(); // 加写锁try {counts[index] += 1;} finally {wlock.unlock(); // 释放写锁}}public int[] get() {rlock.lock(); // 加读锁try {return Arrays.copyOf(counts, counts.length);} finally {rlock.unlock(); // 释放读锁}}
}

把读写操作分别用读锁和写锁来加锁，在读取时，多个线程可以同时获得读锁，这样就大大提高了并发读的执行效率。

使用ReadWriteLock时，适用条件是同一个数据，有大量线程读取，但仅有少数线程修改。

例如，一个论坛的帖子，回复可以看做写入操作，它是不频繁的，但是，浏览可以看做读取操作，是非常频繁的，这种情况就可以使用ReadWriteLock。

4.2.小结

使用ReadWriteLock可以提高读取效率：

1. ReadWriteLock只允许一个线程写入；
2. ReadWriteLock允许多个线程在没有写入时同时读取；
3. ReadWriteLock适合读多写少的场景。

5.使用StampedLock

5.1.StampedLock介绍

前面介绍的ReadWriteLock可以解决多线程同时读，但只有一个线程能写的问题。
如果我们深入分析ReadWriteLock，会发现它有个潜在的问题：如果有线程正在读，写线程需要等待读线程释放锁后才能获取写锁，即读的过程中不允许写，这是一种悲观的读锁。
要进一步提升并发执行效率，Java 8引入了新的读写锁：StampedLock。
StampedLock和ReadWriteLock相比，改进之处在于：读的过程中也允许获取写锁后写入！这样一来，我们读的数据就可能不一致，所以，需要一点额外的代码来判断读的过程中是否有写入，这种读锁是一种乐观锁。
乐观锁的意思就是乐观地估计读的过程中大概率不会有写入，因此被称为乐观锁。反过来，悲观锁则是读的过程中拒绝有写入，也就是写入必须等待。显然乐观锁的并发效率更高，但一旦有小概率的写入导致读取的数据不一致，需要能检测出来，再读一遍就行。
看个例子：

public class Point {private final StampedLock stampedLock = new StampedLock();private double x;private double y;public void move(double deltaX, double deltaY) {long stamp = stampedLock.writeLock(); // 获取写锁try {x += deltaX;y += deltaY;} finally {stampedLock.unlockWrite(stamp); // 释放写锁}}public double distanceFromOrigin() {long stamp = stampedLock.tryOptimisticRead(); // 获得一个乐观读锁// 注意下面两行代码不是原子操作// 假设x,y = (100,200)double currentX = x;// 此处已读取到x=100，但x,y可能被写线程修改为(300,400)double currentY = y;// 此处已读取到y，如果没有写入，读取是正确的(100,200)// 如果有写入，读取是错误的(100,400)if (!stampedLock.validate(stamp)) { // 检查乐观读锁后是否有其他写锁发生stamp = stampedLock.readLock(); // 获取一个悲观读锁try {currentX = x;currentY = y;} finally {stampedLock.unlockRead(stamp); // 释放悲观读锁}}return Math.sqrt(currentX * currentX + currentY * currentY);}
}

和ReadWriteLock相比，写入的加锁是完全一样的，不同的是读取。注意到首先我们通过tryOptimisticRead()获取一个乐观读锁，并返回版本号。接着进行读取，读取完成后，我们通过validate()去验证版本号，如果在读取过程中没有写入，版本号不变，验证成功，我们就可以放心地继续后续操作。如果在读取过程中有写入，版本号会发生变化，验证将失败。在失败的时候，我们再通过获取悲观读锁再次读取。由于写入的概率不高，程序在绝大部分情况下可以通过乐观读锁获取数据，极少数情况下使用悲观读锁获取数据。
可见，StampedLock把读锁细分为乐观读和悲观读，能进一步提升并发效率。但这也是有代价的：一是代码更加复杂，二是StampedLock是不可重入锁，不能在一个线程中反复获取同一个锁。
StampedLock还提供了更复杂的将悲观读锁升级为写锁的功能，它主要使用在if-then-update的场景：即先读，如果读的数据满足条件，就返回，如果读的数据不满足条件，再尝试写。

5.2.小结

1. StampedLock提供了乐观读锁，可取代ReadWriteLock以进一步提升并发性能；
2. StampedLock是不可重入锁。

6.使用Concurrent集合

6.1.Concurrent中的并发集合

针对List、Map、Set、Deque等，java.util.concurrent包也提供了对应的并发集合类。我们归纳一下：

使用这些并发集合与使用非线程安全的集合类完全相同。我们以ConcurrentHashMap为例：

Map<String, String> map = new ConcurrentHashMap<>();
// 在不同的线程读写:
map.put("A", "1");
map.put("B", "2");
map.get("A", "1");

因为所有的同步和加锁的逻辑都在集合内部实现，对外部调用者来说，只需要正常按接口引用，其他代码和原来的非线程安全代码完全一样。即当我们需要多线程访问时，把：

Map<String, String> map = new HashMap<>();

改为：

Map<String, String> map = new ConcurrentHashMap<>();

就可以了。
java.util.Collections工具类还提供了一个旧的线程安全集合转换器，可以这么用：

Map unsafeMap = new HashMap();
Map threadSafeMap = Collections.synchronizedMap(unsafeMap);

但是它实际上是用一个包装类包装了非线程安全的Map，然后对所有读写方法都用synchronized加锁，这样获得的线程安全集合的性能比java.util.concurrent集合要低很多，所以不推荐使用。

6.2.小结

1. 使用java.util.concurrent包提供的线程安全的并发集合可以大大简化多线程编程：
2. 多线程同时读写并发集合是安全的；
3. 尽量使用Java标准库提供的并发集合，避免自己编写同步代码。

7.使用Atomic

7.1.Atomic介绍

Java的java.util.concurrent包除了提供底层锁、并发集合外，还提供了一组原子操作的封装类，它们位于java.util.concurrent.atomic包。
我们以AtomicInteger为例，它提供的主要操作有：

1. 增加值并返回新值：int addAndGet(int delta)
2. 加1后返回新值：int incrementAndGet()
3. 获取当前值：int get()
4. 用CAS方式设置：int compareAndSet(int expect, int update)

Atomic类是通过无锁（lock-free）的方式实现的线程安全（thread-safe）访问。它的主要原理是利用了CAS：Compare and Set。
如果我们自己通过CAS编写incrementAndGet()，它大概长这样：

public int incrementAndGet(AtomicInteger var) {int prev, next;do {prev = var.get();next = prev + 1;} while ( ! var.compareAndSet(prev, next));return prev;
}

CAS是指，在这个操作中，如果AtomicInteger的当前值是prev，那么就更新为next，返回true。如果AtomicInteger的当前值不是prev，就什么也不干，返回false。通过CAS操作并配合do … while循环，即使其他线程修改了AtomicInteger的值，最终的结果也是正确的。
我们利用AtomicLong可以编写一个多线程安全的全局唯一ID生成器：

class IdGenerator {AtomicLong var = new AtomicLong(0);public long getNextId() {return var.incrementAndGet();}
}

通常情况下，我们并不需要直接用do … while循环调用compareAndSet实现复杂的并发操作，而是用incrementAndGet()这样的封装好的方法，因此，使用起来非常简单。
在高度竞争的情况下，还可以使用Java 8提供的LongAdder和LongAccumulator。

7.2.小结

使用java.util.concurrent.atomic提供的原子操作可以简化多线程编程：

1. 原子操作实现了无锁的线程安全；
2. 适用于计数器，累加器等。