在看ConcurrentHashMap 源码的时候看到lock这个锁机制,不明白它和Synchronized的区别,查了一些资料记录下来,在Lock的文档中,对Lock的解释是:Lock实现比synchronized 提供了更多额外的锁操作,它有更灵活的结构,可以支持不同的属性,可以支持多个相关条件的对象。那下边看一下Lock可以提供哪些比synchronized 额外的操作,也就是解决synchronized 存在的问题:
1、它无法中断一个正在等候获得锁的线程
2、也无法通过投票得到锁,如果不想等下去,也就没法得到锁。
第一个问题可以使用lockInterruptibly()方法,lockInterruptibly()方法的执行如下:
如果该锁定没有被另一个线程保持,则获取该锁定并立即返回,将锁定的保持计数设置为 1。
如果当前线程已经保持此锁定,则将保持计数加 1,并且该方法立即返回。
如果锁定被另一个线程保持,则出于线程调度目的,禁用当前线程,并且在发生以下两种情况之一以前,该线程将一直处于休眠状态:
a、锁定由当前线程获得;
b、或者其他某个线程中断当前线程。
如果当前线程获得该锁定,则将锁定保持计数设置为1。
如果当前线程:
a、在进入此方法时已经设置了该线程的中断状态;
b、或者在等待获取锁定的同时被中断。
则抛出 InterruptedException,并且清除当前线程的已中断状态。
即lockInterruptibly()方法允许在等待时由其它线程调用它的Thread.interrupt方法来中断等待而直接返回,这时不再获取锁,而会抛出一个InterruptedException。
第二个问题使用trylock()方法或tryLock(long timeout, TimeUnit timeUnit)方法。trylock()方法:如果获取了锁立即返回true,如果别的线程正持有锁,立即返回false;
tryLock(long timeout, TimeUnit timeUnit)方法:如果获取了锁定立即返回true,如果别的线程正持有锁,会等待参数给定的时间,在等待的过程中,如果获取了锁定,就返回true,如果等待超时,返回false;看一个例子:打个不是很恰当的比分:你现在正在忙于工作,突然感觉内急,于是你跑向洗手间,到门口发现一个“清洁中,暂停使用”的牌牌。没办法,工作又忙,所以你只好先放弃去洗手间回去忙工作,可能如此反复,终于你发现可以进了,于是......
像这样的场景用synchronized你怎么实现?没办法,如果synchronized,当你发现洗手间无法暂时无法进入时,就只能乖乖在门口干等了。而使用trylock()呢,首先你试着去洗手间,发现暂时无法进入(trylock返回false),于是你继续忙你的工作,如此反复,直到可以进入洗手间为止(trylock返回true)。甚至,你非常急,你可以尝试性的在门口等20秒,不行再去忙工作(trylock(20, TimeUnit.SECONDS);)。
synchrozized:
当代码块 加上 synchrozized之后,有两条改变。一个是原子性(atomicity),一个是可见性(visibility)。原子性意味着一次只能有一个线程获得代码锁,进入synchronized 包围的代码块中执行。而可见性则是对不同范围内对变量的修改做出的一致性。强调变量的可见性与一致性,是因为在Java 内存中,内存缓存和编译器优化在多线程条件下会造成各种反常行为。一般来说,线程以某种不必让其他线程立即可以看到的方式(不管这些线程在寄存器(register)中、在处理器特定的缓存(CPU cache)中,还是通过指令重排或者其他编译器优化),不受缓存变量值的约束,但是加人synchronized关键字之后,那么运行库将确保某一线程对变量所做的更新先于对现有 synchronized 块所进行的更新,当进入由同一监控器(lock)保护的另一个 synchronized 块时,将立刻可以看到这些对变量所做的更新。类似的规则也存在于 volatile 变量。
Lock:
自JDK1.5以为,Java提供了java.util.concurrent这个并发包,在它的子包locks中,提供了一系列关于锁的抽象的类。有二种锁:ReentrantLock,ReentrantReadWriteLock。在ReentrantLock锁的例子的实现如下:
Lock lock = new ReentrantLock();
try {
lock.lcok();
// do something
} finally {
lock.unlock();
}
上面这段代码,首先创建了一个lock,然后调用它的lock()方法,开启锁定,在最后调用它的unlock()解除锁定。值得注意的时,一般在使用锁时,都应该按上面的风格书写代码,即lock.unlock()最好放在finally块,这样可以防止,执行do something时发生异常后,导致锁永远无法被释放。
ReentrantReadWriteLock用法与ReentrantLock基本一样,只是ReentrantReadWriteLock实现了特殊规则(读写锁),在ReentrantReadWriteLock中有两个内部类ReentrantReadWriteLock.ReadLock和ReentrantReadWriteLock.WriteLock(实际上不止两个内部类,还有实现AbstractQueuedSynchronizer的Sync等等),这两个类分别可以使用ReentrantReadWriteLock的readLock()和writeLock()返回,该读写锁的规则是:只要没有writer,读取锁定可以由多个reader 线程同时保持,而写入锁定是独占的。ReentrantReadWriteLock锁的例子:
package test.mult;
import java.util.concurrent.locks.ReentrantReadWriteLock;
/**
* @ClassName: ReadWriteLockTest
* @author whwang
* @date 2012-1-11 下午02:20:59
*/
public class ReadWriteLockTest {
static ReentrantReadWriteLock lock = new ReentrantReadWriteLock(true);
public static void main(String[] args) {
// 是否可以进入多个reader - 可以
// 是否可以进入多个writer - 不可以
// 当有reader进入后, writer是否可以进入 - 不可以
// 当有writer进入后, reader是否可以进入 - 不可以
MyThread t1 = new MyThread(0, "t1");
MyThread t2 = new MyThread(0, "t2");
MyThread t3 = new MyThread(1, "t3");
t1.start();
t2.start();
t3.start();
}
private static class MyThread extends Thread {
private int type;
private String threadName;
public MyThread(int type, String threadName) {
this.threadName = threadName;
this.type = type;
}
@Override
public void run() {
while (true) {
if (type == 0) {
// read
ReentrantReadWriteLock.ReadLock readLock = null;
try {
readLock = lock.readLock();
readLock.lock();
System.err.println("to read...." + threadName);
try {
Thread.sleep(5 * 1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
readLock.unlock();
}
} else {
// write
ReentrantReadWriteLock.WriteLock writeLock = null;
try {
writeLock = lock.writeLock();
writeLock.lock();
System.err.println("to write...." + threadName);
try {
Thread.sleep(5 * 1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
} finally {
writeLock.unlock();
}
}
}
}
}
}