本文详细介绍了Java中的Lock锁机制，对比了Lock与synchronized的区别，指出Lock提供了更丰富的功能，如可重入性、可中断性和公平锁等。通过示例展示了Lock的使用方法，包括lock(), tryLock(), tryLock(long time, TimeUnit unit)和lockInterruptibly()，以及如何通过ReentrantLock和ReentrantReadWriteLock实现读写锁。此外，文章还讨论了条件变量Condition以及在避免死锁方面的策略。"
111631069,10295778,Python变量与内存交互：字节流详解,"['Python基础', '内存管理', '变量原理']
java多线程中的同步可以直接使用synhronized关键字，但是它 的缺点也是很明显的
如果一个代码块被synchronized修饰了，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待，等待获取锁的线程释放锁，而这里获取锁的线程释放锁只会有三种情况：
1）获取锁的线程执行完了该代码块，然后线程释放对锁的占有；
2）线程执行发生异常，此时JVM会让线程自动释放锁。
3).调用wait方法,在等待的时候立即释放锁,方便其他的线程使用锁.
那么如果这个获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。
因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。
再举个例子：当有多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作会发生冲突现象，但是读操作和读操作不会发生冲突现象。
但是采用synchronized关键字来实现同步的话，就会导致一个问题：
如果多个线程都只是进行读操作，所以当一个线程在进行读操作时，其他线程只能等待无法进行读操作。
因此就需要一种机制来使得多个线程都只是进行读操作时，线程之间不会发生冲突，通过Lock就可以办到。
另外，通过Lock可以知道线程有没有成功获取到锁。这个是synchronized无法办到的。
总结一下，也就是说Lock提供了比synchronized更多的功能。但是要注意以下几点：
1）Lock不是Java语言内置的，synchronized是Java语言的关键字，因此是内置特性。Lock是一个类，通过这个类可以实现同步访问；
2）Lock和synchronized有一点非常大的不同，采用synchronized不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象。
下面是lock接口的方法
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。newCondition()这个方法最后单独说明。
lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待
Lock lock = ...;
lock.lock();
try{
//处理任务
}catch(Exception ex){
}finally{
lock.unlock(); //释放锁
}tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。
tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。
Lock lock = ...;
if(lock.tryLock()) {
try{
//处理任务
}catch(Exception ex){
}finally{
lock.unlock(); //释放锁
}
}else {
//如果不能获取锁，则直接做其他事情
}lock.Interruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出InterruptedException。
public void method() throws InterruptedException {
lock.lockInterruptibly();
try {
//.....
}
finally {
lock.unlock();
}
}当一个线程获取了锁之后，是不会被interrupt()方法中断的。interrupt()方法不能中断正在运行过程中的线程，只能中断阻塞过程中的线程。
因此当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，只有进行等待的情况下，是可以响应中断的。
而用synchronized修饰的话，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。
lock接口的实现类有三个，一个是reentrantlock，另外两个是ReentrantReadWriteLock中的静态内部类ReadLock和WriteLock
ReentrantLock，字面意思是“可重入锁”，直接看看怎么使用
public class Test {
private ArrayList<Integer> arrayList = new ArrayList<Integer>();
Lock lock = new ReentrantLock();
public static void main(String[] args) {
final Test test = new Test();
new Thread(){
public void run() {
test.insert(Thread.currentThread());
}
}.start();
new Thread(){
public void run() {
test.insert(Thread.currentThread());
}
}.start();
}
public void insert(Thread thread) {
lock.lock();
try {
System.out.println(thread.getName()+"得到了锁");
for(int i=0;i<5;i++) {
arrayList.add(i);
}
} catch (Exception e) {
// TODO: handle exception
}finally {
System.out.println(thread.getName()+"释放了锁");
lock.unlock();
}
}
}public void insert(Thread thread) {
if(lock.tryLock()) { //tryLock的使用
try {
System.out.println(thread.getName()+"得到了锁");
for(int i=0;i<5;i++) {
arrayList.add(i);
}
} catch (Exception e) {
// TODO: handle exception
}finally {
System.out.println(thread.getName()+"释放了锁");
lock.unlock();
}
} else {
System.out.println(thread.getName()+"获取锁失败");
}
}public void insert(Thread thread) throws InterruptedException{
lock.lockInterruptibly(); //注意，如果需要正确中断等待锁的线程，必须将获取锁放在外面，然后将InterruptedException抛出
try {
System.out.println(thread.getName()+"得到了锁");
long startTime = System.currentTimeMillis();
for( ; ;) {
if(System.currentTimeMillis() - startTime >= Integer.MAX_VALUE)
break;
//插入数据
}
}
finally {
System.out.println(Thread.currentThread().getName()+"执行finally");
lock.unlock();
System.out.println(thread.getName()+"释放了锁");
}
}一些方法如下
isFair() //判断锁是否是公平锁
isLocked() //判断锁是否被任何线程获取了
isHeldByCurrentThread() //判断锁是否被当前线程获取了
hasQueuedThreads() //判断是否有线程在等待该锁
上面的使用很简单，看一眼就明白。
还有ReadWriteLock接口，只有两个方法
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*
* @return the lock used for reading.
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing.
*/
Lock writeLock();
}一个用来获取读锁，一个用来获取写锁。也就是说将文件的读写操作分开，分成2个锁来分配给线程，从而使得多个线程可以同时进行读操作。ReentrantReadWriteLock实现了ReadWriteLock接口，并不是实现了lock接口。
ReentrantReadWriteLock里面提供了很多丰富的方法，不过最主要的有两个方法：readLock()和writeLock()用来获取读锁和写锁
public class Test {
private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
public static void main(String[] args) {
final Test test = new Test();
new Thread(){
public void run() {
test.get(Thread.currentThread());
};
}.start();
new Thread(){
public void run() {
test.get(Thread.currentThread());
};
}.start();
}
public void get(Thread thread) {
rwl.readLock().lock();
try {
long start = System.currentTimeMillis();
while(System.currentTimeMillis() - start <= 1) {
System.out.println(thread.getName()+"正在进行读操作");
}
System.out.println(thread.getName()+"读操作完毕");
} finally {
rwl.readLock().unlock();
}
}
}上面是读锁的使用，上面两个线程获取到读锁时候可以并行的操作，不受对方的影响。只要将readlock改成writelock就可以看到线程1先输出结束之后线程2才会输出。
要注意的是，如果有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁。
如果有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，则申请的线程会一直等待释放写锁。
锁还有几个相关的概念。
可重入锁
如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。
可中断锁：顾名思义，就是可以相应中断的锁。
在Java中，synchronized就不是可中断锁，而Lock是可中断锁。
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。
在前面演示lockInterruptibly()的用法时已经体现了Lock的可中断性。
公平锁
公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。
非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。
在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。
而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。
ReentrantLock可以实现公平锁，看看源码构造方法，通过传递参数来实现公平锁。
public ReentrantLock() {
sync = new NonfairSync();
}
/**
* Creates an instance of {@code ReentrantLock} with the
* given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}ReentrantLock中有三个内部类
static final class FairSync extends Sync 公平锁
static final class NonfairSync extends Sync 非公平锁
abstract static class Sync extends AbstractQueuedSynchronizer Sync类
很明显ReentrantLock把所有Lock接口的操作都委派到一个Sync类上，该类继承了AbstractQueuedSynchronizer，太深刻的内容我也看不懂了，就到这里把。
同样的来看看ReentrantReadWriteLock的源码，先看看构造方法
public ReentrantReadWriteLock() {
this(false);
}
/**
* Creates a new {@code ReentrantReadWriteLock} with
* the given fairness policy.
*
* @param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}先确定构造一个公平锁还是非公平锁之后，生成读锁和写锁两个对象，readlock和writelock这两个静态内部类都是实现了lock接口。同样ReentrantReadWriteLock中除了这两个不一样的 内部类之外还有和ReentrantLock相同的那三个内部类。
ReentrantLock实现锁，是纯java的，那么锁的工作流程到底是怎么样，lock的基本思想如下:
需要实现锁的功能，两个必备元素，一个是表示（锁）状态的变量（我们假设0表示没有线程获取锁，1表示已有线程占有锁），另一个是队列，队列中的节点表示因未能获取锁而阻塞的线程。
线程获取锁的大致过程
1. 读取表示锁状态的变量
2. 如果表示状态的变量的值为0，那么当前线程尝试将变量值设置为1（通过CAS操作完成），当多个线程同时将表示状态的变量值由0设置成1时，仅一个线程能成功，其它线程都会失败
2.1 若成功，表示获取了锁，
2.1.1 如果该线程（或者说节点）已位于在队列中，则将其出列（并将下一个节点则变成了队列的头节点）
2.1.2 如果该线程未入列，则不用对队列进行维护
然后当前线程从lock方法中返回，对共享资源进行访问。
2.2 若失败，则当前线程将自身放入等待（锁的）队列中并阻塞自身，此时线程一直被阻塞在lock方法中，没有从该方法中返回（被唤醒后仍然在lock方法中，并从下一条语句继续执行，这里又会回到第1步重新开始）。
3. 如果表示状态的变量的值为1，那么将当前线程放入等待队列中，然后将自身阻塞（被唤醒后仍然在lock方法中，并从下一条语句继续执行，这里又会回到第1步重新开始）
注意: 唤醒并不表示线程能立刻运行，而是表示线程处于就绪状态，仅仅是可以运行而已
线程释放锁的大致过程
1. 释放锁的线程将状态变量的值从1设置为0，并唤醒等待（锁）队列中的队首节点，释放锁的线程从就从unlock方法中返回，继续执行线程后面的代码
2. 被唤醒的线程（队列中的队首节点）和未进入队列并且准备获取的线程竞争获取锁，重复获取锁的过程
注意：可能有多个线程同时竞争去获取锁，但是一次只能有一个线程去释放锁，队列中的节点都需要它的前一个节点将其唤醒，例如有队列A<-B-<C ，即由A释放锁时唤醒B，B释放锁时唤醒C
那既然这样，公平锁具体是怎么一个流程呢，对于上面提到的锁的状态变量state为0的时候人为锁没有被获取，被获取之后state不为0。公平锁维护一个阻塞队列，阻塞队列中的线程按照先来后都的顺序获取锁。此时占有锁的线程还可以再次占有锁，不过state就要+1（可重入锁的原理），只有当这个线程完全释放锁之后state才变成0，那么此时会唤醒阻塞队列中的第一个线程(来的最早的线程)去获取锁，以此类推。
那非公平锁呢，唯一的区别就是当执行线程释放锁之后会唤醒队列中的第一个线程去获取锁，但是如果这个时候新来了一个线程也想获取锁，因为这时候锁状态state为0，他并不会进入阻塞队列，那么这两个线程将会一起竞争锁，那么就有可能队列中被唤醒的第一个线程依旧不会获取到锁，回到阻塞状态。这就是非公平锁。
最后，condition还没说。lock接口中有一个Condition newCondition();方法
我们有时会遇到这样的场景：线程A执行到某个点的时候，因为某个条件condition不满足，需要线程A暂停；等到线程B修改了条件condition，使condition满足了线程A的要求时，A再继续执行。
public class Test {
private static volatile int condition = 0;
public static void main(String[] args) throws InterruptedException {
Thread A = new Thread(new Runnable() {
@Override
public void run() {
while (!(condition == 1)) {
// 条件不满足，自旋
}
System.out.println("a executed");
}
});
A.start();
Thread.sleep(2000);
condition = 1;
}
}这种方式的问题在于自旋非常耗费CPU资源，当然如果在自旋的代码块里加入Thread.sleep(time)将会减轻CPU资源的消耗，但是如果time设的太大，A线程就不能及时响应condition的变化，如果设的太小，依然会造成CPU的消耗。
java在Object类里提供了wait()和notify()方法
class Test1 {
private static volatile int condition = 0;
private static final Object lock = new Object();
public static void main(String[] args) throws InterruptedException {
Thread A = new Thread(new Runnable() {
@Override
public void run() {
synchronized (lock) {
while (!(condition == 1)) {
try {
lock.wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
System.out.println("a executed by notify");
}
}
});
A.start();
Thread.sleep(2000);
condition = 1;
synchronized (lock) {
lock.notify();
}
}
}可以看到在lock.wait()前面检测condition条件的时候使用了一个while循环而不是if，其中 while(condition)循环，它又被叫做“自旋锁”。自旋锁以及wait()和notify()方法在线程通信这篇文章中有更加详细的介绍。为防止该线程没有收到notify()调用也从wait()中返回（也称作虚假唤醒），这个线程会重新去检查condition条件以决定当前是否可以安全地继续执行还是需要重新保持等待，而不是认为线程被唤醒了就可以安全地继续执行了。
因为wait()、notify()是和synchronized配合使用的，因此如果使用了显示锁Lock，就不能用了。所以显示锁要提供自己的等待/通知机制，Condition应运而生。
class Test2 {
private static volatile int condition = 0;
private static Lock lock = new ReentrantLock();
private static Condition lockCondition = lock.newCondition();
public static void main(String[] args) throws InterruptedException {
Thread A = new Thread(new Runnable() {
@Override
public void run() {
lock.lock();
try {
while (!(condition == 1)) {
lockCondition.await();
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
lock.unlock();
}
System.out.println("a executed by condition");
}
});
A.start();
Thread.sleep(2000);
condition = 1;
lock.lock();
try {
lockCondition.signal();
} finally {
lock.unlock();
}
}
}可以看到通过 lock.newCondition() 可以获得到 lock 对应的一个Condition对象lockCondition ，lockCondition的await()、signal()方法分别对应之前的Object的wait()和notify()方法。整体上和Object的等待通知是类似的。
Condition实现的等待通知和Object的等待通知是非常类似的，而Condition提供的等待通知功能更强大，最重要的一点是，一个lock对象可以通过多次调用 lock.newCondition() 获取多个Condition对象，也就是说，在一个lock对象上，可以有多个等待队列，而Object的等待通知在一个Object上，只能有一个等待队列。用下面的例子说明，下面的代码实现了一个阻塞队列，当队列已满时，add操作被阻塞有其他线程通过remove方法删除元素；当队列已空时，remove操作被阻塞直到有其他线程通过add方法添加元素。
public class BoundedQueue1<T> {
public List<T> q; //这个列表用来存队列的元素
private int maxSize; //队列的最大长度
private Lock lock = new ReentrantLock();
private Condition addConditoin = lock.newCondition();
private Condition removeConditoin = lock.newCondition();
public BoundedQueue1(int size) {
q = new ArrayList<>(size);
maxSize = size;
}
public void add(T e) {
lock.lock();
try {
while (q.size() == maxSize) {
addConditoin.await();
}
q.add(e);
removeConditoin.signal(); //执行了添加操作后唤醒因队列空被阻塞的删除操作
} catch (InterruptedException e1) {
Thread.currentThread().interrupt();
} finally {
lock.unlock();
}
}
public T remove() {
lock.lock();
try {
while (q.size() == 0) {
removeConditoin.await();
}
T e = q.remove(0);
addConditoin.signal(); //执行删除操作后唤醒因队列满而被阻塞的添加操作
return e;
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return null;
} finally {
lock.unlock();
}
}
}condition维护着一个等待队列，当调用signal的时候，只是通知了队列中的第一个线程（最先挂起的线程）。使用signalAll的时候队列中的所有线程都会被唤醒，也是从头开始唤醒的
ConditionObject简介
我们都知道，synchronized控制同步的时候，可以配合Object的wait()、notify()，notifyAll() 系列方法可以实现等待/通知模式。而Lock呢？它提供了条件Condition接口，配合await(),signal(),signalAll() 等方法也可以实现等待/通知机制。ConditionObject实现了Condition接口，给AQS提供条件变量的支持 。
Condition队列与CLH队列的那些事
我们先来看一下图：
ConditionObject队列与CLH队列的爱恨情仇：
- 调用了await()方法的线程，会被加入到conditionObject等待队列中，并且唤醒CLH队列中head节点的下一个节点。
- 线程在某个ConditionObject对象上调用了singnal()方法后，等待队列中的firstWaiter会被加入到AQS的CLH队列中，等待被唤醒。
- 当线程调用unLock()方法释放锁时，CLH队列中的head节点的下一个节点(在本例中是firtWaiter)，会被唤醒。
区别：
- ConditionObject对象都维护了一个单独的等待队列 ，AQS所维护的CLH队列是同步队列，它们节点类型相同，都是Node。
关于避免死锁
1.发生死锁的原因是因为加锁顺序不一致而出现的~，如果所有线程以固定的顺序来获得锁，那么程序中就不会出现锁顺序死锁问题！
2.
因为在调用某个方法时就需要持有锁，并且在方法内部也调用了其他带锁的方法！
-
如果在调用某个方法时不需要持有锁，那么这种调用被称为开放调用！
我们可以这样来改造：
-
同步代码块最好仅被用于保护那些涉及共享状态的操作！缩减同步代码块范围，最好仅操作共享变量时才加锁
3.
使用显式Lock锁，在获取锁时使用tryLock()方法。当等待超过时限的时候，tryLock()不会一直等待，而是返回错误信息。
使用tryLock()能够有效避免死锁问题~~
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
