java并发编程深入学习分析.docxVIP

Java 并发编程深入学习—— Lock 锁 Lock 锁介绍 在 Java 5.0 之前，在协调对共享对象的访问时可以使用的机制只有 synchronized 和 volatile 。 Java 5.0 增加了一种新的机制： ReentrantLock. 它并不是一种替代内置加锁的方法， 而是当内 置加锁机制不适用时，作为一种可选择的高级功能。 Lock 接口 Lock 接口位于 java.util.concurrent.locks 包中，它定义了一组抽象的加锁操作。 public interface Lock { //获取锁 void lock(); // 如果当前线程未被中断，则获取锁 void lockInterruptibly() throws InterruptedException; //仅在调用时锁为空闲状态才获取该锁 〃如果锁可用，则获取锁，并立即返回值 true。如果锁不可用，则此方法将立即返回值 false boolean tryLock(); //如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁 boolean tryLock(long time, TimeUnit unit) throws InterruptedException; //释放锁 void unlock(); //返回绑定到此 Lock 实例的新 Condition 实例 Condition newCondition(); } ReetrantLock 实现了 Lock 接口，并提供了与 synchronized 相同的互斥性和内存可见性， 在获取 ReentrantLock 时，有着与进入同步代码块相同的内存语义， 在释放 ReentrantLock 时， 同样有着与退出同步代码块相同的内存语义。 lock 锁与 synchronized 锁对比 为什么要创建一种与内置锁如此相似的新加锁机制？在大多数情况下， 内置锁都能很好地工 作，但在功能上存在一些局限性。 内置锁无法中断一个正在等待获取锁的线程，或者无法在请求获取一个锁时无限地等待下 去。 内置锁必须在获取该锁的代码块中释放， 这虽然简化了编码工作， 并且与异常处理操作实现 了很好的交互，但却无法实现非阻塞结构的加锁规则。 所以需要一种更加灵活的加锁机制， lock 锁便应运而生。 Lock 锁的标准使用形式如下： Lock lock = new ReentrantLock(); if (lock.tryLock()) {// 尝试获取锁 try { //更新对象状态 //捕获异常，并在必要时恢复不变性条件 } finally { lock.unlock();// 注意要记得释放锁 } } else { // 获取锁失败执行其他操作 } 如果没有使用 finally 来释放 Lock, 那么程序出错时，将很难追踪到最初发生错误的位置，因 为没有记录应该释放锁的位置和时间。 这一点也是 ReetrantLock 不能完全替代 synchronized 的原因， 因为它更加危险，程序并没有 自动清除锁的机制，使用起来需要格外小心。 锁的分类 可重入锁 当某一个线程请求一个由其他线程持有的锁时， 发去请求的线程就会阻塞。 由于内置锁可 重入特性的存在， 如果某个线程视图获得一个已经由它自己持有的锁， 那么这个请求却会成 功。 如果锁具备可重入性，则称作为可重入锁。 .像 synchronized 和 ReentrantLock 都是可重入 锁，重入性表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。 重入锁的实现机制如下： 为每个锁关联一个获取计数值和一个所有者线程。 当计数器为 0 时这个锁被认为没有被任 何线程持有。当线程请求一个未被持有的锁时， JVM 将记下锁的持有者，并且将获取计数 器置为 1。如果同一个线程再次获取这个锁，计数器将递增，而当线程退出同步代码块时， 计数器会相应地递减。当计数器为 0 时，这个锁将被释放。 可举个简单的例子，当一个线程执行到某个 synchronized方法时，比如说 methodi，而 在methodi中会调用另外一个 synchronized方法method2，此时线程不必重新去申请锁，而 是可以直接执行方法 method2。 看下面这段代码就明白了： class MyClass { public synchronized void method1() { method2(); } public synchronized void method2() { } } 上述代码中的两个方法 method1 和 method2 都用 synchronized 修饰了，假如某一时刻， 线程 A 执行到了 method1 ，此时