13 | 理论基础模块热点问题答疑
起源是一个硬件的核心矛盾：CPU 与内存、I/O 的速度差异，系统软件（操作系统、编译器）在解决这个核心矛盾的同时，引入了可见性、原子性和有序性问题，这三个问题就是很多并发程序的 Bug 之源。这，就是01 | 可见性、原子性和有序性问题：并发编程Bug的源头的内容。
那如何解决这三个问题呢？Java 语言自然有招儿，它提供了 Java 内存模型和互斥锁方案。所以，在02 | Java内存模型：看Java如何解决可见性和有序性问题我们介绍了 Java 内存模型，以应对可见性和有序性问题；那另一个原子性问题该如何解决？多方考量用好互斥锁才是关键，这就是03 | 互斥锁（上）：解决原子性问题和04 | 互斥锁（下）：如何用一把锁保护多个资源？的内容。
虽说互斥锁是解决并发问题的核心工具，但它也可能会带来死锁问题，所以05 | 一不小心就死锁了，怎么办？就介绍了死锁的产生原因以及解决方案；同时还引出一个线程间协作的问题，这也就引出了06 | 用“等待-通知”机制优化循环等待这篇文章的内容，介绍线程间的协作机制：等待 - 通知。
你应该也看出来了，前六篇文章，我们更多地是站在微观的角度看待并发问题。而07 | 安全性、活跃性以及性能问题则是换一个角度，站在宏观的角度重新审视并发编程相关的概念和理论，同时也是对前六篇文章的查漏补缺。
08 | 管程：并发编程的万能钥匙介绍的管程，是 Java 并发编程技术的基础，是解决并发问题的万能钥匙。并发编程里两大核心问题——互斥和同步，都是可以由管程来解决的。所以，学好管程，就相当于掌握了一把并发编程的万能钥匙。
至此，并发编程相关的问题，理论上你都应该能找到问题所在，并能给出理论上的解决方案了。
而后在09 | Java线程（上）：Java线程的生命周期、10 | Java线程（中）：创建多少线程才是合适的？和11 | Java线程（下）：为什么局部变量是线程安全的？我们又介绍了线程相关的知识，毕竟 Java 并发编程是要靠多线程来实现的，所以有针对性地学习这部分知识也是很有必要的，包括线程的生命周期、如何计算合适的线程数以及线程内部是如何执行的。
最后，在12 | 如何用面向对象思想写好并发程序？我们还介绍了如何用面向对象思想写好并发程序，因为在 Java 语言里，面向对象思想能够让并发编程变得更简单。
14 | Lock和Condition（上）：隐藏在并发包中的管程
- 再造管程的理由
- 如何保证可见性
- 什么是可重入锁
- 公平锁与非公平锁
- 用锁的最佳实践
在并发编程领域，有两大核心问题：
- 一个是互斥，即同一时刻只允许一个线程访问共享资源；
- 另一个是同步，即线程之间如何通信、协作。
这两大问题，管程都是能够解决的。Java SDK 并发包通过 Lock 和 Condition 两个接口来实现管程，其中Lock 用于解决互斥问题，Condition 用于解决同步问题。
再造管程的理由
我们前面在介绍05 | 一不小心就死锁了，怎么办？的时候，提出了一个破坏不可抢占条件方案，但是这个方案 synchronized 没有办法解决。原因是 synchronized 申请资源的时候，如果申请不到，线程直接进入阻塞状态了，也释放不了线程已经占有的资源。
如果我们重新设计一把互斥锁去解决这个问题，那该怎么设计呢？我觉得有三种方案。
- 能够响应中断。synchronized 的问题是，持有锁 A 后，如果尝试获取锁 B 失败，那么线程就进入阻塞状态，一旦发生死锁，就没有任何机会来唤醒阻塞的线程。但如果阻塞状态的线程能够响应中断信号，也就是说当我们给阻塞的线程发送中断信号的时候，能够唤醒它，那它就有机会释放曾经持有的锁 A。这样就破坏了不可抢占条件了。
- 支持超时。如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个错误，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
- 非阻塞地获取锁。如果尝试获取锁失败，并不进入阻塞状态，而是直接返回，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。
体现在 API 上，就是 Lock 接口的三个方法：
// 支持中断的API
void lockInterruptibly()
throws InterruptedException;
// 支持超时的API
boolean tryLock(long time, TimeUnit unit)
throws InterruptedException;
// 支持非阻塞获取锁的API
boolean tryLock();
如何保证可见性
那 Java SDK 里面 Lock 靠什么保证可见性呢？例如在下面的代码中，线程 T1 对 value 进行了 +=1 操作，那后续的线程 T2 能够看到 value 的正确结果吗？
class X {
private final Lock rtl =
new ReentrantLock();
int value;
public void addOne() {
// 获取锁
rtl.lock();
try {
value+=1;
} finally {
// 保证锁能释放
rtl.unlock();
}
}
}
Java SDK 里面锁，是利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的 ReentrantLock，内部持有一个 volatile 的成员变量 state，获取锁的时候，会读写 state 的值；解锁的时候，也会读写 state 的值。根据相关的 Happens-Before 规则：
- 顺序性规则：对于线程 T1，value+=1 Happens-Before 释放锁的操作 unlock()；
- volatile 变量规则：由于 state = 1 会先读取 state，所以线程 T1 的 unlock() 操作 Happens-Before 线程 T2 的 lock() 操作；
- 传递性规则：线程 T1 的 value+=1 Happens-Before 线程 T2 的 lock() 操作。
所以说，后续线程 T2 能够看到 value 的正确结果。02 | Java内存模型：看Java如何解决可见性和有序性问题
什么是可重入锁
ReentrantLock，可重入锁，指的是线程可以重复获取同一把锁。如果锁是可重入的，那么线程 可以再次加锁成功；如果锁是不可重入的，那么线程会被阻塞。
可重入函数，指的是多个线程可以同时调用该函数，每个线程都能得到正确结果；同时在一个线程内支持线程切换，无论被切换多少次，结果都是正确的。即线程安全。
公平锁与非公平锁
ReentrantLock 这个类有两个构造函数，一个是无参构造函数，一个是传入 fair 参数的构造函数。fair 参数代表的是锁的公平策略，如果传入 true 就表示需要构造一个公平锁，反之则表示要构造一个非公平锁。
//无参构造函数：默认非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
//根据公平策略参数创建锁
public ReentrantLock(boolean fair){
sync = fair ? new FairSync()
: new NonfairSync();
}
在前面08 | 管程：并发编程的万能钥匙中，我们介绍过入口等待队列，锁都对应着一个等待队列，如果一个线程没有获得锁，就会进入等待队列，当有线程释放锁的时候，就需要从等待队列中唤醒一个等待的线程。如果是公平锁，唤醒的策略就是谁等待的时间长，就唤醒谁，很公平；如果是非公平锁，则不提供这个公平保证，有可能等待时间短的线程反而先被唤醒。
用锁的最佳实践
《Java 并发编程：设计原则与模式》一书中，推荐的三个用锁的最佳实践，它们分别是：
- 永远只在更新对象的成员变量时加锁
- 永远只在访问可变的成员变量时加锁
- 永远不在调用其他对象的方法时加锁
总结
Java SDK 并发包里的 Lock 接口里面的每个方法，你可以感受到，都是经过深思熟虑的。除了支持类似 synchronized 隐式加锁的 lock() 方法外，还支持超时、非阻塞、可中断的方式获取锁，这三种方式为我们编写更加安全、健壮的并发程序提供了很大的便利。希望你以后在使用锁的时候，一定要仔细斟酌。
除了并发大师 Doug Lea 推荐的三个最佳实践外，你也可以参考一些诸如：减少锁的持有时间、减小锁的粒度等业界广为人知的规则，其实本质上它们都是相通的，不过是在该加锁的地方加锁而已。你可以自己体会，自己总结，最终总结出自己的一套最佳实践来。
课后思考
你已经知道 tryLock() 支持非阻塞方式获取锁，下面这段关于转账的程序就使用到了 tryLock()，你来看看，它是否存在死锁问题呢？
class Account {
private int balance;
private final Lock lock
= new ReentrantLock();
// 转账
void transfer(Account tar, int amt){
while (true) {
if(this.lock.tryLock()) {
try {
if (tar.lock.tryLock()) {
try {
this.balance -= amt;
tar.balance += amt;
} finally {
tar.lock.unlock();
}
}//if
} finally {
this.lock.unlock();
}
}//if
}//while
}//transfer
}
Copyright © 2015 Powered by MWeb, Theme used GitHub CSS.