java并发编程实战-第13章-显示锁

java并发编程实战-第13章-显示锁

 Lock interface：

 

 方法摘要 

 void lock() 

          获取锁。 

 void lockInterruptibly() 

          如果当前线程未被中断，则获取锁。 

 Condition () 

          返回绑定到此 Lock 实例的新 Condition 实例。 

 boolean tryLock() 

          仅在调用时锁为空闲状态才获取该锁。 

 boolean tryLock(long time, TimeUnit newConditionunit) 

          如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁。 

 void unlock() 

          释放锁。 

 

 

 Unlike intrinsic locking, Lock offers a choice of unconditional, polled, timed, and interruptible lock acquisition, and all lock and unlock operations are explicit

  无条件的、可轮询的、基于时间的和可中断的 ，并且加锁和解锁都是显示的。

13.1 Lock and ReentrantLock

13.1.1 . Polled and Timed Lock Acquisition

  如果不能获得所需要的所有锁，那么可以使用定时的或者轮询的锁获取方式，从而重新获取控制权，首先释放所有已获得的锁，然后重新尝试获取所有锁。

  

  比如用来解决动动顺序死锁问题。清单13-3 transferMoney

  

  

  

  基于时间的发送消息，如果在时间段里没有获取到锁，则会优雅的失败。

  

  Listing 13.4. Locking with a Time Budget.

public boolean trySendOnSharedLine(String message,

                                   long timeout, TimeUnit unit)

                                   throws InterruptedException {

    long nanosToLock = unit.toNanos(timeout)

                     - estimatedNanosToSend(message);

    if (!lock.tryLock(nanosToLock, NANOSECONDS))

        return false;

    try {

        return sendOnSharedLine(message);

    } finally {

        lock.unlock();

    }

}

 

 

 

 

  

13.1.2 Interruptible Lock Acquisition

 

  interruptible lock acquisition allows locking to be used within cancellable activities

  

  Listing 13.5. Interruptible Lock Acquisition.

 

public boolean sendOnSharedLine(String message)

       throws InterruptedException {

   lock.lockInterruptibly();

   try {

       return cancellableSendOnSharedLine(message);

   } finally {

       lock.unlock();

   }

}

 

private boolean cancellableSendOnSharedLine(String message)

   throws InterruptedException { ... }

 

13.1.3. Non-block-structured Locking

（以下内容再自jdk1.6）

虽然 synchronized 方法和语句的范围机制使得使用监视器锁编程方便了很多，而且还帮助避免了很多涉及到锁的常见编程错误，但有时也需要以更为灵活的方式使用锁。例如，某些遍历并发访问的数据结果的算法要求使用 "hand-over-hand" 或 "chain locking"：获取节点 A 的锁，然后再获取节点 B 的锁，然后释放 A 并获取 C，然后释放 B 并获取 D，依此类推。Lock 接口的实现允许锁在不同的作用范围内获取和释放，并允许以任何顺序获取和释放多个锁，从而支持使用这种技术。 

 

随着灵活性的增加，也带来了更多的责任。不使用块结构锁就失去了使用 synchronized 方法和语句时会出现的锁自动释放功能。在大多数情况下，应该使用以下语句： 

 

     Lock l = ...; 

     l.lock();

     try {

         // access the resource protected by this lock

     } finally {

         l.unlock();

     }

 

 

13.2. Performance Considerations

 

   通过synchronized 和ReentrantLock  在jdk1.5 和1.6 中比较，

   

   在1.5中，synchronized会随着竞争的加剧，而性能减小，但在1.6中情况完全不同。已经和ReentrantLock性能相当

  

  

   所以，性能是个不断变化的指标，昨天的测试今天可能就过时了

   

 

13.3 公平性

 

    ReentrantLock  和 ReentrantReadWriteLock  的默认都是非公平的锁，这样可以提高并发的性能 。公平性将由于存在挂起线程和恢复线程时存在开销而极大的降低性能。

    

   非公平的锁中，如果一个新线程请求资源，并且该资源可用时，可以插队直接获取改资源的锁。而在公平锁中，如果有另外一个线程持有该锁，或者有其他线程在队列中等待这个锁，那么新发出请求的线程会被放入队列中。

13.4 ReentrantLock 和 内置锁的选择

    优先使用内置锁，当内置锁不能提供额为的功能时，再考虑ReentrantLock，这些功能包括：可轮询、定时、可取消 和 提供公平性时 

    

13.5   读写锁

 

     在读多写少的数据结构时，可以提高程序的并发性

      可以包裹 HashMap  ,ArrayList 提供安全的可并发的数据结构

  

 

小结 ：

 

 

显示锁，提供了更好的灵活性，但不能完全替代synchronized,只有在synchronized无法买足需求时，

 

 

Read-write locks： 当访问以以读为主的数据结构时，可以调高程序的可伸缩性。