Java内置锁:深度解析lock和trylock - 程序员古德
lock和tryLock是两种获取锁的方式,它们在处理并发问题时有所不同,lock是阻塞性的,确保只有一个线程能访问被锁资源,但可能导致线程长时间等待;而tryLock非阻塞性,若锁被占用则立即返回失败,避免了长时间等待,但需要更复杂的逻辑处理未能获锁的情况。
定义
Java内置锁:深度解析lock和trylock - 程序员古德
在Java 11中,Lock接口是Java并发编程中一个重要的接口,它提供了更灵活的线程同步机制,相比于内置的synchronized关键字,Lock接口中主要有两个方法用于获取锁:lock()和tryLock()。
参考文档:https://docx.iamqiang.com/jdk11/api/java.base/java/util/concurrent/locks/Lock.html
lock()方法是一个阻塞式的方法,当线程调用这个方法时,如果锁已经被其他线程持有,那么当前线程就会进入等待状态,直到获得锁为止,在这个过程中,线程会一直等待,不会做其他的事情,这就好比在一个繁忙的餐厅外等待空位,如果没有空位,就只能站着等,不能做其他事情,直到有空位为止。
tryLock()方法则是一个非阻塞式的方法,当线程调用这个方法时,如果锁已经被其他线程持有,那么这个方法会立即返回,不会让线程进入等待状态,如果锁没有被其他线程持有,那么当前线程就会立即获得锁,这就像在餐厅外等待空位,但是不确定是否有空位,所以先问一下服务员,如果有空位就坐下,如果没有就去其他地方看看或者做其他事情。
代码案例
Java内置锁:深度解析lock和trylock - 程序员古德lock方法使用
参考文档:https://docx.iamqiang.com/jdk11/api/java.base/java/util/concurrent/locks/Lock.html#lock()
下面举一个例子,模拟一个餐厅,其中有固定数量的座位,客户(线程)需要获取锁(座位)才能在餐厅就餐,如果座位被占用,客户将等待直到有座位可用。
import?java.util.concurrent.locks.Lock;
import?java.util.concurrent.locks.ReentrantLock;
public?class?Restaurant?{
//?餐厅的座位,用Lock表示
private?final?Lock?seat?=?new?ReentrantLock();
//?客户进入餐厅并坐下
public?void?enterAndSit()?{
//?客户尝试获取座位锁
seat.lock();
try?{
//?客户已经坐下,这里可以执行就餐的相关操作
System.out.println(Thread.currentThread().getName()?+?"?已进入餐厅并坐下。");
//?模拟就餐时间
try?{
Thread.sleep(1000);?//?等待1秒
}?catch?(InterruptedException?e)?{
e.printStackTrace();
}
}?finally?{
//?客户离开时释放座位锁
seat.unlock();
System.out.println(Thread.currentThread().getName()?+?"?已离开餐厅。");
}
}
}
创建一个client类来模拟多个客户同时尝试进入餐厅,如下代码:
public?class?RestaurantClient?{
public?static?void?main(String[]?args)?{
//?创建一个餐厅实例
Restaurant?restaurant?=?new?Restaurant();
//?模拟多个客户线程
for?(int?i?=?0;?i?
new?Thread(()?->?{
restaurant.enterAndSit();
},?"客户"?+?Thread.currentThread().getId()).start();
}
}
}
运行RestaurantClient会看到类似以下的输出(由于线程调度的不确定性,输出顺序可能会有所不同):
客户13?已进入餐厅并坐下。
客户13?已离开餐厅。
客户12?已进入餐厅并坐下。
客户12?已离开餐厅。
客户11?已进入餐厅并坐下。
客户11?已离开餐厅。
客户10?已进入餐厅并坐下。
客户10?已离开餐厅。
客户9?已进入餐厅并坐下。
客户9?已离开餐厅。
从输出中可以看到,尽管同时启动了5个客户线程,但它们是顺序地进入餐厅并坐下的,这是因为lock()方法是阻塞的,当一个客户获得座位锁时,其他客户必须等待直到锁被释放,这就确保了餐厅在任何时候都不会有超过其座位数的客户同时就餐。
trylock方法使用
参考文档:https://docx.iamqiang.com/jdk11/api/java.base/java/util/concurrent/locks/Lock.html#tryLock()
接着模拟餐厅排队的场景,这次使用Lock接口中的tryLock()方法,如果座位不可用,则他们可以选择做其他事情,而不是无限期等待,先定义餐厅类Restaurant,使用ReentrantLock作为座位锁,如下代码:
import?java.util.concurrent.locks.Lock;
import?java.util.concurrent.locks.ReentrantLock;
public?class?Restaurant?{
//?餐厅的座位,用Lock表示
private?final?Lock?seat?=?new?ReentrantLock();
//?客户尝试进入餐厅并坐下,如果无法立即获得座位则返回false
public?boolean?tryEnterAndSit()?{
//?客户尝试获取座位锁,如果成功则进入餐厅,否则返回false
boolean?acquired?=?seat.tryLock();
if?(acquired)?{
try?{
//?客户已经坐下,这里可以执行就餐的相关操作
System.out.println(Thread.currentThread().getName()?+?"?已进入餐厅并坐下。");
//?模拟就餐时间
try?{
Thread.sleep(1000);?//?等待1秒
}?catch?(InterruptedException?e)?{
e.printStackTrace();
}
}?finally?{
//?客户离开时释放座位锁
seat.unlock();
System.out.println(Thread.currentThread().getName()?+?"?已离开餐厅。");
}
}?else?{
//?客户未能获得座位
System.out.println(Thread.currentThread().getName()?+?"?无法进入餐厅,座位已被占用。");
}
return?acquired;
}
}
创建一个client类来模拟多个客户同时尝试进入餐厅,如下代码:
public?class?RestaurantClient?{
public?static?void?main(String[]?args)?{
//?创建一个餐厅实例
Restaurant?restaurant?=?new?Restaurant();
//?模拟多个客户线程
for?(int?i?=?0;?i?
new?Thread(()?->?{
//?尝试进入餐厅
boolean?success?=?restaurant.tryEnterAndSit();
//?如果未能进入餐厅,则做其他事情
if?(!success)?{
System.out.println(Thread.currentThread().getName()?+?"?选择去其他地方。");
}
},?"客户"?+?(i?+?1)).start();
}
}
}
运行RestaurantClient会看到类似以下的输出(由于线程调度的不确定性,输出顺序可能会有所不同):
客户1?已进入餐厅并坐下。
客户2?无法进入餐厅,座位已被占用。
客户2?选择去其他地方。
客户3?无法进入餐厅,座位已被占用。
客户3?选择去其他地方。
客户4?无法进入餐厅,座位已被占用。
客户4?选择去其他地方。
客户5?无法进入餐厅,座位已被占用。
客户5?选择去其他地方。
客户1?已离开餐厅。
从输出中可以看到,只有第一个客户成功进入了餐厅,因为tryLock()方法是非阻塞的,当一个客户获得座位锁时,其他客户会立即得到反馈,知道座位不可用,并选择了做其他事情,这就展示了tryLock()方法如何在避免线程长时间等待发挥作用。
核心总结
Java内置锁:深度解析lock和trylock - 程序员古德
lock方法是一种阻塞性的获取锁的方式,当调用一个对象的lock方法时,如果锁当前被其他线程持有,那么当前线程将会被挂起(即阻塞),直到锁被释放,这种机制确保了只有一个线程能够在同一时间访问被锁保护的代码块或资源,从而避免了并发问题,但是,它也可能导致线程长时间等待,特别是在高并发环境下,如果锁的持有者因为某些原因(如死锁)未能及时释放锁,那么其他线程可能会一直等待下去。
tryLock方法则是一种非阻塞性的获取锁的方式,当调用一个对象的tryLock方法时,如果锁当前可用,那么将成功获得锁并继续执行;如果锁被其他线程持有,那么不会被挂起,而是立即得到一个失败的结果(通常是一个布尔值false),这种方式的好处是可以避免线程长时间等待,因为可以立即知道是否获得了锁,但是,这也意味着可能需要编写更复杂的逻辑来处理未能获得锁的情况,例如通过重试机制或执行备选方案等。
总结:如果希望确保线程能够按照特定的顺序访问共享资源,并且不介意可能的等待时间,那么lock方法是一个不错的选择,但是,如果希望避免线程长时间等待,并且能够处理未能立即获得锁的情况,那么tryLock方法可能更适合。
领取专属 10元无门槛券
私享最新 技术干货