LOCK
java中提供了两种不同的方式加锁,synchronized和juc包下的Lock接口。
sychronized可重入、不可中断、非公平;Lock可重入、可中断、非公平和公平;
Lock是java 1.5中引入的线程同步工具,它主要用于多线程下共享资源的控制。
- 需要用户主动释放锁
- 可中断,设置超时中断
- 默认也是非公平锁,可以设置成公平锁
- 锁绑定多个condition用来精确唤醒
常见方法:
-
void lock();尝试获取锁,获取成功则返回,否则阻塞当前线程
-
void lockInterruptibly() throws InterruptedException;尝试获取锁,线程在成功获取锁之前被中断,则放弃获取锁,抛出异常
-
boolean tryLock();尝试获取锁,获取锁成功则返回true,否则返回false
-
boolean tryLock(long time, TimeUnit unit)尝试获取锁,若在规定时间内获取到锁,则返回true,否则返回false,未获取锁之前被中断,则抛出异常
-
void unlock();释放锁,一般需要使用try/finally结构保证锁的释放
Lock有三个实现类
一个是ReentrantLock
,另两个是ReentrantReadWriteLock 类中的两个静态内部类ReadLock和WriteLock
。这些类的底层使用都依赖于juc包 抽象队列同步器AbstractQueuedSynchronizer
使用方法:多线程下访问(互斥)共享资源时, 访问前加锁,访问结束以后解锁, 解锁的操作推荐放入finally块中。
private static final ReentrantLock lock=new ReentrantLock(); 定义锁对象
在具体方法中
lock.lock();
try{
代码块;
}finally{
lock.unlock();
}
synchronized的缺陷
sychronized是java的一个关键字,是java内置的特性,没有区分读写锁
Lock接口
实现类ReentrantLock,区分读写ReadWriteLock接口
- tryLock
- lock
具体实现类ReentrantLock
实现了Lock接口
- newCondition创建一个条件对象,用来管理得到锁但是不能执行工作的线程
如果一个线程lock.lock()已经获取了锁,也可以多次调用这个方法(重入锁名称的来源),都可以获取到锁,但是获取多少次锁必须通过lock.unlock释放多少次,否则其它线程会阻塞在lock.lock()方法上,注意lock()方法和unlock()方法的执行次数必须匹配,所以一般建议使lock.lock();try{}finally{lock.unlock();}
当调用condition.await()阻塞线程时会自动释放锁,不管调用了多少次lock.lock(),这时阻塞lock.lock()方法上线程则可以获取锁
当调用condition.signal()唤醒线程时会继续上次阻塞的位置继续执行,默认会自动重新获取锁(注意和阻塞时获取锁的次数一致)
ReentrantReadWriteLock是Lock的另一种实现方式,ReentrantLock是一个排他锁,同一时间只允许一个线程访问,而ReentrantReadWriteLock允许多个读线程同时访问,但不允许写线程和读线程、写线程和写线程同时访问。相对于排他锁,提高了并发性。在实际应用中,大部分情况下对共享数据(如缓存)的访问都是读操作远多于写操作,这时ReentrantReadWriteLock能够提供比排他锁更好的并发性和吞吐量。
ReentrantLock底层实现
底层实现依赖于Sync实现的,Sync是AbstractQueuedSynchronizer的抽象子类。 在ReentrantLock中有2个静态内部类NonfairSync和FairSync分别代表非公平锁 和公平锁,可以在创建ReentrantLock对象时使用参数进行指定。
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
ReentrantLock提供了很多的额外方法,例如isFair()可以判断锁是否为公平锁isLocked判断锁是否被任何线程获取了,isHeldByCurrentThread判断锁是否被 当前线程获取,hasQueuedThreads()判断是否有线程在等待该锁
ReadWriteLock接口
实例上和Lock接口无关,提供了通过分开读锁和写锁,控制锁阻塞的方法,提高程序的执行效率
public interface ReadWriteLock {
Lock readLock(); 用于获取读锁,读锁之间不相互阻塞
Lock writeLock(); 用于获取写锁,写锁和其它锁互斥
}
功能在于将文件的读写操作分开,分成2个锁分配给线程,从而实现多个线程可以同时执行读操作
实现类ReentrantReadWriteLock
提供了写锁和读锁的实现
Lock和synchronized的区别:
- Lock是一个接口,而synchronized是Java中的关键字,synchronized是内置的
语言实现 - synchronized在发生异常时,会自动释放线程占有的锁,因此不会导致死锁现象
发生;而Lock在发生异常时,如果没有主动通过unLock()去释放锁(所以建议使用的
try/finally结构),则很可能造成死锁现象,因此使用Lock时需要在finally块中
释放锁 - Lock可以让等待锁的线程响应中断,而synchronized却不行,使用synchronized
时,等待的线程会一直等待下去,不能够响应中断 - 通过Lock可以知道有没有成功获取锁,而synchronized却无法办到
Thread类中提供了一个静态方法,可以判断boolean holdsLock(Object obj) - Lock可以提高多个线程进行读操作的效率。
在性能上来说,如果竞争资源不激烈,两者的性能是差不多的,而当竞争资源非常激烈
时(即有大量线程同时竞争),此时Lock的性能要远远优于synchronized。所以说,在
具体使用时要根据适当情况选择。
//存取款轮流操作,各自5个线程,测试结果是否正确
public class Test2 {
public static void main(String[] args) {
Account a=new Account();
for(int i=0;i<5;i++) {
int k=i;
new Thread(()->{
a.cunKuan(k);
}).start();
new Thread(()->{
a.quKuan(k);
}).start();
}
}
}
class Account {
private long id;
private double balance;
//不能使用static,因为同一个账户操作才有互斥,不是所有账户都使用同一个锁
private final Lock lock = new ReentrantLock(); // 账户锁
private final Condition _save = lock.newCondition(); // 存款条件,一个锁上可以定义无数个条件变量
private final Condition _draw = lock.newCondition(); // 取款条件
/*
* 存款
* > lock.lock(); // 获取锁
* > _save.await(); // 阻塞存款操作, await后就隐示自动释放lock直到被唤醒自动获取
* > _draw.signalAll(); // 唤醒所有等待取款线程
* > lock.unlock(); // 释放锁
*
* 取款
* > lock.lock(); // 获取锁
* > _draw.await(); // 阻塞取款操作, await后就隐示自动释放lock直到被唤醒自动获取
* > _save.signalAll(); // 唤醒所有存款操作
* > lock.unlock(); // 释放锁
*/
public void cunKuan(double num) {
lock.lock();
try {
System.out.println(Thread.currentThread()+"开始存款");
balance+=num;
System.out.println(Thread.currentThread()+"存款结束");
_save.await();
_draw.signal();
} catch(Exception e){
e.printStackTrace();
}finally {
lock.unlock();
}
}
public void quKuan(double num) {
lock.lock();
try {
System.out.println(Thread.currentThread()+"开始取款");
balance+=num;
System.out.println(Thread.currentThread()+"取款结束");
_draw.await();
_save.signal();
} catch(Exception e){
e.printStackTrace();
}finally {
lock.unlock();
}
}