线程基础(九)ReentrantReadWriteLock ,synchronized和ReentrantLock的对比

时间:2019-01-22
本文章向大家介绍线程基础(九)ReentrantReadWriteLock ,synchronized和ReentrantLock的对比,主要包括线程基础(九)ReentrantReadWriteLock ,synchronized和ReentrantLock的对比使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

读写锁ReentrantReadWriteLock概述

大型网站中很重要的一块内容就是数据的读写,ReentrantLock虽然具有完全互斥排他的效果(即同一时间只有一个线程正在执行lock后面的任务),但是效率非常低。所以在JDK中提供了一种读写锁ReentrantReadWriteLock,使用它可以加快运行效率。

读写锁表示两个锁,一个是读操作相关的锁,称为共享锁;另一个是写操作相关的锁,称为排他锁。我把这两个操作理解为三句话:

1、读和读之间不互斥,因为读操作不会有线程安全问题

2、写和写之间互斥,避免一个写操作影响另外一个写操作,引发线程安全问题

3、读和写之间互斥,避免读操作的时候写操作修改了内容,引发线程安全问题

总结起来就是,多个Thread可以同时进行读取操作,但是同一时刻只允许一个Thread进行写入操作

读和读共享

先证明一下第一句话"读和读之间不互斥"

public class Test06 {
	ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
	
	public void methodA(){
		try {
			lock.readLock().lock();
			System.out.println(Thread.currentThread().getName()+"获取锁");
			Thread.sleep(Integer.MAX_VALUE);
		} catch (Exception e) {
			e.printStackTrace();
		}finally{
			lock.readLock().unlock();
		}
	}
	
	public static void main(String[] args) {
		final Test06 t = new Test06();
	    Runnable r = new Runnable() {
			@Override
			public void run() {
				t.methodA();
			}
		};
		
		Thread t1 = new Thread(r,"线程1");
		Thread t2 = new Thread(r,"线程2");
		t1.start();
		t2.start();
	}
}
线程1获取锁
线程2获取锁

如上诉代码,当第一个线程获取锁以后,让它进行长时间休眠。如果互斥则线程2应该无法获取锁,所以读和读之间不互斥

写和写互斥

改写上方代码

public class Test06 {
	ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
	
	public void methodA(){
		try {
//			lock.readLock().lock();
			lock.writeLock().lock();
			System.out.println(Thread.currentThread().getName()+"获取锁");
			Thread.sleep(Integer.MAX_VALUE);
		} catch (Exception e) {
			e.printStackTrace();
		}finally{
			lock.writeLock().unlock();
		}
	}
	
	public static void main(String[] args) {
		final Test06 t = new Test06();
	    Runnable r = new Runnable() {
			@Override
			public void run() {
				t.methodA();
			}
		};
		
		Thread t1 = new Thread(r,"线程1");
		Thread t2 = new Thread(r,"线程2");
		t1.start();
		t2.start();
	}
}
线程1获取锁

当线程1获取锁以后,释放前线程2获取不到锁。证明写和写之间互斥

读和写互斥

最后证明一下第三句话"读和写之间互斥",证明方法无非是把上面二者结合起来而已

public class Test07 {
	ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
	
	public void write(){
		try {
			lock.writeLock().lock();
			System.out.println(Thread.currentThread().getName()+"获取锁");
			Thread.sleep(Integer.MAX_VALUE);
		} catch (Exception e) {
			e.printStackTrace();
		}finally{
			lock.writeLock().unlock();
		}
	}
	
	public void read(){
		try {
			lock.readLock().lock();
			System.out.println(Thread.currentThread().getName()+"获取锁");
			Thread.sleep(Integer.MAX_VALUE);
		} catch (Exception e) {
			e.printStackTrace();
		}finally{
			lock.readLock().unlock();
		}
	}
	public static void main(String[] args) {
		final Test07 t = new Test07();
		
		Thread t1 = new Thread(new Runnable() {
			@Override
			public void run() {
				t.write();
			}
		},"线程1");
		Thread t2 = new Thread(new Runnable() {
			@Override
			public void run() {
				t.write();
			}
		},"线程2");
		t1.start();
		t2.start();
	}
}
线程1获取锁

当线程1获取锁以后,释放前线程2获取不到锁。证明读和写之间互斥

 

synchronized和ReentrantLock的对比

到现在,看到多线程中,锁定的方式有2种:synchronized和ReentrantLock。两种锁定方式各有优劣,下面简单对比一下:

1、synchronized是关键字,就和if...else...一样,是语法层面的实现,因此synchronized获取锁以及释放锁都是Java虚拟机帮助用户完成的;ReentrantLock是类层面的实现,因此锁的获取以及锁的释放都需要用户自己去操作。特别再次提醒,ReentrantLock在lock()完了,一定要手动unlock()

2、synchronized简单,简单意味着不灵活,而ReentrantLock的锁机制给用户的使用提供了极大的灵活性。这点在Hashtable和ConcurrentHashMap中体现得淋漓尽致。synchronized一锁就锁整个Hash表,而ConcurrentHashMap则利用ReentrantLock实现了锁分离,锁的知识segment而不是整个Hash表

3、synchronized是不公平锁,而ReentrantLock可以指定锁是公平的还是非公平的

4、synchronized实现等待/通知机制通知的线程是随机的,ReentrantLock实现等待/通知机制可以有选择性地通知

5、和synchronized相比,ReentrantLock提供给用户多种方法用于锁信息的获取,比如可以知道lock是否被当前线程获取、lock被同一个线程调用了几次、lock是否被任意线程获取等等

6. ReentrantLock的某些方法可以决定多长时间内尝试获取锁,如果获取不到就抛异常,这样就可以一定程度上减轻死锁的可能性,如果锁被另一个线程占据了,synchronized只会一直等待,很容易错序死锁

7.synchronized的话,锁的范围是整个方法或synchronized块部分;而Lock因为是方法调用,可以跨方法,灵活性更大

 

总结起来,我认为如果只需要锁定简单的方法、简单的代码块,那么考虑使用synchronized,复杂的多线程处理场景下可以考虑使用ReentrantLock。当然这只是建议性地,还是要具体场景具体分析的。

JDK1.5版本只有由于对synchronized做了诸多优化,效率上synchronized和ReentrantLock应该是差不多。