前言
如果一个代码块被synchronized修饰了,当一个线程获取了相应的锁,并执行该代码块时,其他线程便只能一直等待,等待获取锁的释放,现在有这么一种情况,这个获取锁的线程由于要等待IO或者其他原因(比如调用sleep方法)被阻塞了,但是又没有释放锁,其他线程只能干巴巴地等着,在这种情况下,非常影响程序执行效率
所以Lock应运而生,可以不让等待的线程一直等待下去(比如只等待一定的时间或者能够响应中断)
一、Lock接口
(1)与synchronzed区别
synchronized是JVM层面的内置锁,而Lock则是java层面的显示锁,Lock提供了一种可重入的、可轮询的、定时的以及可中断的锁获取操作。
采用synchronized不需要用户去手动释放锁,当synchronized方法或者synchronized代码块执行完之后,系统会自动让线程释放对锁的占用;而Lock则必须要用户去手动释放锁,如果没有主动释放锁,就有可能导致出现死锁现象。
(2)lock接口源码详解
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
Condition newCondition();
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
}
lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的。unLock()方法是用来释放锁的。 newCondition()方法返回一个Condition对象
lock():此方法是平常使用得最多的一个方法,就是用来获取锁。如果锁已被其他线程获取,则进行等待。
Lock lock = ...;
lock.lock();
try{
//处理任务
}catch(Exception ex){
}finally{
lock.unlock(); //释放锁
}
tryLock():此方法是有返回值的,它表示用来尝试获取锁,如果获取成功,则返回true,如果获取失败(即锁已被其他线程获取),则返回false,也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。
Lock lock = ...;
if(lock.tryLock()) {
try{
//处理任务
}catch(Exception ex){
}finally{
lock.unlock(); //释放锁
}
}else {
//如果不能获取锁,则直接做其他事情
}
tryLock(long time, TimeUnit unit):此方法和tryLock()方法是类似的,只不过区别在于这个方法在拿不到锁时会等待一定的时间,在时间期限之内如果还拿不到锁,就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁,则返回true。
lockInterruptibly()方法比较特殊,当通过这个方法去获取锁时,如果线程正在等待获取锁,则这个线程能够响应中断,即中断线程的等待状态。也就使说,当两个线程同时通过lock.lockInterruptibly()想获取某个锁时,假若此时线程A获取到了锁,而线程B只有在等待,那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
二、ReentrantLock
(1)模拟可中断的锁获取
Lock中的lockInterruptibly() 可以在获得锁的同时保持对中断的响应,但是内置锁synchronized却很难实现这个功能。
synchronized
如下程序,创建一任务,假设该任务需要执行很长时间才能结束(使用死循环来模拟时长)。现在有两个线程竞争该资源的内置锁,在等待一段时间后,想要终止线程t2的锁获取等待操作,使用t2.interrupt(); 尝试中断线程t2。遗憾的是,此时t2根本不会响应这个中断操作,它会继续等待直到获得资源锁。
public class InterruptedLockTest implements Runnable{
public synchronized void doCount(){
//使用死循环表示此操作要进行很长的一段时间才能结束
while(true){}
}
@Override
public void run() {
doCount();
}
}
public static void main(String[] args) throws InterruptedException {
InterruptedLockTest test = new InterruptedLockTest();
Thread t1 = new Thread(test);
Thread t2 = new Thread(test);
t1.start();
t2.start();
//等待两秒,尝试中断线程t2的等待
TimeUnit.SECONDS.sleep(2);
t2.interrupt();
//等待1秒,让 t2.interrupt(); 执行生效
TimeUnit.SECONDS.sleep(1);
System.out.println("线程t1是否存活:" + t1.isAlive());
System.out.println("线程t2是否存活:" + t2.isAlive());
}
console打印:
线程t1是否存活:true
线程t2是否存活:true
Lock
public class LockDemo implements Runnable {
@Override
public void run() {
try {
doCount();
} catch (InterruptedException e) {
System.out.println("被中断....");
}
}
Lock lock = new ReentrantLock();
public void doCount() throws InterruptedException {
lock.lockInterruptibly();
try {
while (true){
}
}catch (Exception e){
}finally {
lock.unlock();
}
}
public static void main(String[] args) throws InterruptedException {
LockDemo lockDemo = new LockDemo();
Thread t1 = new Thread(lockDemo);
Thread t2 = new Thread(lockDemo);
t1.start();
t2.start();
TimeUnit.SECONDS.sleep(2);
t2.interrupt();
//等待1秒,让 t2.interrupt(); 执行生效
TimeUnit.SECONDS.sleep(1);
System.out.println("线程t1是否存活:" + t1.isAlive());
System.out.println("线程t2是否存活:" + t2.isAlive());
}
}
console打印:
被中断....
线程t1是否存活:true
线程t2是否存活:false
(2)模拟可轮询(避免死锁)
相比于synchronized内置锁的无条件锁获取模式,Lock提供了tryLock() 实现可定时和可轮询的锁获取模式,这也使Lock具有更完善的错误恢复机制。在内置锁中,死锁是一个很严重的问题,造成死锁的原因之一可能是,锁获取顺序不一致导致程序死锁。比如说,线程1持有A对象锁,正在等待获取B对象锁;线程2持有B对象锁,正在等待获取A对象锁。这样,两个线程都会由于获取不到想要的锁而陷入死锁的境地。解决办法可以是,两个线程要么同时获取两个锁,要么一个锁都不获取。Lock 的可定时和可轮询锁就可以很好的满足该条件,从而避免死锁的发生
synchronized死锁问题
public class TestDeadLock implements Runnable{
int flag ;
static Object o1 = new Object();
static Object o2 = new Object();
@Override
public void run() {
if(flag==0){
synchronized (o1) {
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (o2) {
System.out.println("flag==0");
}
}
}
else if (flag==1){
synchronized (o2) {
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (o1) {
System.out.println("flag==1");
}
}
}
}
public static void main(String[] args) {
TestDeadLock td1 = new TestDeadLock();
TestDeadLock td2 = new TestDeadLock();
td1.flag = 0;
td2.flag = 1;
Thread t1 = new Thread(td1);
Thread t2 = new Thread(td2);
t1.start();
t2.start();
}
}
ReentrantLock可轮询
// 资源类
public class Resource {
//资源总和
private int resourceNum;
// 显示锁
public Lock lock = new ReentrantLock();
public Resource(int resourceNum){
this.resourceNum = resourceNum;
}
//返回此资源的总量
public int getResourceNum(){
return resourceNum;
}
}
public class LockTest1 {
//传入两个资源类和预期操作时间,在此期间内返回两个资源的数量总和
public int getResource(Resource resourceA, Resource resourceB, long timeout, TimeUnit unit)
throws InterruptedException {
// 获取当前时间,算出操作截止时间
long stopTime = System.nanoTime() + unit.toNanos(timeout);
while(true){
try {
// 尝试获得资源A的锁
if (resourceA.lock.tryLock()) {
try{
// 如果获得资源A的锁,尝试获得资源B的锁
if(resourceB.lock.tryLock()){
//同时获得两资源的锁,进行相关操作后返回
return getSum(resourceA, resourceB);
}
}finally {
resourceB.lock.unlock();
}
}
}finally {
resourceA.lock.unlock();
}
// 判断当前是否超时,规定-1为错误标识
if(System.nanoTime() > stopTime)
return -1;
//睡眠1秒,继续尝试获得锁
TimeUnit.SECONDS.sleep(1);
}
}
// 获得资源总和
public int getSum(Resource resourceA,Resource resourceB){
return resourceA.getResourceNum()+resourceB.getResourceNum();
}
}
(3)公平锁
背景
CPU在调度线程的时候是在等待队列里随机挑选一个线程,由于这种随机性所以是无法保证线程先到先得的(synchronized控制的锁就是这种非公平锁)。但这样就会产生饥饿现象,即有些线程(优先级较低的线程)可能永远也无法获取cpu的执行权,优先级高的线程会不断的强制它的资源。那么如何解决饥饿问题呢,这就需要公平锁了。
公平锁可以保证线程按照时间的先后顺序执行,避免饥饿现象的产生。但公平锁的效率比较地,因为要实现顺序执行,需要维护一个有序队列。
// 也可以指定公平性
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
//默认创建非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
Demo
package com.jalja.base.threadTest;
import java.util.concurrent.locks.ReentrantLock;
public class LockFairTest implements Runnable{
//创建公平锁
private static ReentrantLock lock=new ReentrantLock(true);
public void run() {
while(true){
lock.lock();
try{
System.out.println(Thread.currentThread().getName()+"获得锁");
}finally{
lock.unlock();
}
}
}
public static void main(String[] args) {
LockFairTest lft=new LockFairTest();
Thread th1=new Thread(lft);
Thread th2=new Thread(lft);
th1.start();
th2.start();
}
}
console打印:
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
分析结果可看出两个线程是交替执行的,几乎不会出现同一个线程连续执行多次。
三、Synchronized与Lock的区别
锁类型
-
可重入锁:在执行对象中所有同步方法不用再次获得锁
-
可中断锁:在等待获取锁过程中可中断
-
公平锁: 按等待获取锁的线程的等待时间进行获取,等待时间长的具有优先获取锁权利
-
读写锁:对资源读取和写入的时候拆分为2部分处理,读的时候可以多线程一起读,写的时候必须同步地写
区别
类别 | synchronized | Lock |
---|---|---|
存在层次 | Java的关键字,在jvm层面上 | 是一个类 |
锁的释放 | 1、以获取锁的线程执行完同步代码,释放锁 2、线程执行发生异常,jvm会让线程释放锁 | 在finally中必须释放锁,不然容易造成线程死锁 |
锁的获取 | 假设A线程获得锁,B线程等待。如果A线程阻塞,B线程会一直等待 | 分情况而定,Lock有多个锁获取的方式,具体下面会说道,大致就是可以尝试获得锁,线程可以不用一直等待 |
锁状态 | 无法判断 | 可以判断 |
锁类型 | 可重入 不可中断 非公平 | 可重入 可中断 可公平(两者皆可) |
性能 | 少量同步 | 大量同步 |
关于读写锁
我们知道,当多个线程读写文件时,读操作和写操作会发生冲突现象,写操作和写操作也会发生冲突现象,但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话,就会导致一个问题,即当多个线程都只是进行读操作时,也只有一个线程在可以进行读操作,其他线程只能等待锁的释放而无法进行读操作。因此,需要一种机制来使得当多个线程都只是进行读操作时,线程之间不会发生冲突。同样地,Lock也可以解决这种情况 (解决方案:ReentrantReadWriteLock) 。