首页 > 代码库 > Synchronized和Lock接口
Synchronized和Lock接口
关于synchronized字段,不管该关键字是修饰方法还是修饰同步代码块,synchronzed拿到的都是对象。
当synchronized修饰的是方法时,synchronized所拿到的是调用该方法的对象的锁,一般情况下都是this的锁;
当synchronized()修饰的同步代码块时,synchronized拿到的是指定对象的锁。
扩展:
当synchronized修饰的静态方法时,由于静态方法不包含this,属于类层次的方法,所以,synchronized拿到的是这个方法所属Class对象的锁。
java中的对象每个只含有一个锁,通过synchronized来获取对象的锁。
注意:当方法异常退出时,其对象锁可以有JVM进行释放。
占有锁的线程释放锁时一般是以下三种情况:
1、 占有锁的线程执行完了代码块,然后释放对锁的占有;
2、 占有锁的线程发生了异常,此时JVM会让线程自动释放锁;
3、 占有锁的线程调用了wait()方法,从而进入了WAITING状态需要释放锁。
探究-->对象都含有什么锁?
对象锁:又称独占排它锁,通过名字我们便可知道,在多线程程序中,一旦一个线程到达了共享区(即synchronized修饰的区域)。那么该线程将拥有该共享区的对象锁,其他线程想要进入,只能等到该线程释放了锁才可进入。对应于非静态方法和非静态代码块。
类锁:方法或代码块所在类的类对象的锁。对应于静态方法和静态代码块。
Lock接口
体系类图:
方法介绍:
Lock:是Lock接口中使用最多的获取锁的方法,如果锁被其他线程占用就等待。由于Lock接口是基于JDK层面的,所以,锁的释放动作必须手动进行。不像synchronized是基于Java语言的特性,属于JVM层面,锁的获取和释放动作都由JVM自动进行,对开发者是透明的。
使用方式:
Lock lock = ...; lock.lock(); try{ //处理任务 }catch(Exception ex){
}finally{ lock.unlock(); //释放锁 }
}finally{ lock.unlock(); //释放锁 }
tryLock:表示用来尝试获取锁,如果获取成功即返回TRUE,如果锁被其他线程占用,则返回FALSE;该方法会立即返回结果,不会一直处于等待状态。
tryLock(long time,TimeUnit unit):与tryLock类似,区别在于这个方法在拿不到锁的情况下会等待一个时间time,在时间期限之内如果还拿不到锁,就返回FALSE;同时可以相应中断。如果在一开始或者等待期间获得了锁,则返回true。
问题:如果在开始没有拿到锁,那么代码块会进入到等待状态么?
猜想:我觉得会进入等待状态,不过在等待的这段时间内,会存在一个响应机制来监测别的线程是否释放了锁,如果释放了锁,则直接有该线程获取锁,该方法返回TRUE;如果没有释放,那么该方法将不再享有响应机制的提醒,并返回FALSE。
使用方式:
Lock lock = ...; if(lock.tryLock()) { try{ //处理任务 }catch(Exception ex){
}finally{ lock.unlock(); //释放锁 } }else { //如果不能获取锁,则直接做其他事情 }
}finally{ lock.unlock(); //释放锁 } }else { //如果不能获取锁,则直接做其他事情 }
lockInterruptibly:当通过这个方法尝试获取锁时,如果线程正在等待获取锁,那么这个线程能够响应中断,即被自己或者其他线程中断线程的等待状态。例如,当两个线程同时通过lock.lockInterruptibly()方法获取锁时,假如线程A获取了锁,那么线程B就只能进入等待状态,那么对线程B调用ThreadB.interrupt()能够中断线程B的等待状态。
注意:lockInterruptibly方法必须放在try块中或者在调用lockInterruptibly的方法外声明抛出InterruptedException,推荐使用后者。
使用方式:
public void method() throws InterruptedException { lock.lockInterruptibly(); try { //..... } finally { lock.unlock(); } }
疑问:释放掉线程的等待状态有什么用处?
相比于synchronized,等待状态的线程无法响应中断。提高了代码的灵活性,当不想持续的等待下去时,响应中断去做其余的事情,更具灵活性。
ReadWriteLock
该锁提升了读操作的效率,不过要注意的是,如果有一个线程已经占用了读锁,则此时其他线程如果要申请写锁,则申请写锁的线程会一直等待释放读锁。如果有一个线程已经占用了写锁,则此时其他线程如果申请写锁或者读锁,则申请的线程也会一直等待释放写锁。
Lock和synchronized的选择:
1、 Lock是一个接口,属于JDK层面的实现;而synchronized属于Java语言的特性,其实现有JVM来控制。
2、 synchronized在发生异常时,会自动释放掉锁,故不会发生死锁现(此时的死锁一般是代码逻辑引起的);而Lock必须在finally中主动unlock锁,否则就会出现死锁。
3、 Lock能够响应中断,让等待状态的线程停止等待;而synchronized不行。
4、 通过Lock可以知道线程是否成功获得了锁,而synchronized不行。
5、 Lock提高了多线程下对读操作的效率。
扩展
可重入锁:synchronized和ReentrantLock都是可重入锁。当一个线程执行到某个synchronized方法时,比如说method1,而在method1中会调用另外一个synchronized方法method2,此时线程不必重新去申请锁,而是可以直接执行方法method2。
可中断锁:通过上面的例子,我们可以得知Lock是可中断锁,而synchronized不是。
公平锁:尽量以请求的顺序来获取锁,同是有多个线程在等待一个锁,当这个锁被释放时,等待时间最久的线程(最先请求的线程)会获得该锁。synchronized是非公平锁,而ReentrantLock和ReentReadWriteLock默认情况下是非公平锁,但是可以设置成公平锁
ReentrantLock lock = new ReentrantLock(true);
ReentrantReadWriteLock lock = new ReentrantReadWriteLock(true);
设置为TRUE即为公平锁,为FALSE或者无参数为非公平锁。
读写锁:读写锁将对临界资源的访问分成了两个锁,一个读锁和一个写锁。即ReadWriteLock接口及其实现ReentrantReadWriteLock。
Synchronized和Lock接口
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。