对于Java开发工程师来说，并发编程接触的机会很少，当然也是程序员技术最薄弱的地方，根据墨菲定律，往往实际项目中容易出问题的地方都是技术难度高的地方，越担心，越出现。
并发编程领域，有两大核心问题：一个是互斥，即同一时刻只允许一个线程访问共享资源；另一个是同步，即线程之间如何通信、协作。这两大问题，管程都是能够解决的。
今天我来学习一下Java并发包里面的Lock与Condition，Lock用来解决互斥问题，Condition用来解决同步问题，首先我们主要分析一下Lock（锁🔒）是如何解决互斥问题的,Synchronized是Java语言级别的锁，支持对象锁，类锁，Synchronized申请资源的时候如果获取不到锁，那么就会进入堵塞状态，什么也做不了，已经申请的资源也无法释放，但是我们希望的是：
对于不可以抢占的资源，占用部分资源的线程正在进一步申请其他资源的时候，如果申请不到，那么可以主动的释放已经占有的资源，这样不可抢占这个条件就破坏掉了，解决这个问题大体有三个方案：
- 能够响应中断
void lockInterruptibly() throws InterruptedException;- 支持超时
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
- 非堵塞的获取锁 获取不到锁不会堵塞等待，而是会直接返回结果，这样的话 这个线程已经占有的资源也会有可能释放掉
boolean tryLock();
Synchronized的锁遵循HappenBefore原则就是,这条规则是指对一个锁的解锁 Happens-Before 于后续对这个锁的加锁.
具体使用Lock的答题方式如下，比较经典的try{}catch(){}finnally{},Java SDK 里面锁的实现非常复杂，这里我就不展开细说了，但是原理还是需要简单介绍一下：它是利用了 volatile 相关的 Happens-Before 规则。Java SDK 里面的 ReentrantLock，内部持有一个 volatile 的成员变量 state，获取锁的时候，会读写 state 的值；解锁的时候，也会读写 state 的值（简化后的代码如下面所示）。也就是说，在执行 value+=1 之前，程序先读写了一次 volatile 变量 state，在执行 value+=1 之后，又读写了一次 volatile 变量 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() 操作,简略代码如下
class SampleLock {
volatile int state;
// 加锁
lock() {
// 省略代码无数
state = 1;
}
// 解锁
unlock() {
// 省略代码无数
state = 0;
}
}class X {
private final Lock rtl =
new ReentrantLock();
int value;
public void addOne() {
// 获取锁
rtl.lock();
try {
value+=1;
} finally {
// 保证锁能释放
rtl.unlock();
}
}
}什么是可重入锁？
如果你细心观察，会发现我们创建的锁的具体类名是 ReentrantLock，这个翻译过来叫可重入锁，这个概念前面我们一直没有介绍过。所谓可重入锁，顾名思义，指的是线程可以重复获取同一把锁。例如下面代码中，当线程 T1 执行到 ① 处时，已经获取到了锁 rtl ，当在 ① 处调用 get() 方法时，会在 ② 再次对锁 rtl 执行加锁操作。此时，如果锁 rtl 是可重入的，那么线程 T1 可以再次加锁成功；如果锁 rtl 是不可重入的，那么线程 T1 此时会被阻塞。除了可重入锁，可能你还听说过可重入函数，可重入函数怎么理解呢？指的是线程可以重复调用？显然不是，所谓可重入函数，指的是多个线程可以同时调用该函数，每个线程都能得到正确结果；同时在一个线程内支持线程切换，无论被切换多少次，结果都是正确的。多线程可以同时执行，还支持线程切换，这意味着什么呢？线程安全啊。所以，可重入函数是线程安全的，这是一把锁临界区的资源是被同一把锁锁的，那么在临界区内相同线程可以重复获取锁，就是可以重入锁。
class X {
private final Lock rtl =
new ReentrantLock();
int value;
public int get() {
// 获取锁
rtl.lock(); ②
try {
return value;
} finally {
// 保证锁能释放
rtl.unlock();
}
}
public void addOne() {
// 获取锁
rtl.lock();
try {
value = 1 + get(); ①
} finally {
// 保证锁能释放
rtl.unlock();
}
}
}公平锁与非公平锁
在使用 ReentrantLock 的时候，你会发现 ReentrantLock 这个类有两个构造函数，一个是无参构造函数，一个是传入 fair 参数的构造函数。fair 参数代表的是锁的公平策略，如果传入 true 就表示需要构造一个公平锁，反之则表示要构造一个非公平锁。
//无参构造函数：默认非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
//根据公平策略参数创建锁
public ReentrantLock(boolean fair){
sync = fair ? new FairSync()
: new NonfairSync();
}用锁的最佳实践你已经知道
用锁虽然能解决很多并发问题，但是风险也是挺高的。可能会导致死锁，也可能影响性能。这方面有是否有相关的最佳实践呢？有，还很多。但是我觉得最值得推荐的是并发大师 Doug Lea《Java 并发编程：设计原则与模式》一书中，推荐的三个用锁的最佳实践，它们分别是：
- 永远只在更新对象的成员变量时加锁
- 永远只在访问可变的成员变量时加锁
- 永远不在调用其他对象的方法时加锁
这三条规则，前两条估计你一定会认同，最后一条你可能会觉得过于严苛。但是我还是倾向于你去遵守，因为调用其他对象的方法，实在是太不安全了，也许“其他”方法里面有线程 sleep() 的调用，也可能会有奇慢无比的 I/O 操作，这些都会严重影响性能。更可怕的是，“其他”类的方法可能也会加锁，然后双重加锁就可能导致死锁。
