Java
并发编程深入学习—?/p>
Lock
?/p>
Lock
锁介?/p>
?/p>
Java 5.0
之前?/p>
在协调对共享对象的访问时可以使用的机制只?/p>
synchronized
?/p>
volatile
?/p>
Java 5.0
增加了一种新的机制:
ReentrantLock.
它并不是一种替代内置加锁的方法?/p>
而是当内
置加锁机制不适用时,作为一种可选择的高级功能?/p>
Lock
接口
Lock
接口位于
java.util.concurrent.locks
包中,它定义了一组抽象的加锁操作?/p>
public interface Lock {
//
获取?/p>
void lock();
//
如果当前线程未被中断,则获取?/p>
void lockInterruptibly() throws InterruptedException;
//
仅在调用时锁为空闲状态才获取该锁
//
如果锁可用,
则获取锁?/p>
并立即返回?/p>
true
?/p>
如果锁不可用?/p>
则此方法将立即返回?/p>
false
boolean tryLock();
//
如果锁在给定的等待时间内空闲,并且当前线程未被中断,则获取锁
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
//
释放?/p>
void unlock();
//
返回绑定到此
Lock
实例的新
Condition
实例
Condition newCondition();
}
ReetrantLock
实现?/p>
Lock
接口,并提供了与
synchronized
相同的互斥性和内存可见性,
在获?/p>
ReentrantLock
时,
有着与进入同步代码块相同的内存语义,
在释?/p>
ReentrantLock
时,
同样有着与退出同步代码块相同的内存语义?/p>
lock
锁与
synchronized
锁对?/p>
为什么要创建一种与内置锁如此相似的新加锁机制?在大多数情况下,
内置锁都能很好地?/p>
作,但在功能上存在一些局限性?/p>
内置锁无法中断一个正在等待获取锁的线程,或者无法在请求获取一个锁时无限地等待?/p>
去?/p>
内置锁必须在获取该锁的代码块中释放,
这虽然简化了编码工作?/p>
并且与异常处理操作实?/p>
了很好的交互,但却无法实现非阻塞结构的加锁规则?/p>
所以需要一种更加灵活的加锁机制?/p>
lock
锁便应运而生?/p>