【Java并发】显式锁

Lock与ReentrantLock

ReentrantLock实现了Lock接口，并提供了与synchronized相同的互斥性和内存可见性，在获取ReentrantLock时，有着与同步代码块相同的内存语义，在释放ReentrantLock时，有着与退出同步代码块相同的内存语义。此外，与synchronized一样，ReentrantLock提供了可重入的加锁语义。
两者比较：
1 显式锁提供定时的锁等待、可中断的锁等待、公平性，以及非块结构的加锁。性能提升；
2 内置锁更简洁，使用风险更低，显式锁需要显式的调用方法释放锁。
3 未来性能可能持续提升的是内置锁，因为内置锁是JVM的内置属性，它能执行一些优化。
4 Lock无法像内置锁那样自动释放，需要显式释放锁，增加了开发应用的风险。

public interface Lock
{
    //获取锁
    void lock();
    //如果当前线程未被中断，则获取锁
    void lockInterruptibly() throws 
InterruptedException;
    //如果锁可用，则获取锁，并立即返回值 true。如果锁不可用，则此方法将立即返回值 false。
    boolean tryLock();
    //如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁
    boolean tryLock(long timeout, TimeUnit unit)
        throws InterruptedException;
    //释放锁
    void unlock();
    //返回绑定到此Lock实例的新Condition实例
    Condition newCondition();  
}

示例一：使用ReentantLock保护对象状态的典型用法：

Lock lock = new ReentrantLock();
...
lock.lock();
try
{
    //更新对象状态
    //捕获异常，并在必要时恢复不变性条件
}
finally
{
    //必须在finally中显式的释放锁
    lock.unlock();
}

示例二：通过tryLock来避免顺序死锁：

private void transfer(Account fromAccount, Account toAccount, int transferAmount, long deadTime)
            {
                long starttime = System.currentTimeMillis();
                while(true)
                {
                    //尝试获取锁，如果失败，则循环尝试，直到获取锁或者超时
                    if(fromAccount.getLock().tryLock()) 
                    {
                        try
                        {
                            if(toAccount.getLock().tryLock())   
                            {
                                try
                                {
                                    fromAccount.withDraw(transferAmount);
                                    toAccount.deposit(transferAmount);
                                    count++;
                                    //System.out.println("run count = " + count);
                                }
                                finally
                                {
                                    fromAccount.getLock().unlock();
                                }
                            }
                        }
                        finally
                        {
                            fromAccount.getLock().unlock();
                        }
                    }
                    try 
                    {
                        Thread.sleep(1000);
                    }
                    catch (InterruptedException e) 
                    {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    };
                    if((System.currentTimeMillis() - starttime) < deadTime)
                    {
                        return;
                    }
                }
            }

定时锁与轮询锁的锁获取模式是由tryLock实现的。与内置锁相比，使用tryLock如果不能获取需要的锁，可以使用可定时的或可轮询的锁获取方式，从而重新获得控制权，它会释放已经获得的锁，然后重新尝试获取所有锁(或者至少会记录失败日志，或采取其他措施)。
示例三：可中断的锁获取方式lockInterruptibly：

//todo

lockInterruptibly方法能够在获得锁的同时保持对中断的响应。
仅当内置锁不能满足要求时，才应该考虑使用ReentrantLock的一些高级功能，包括：可定时的、可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁。否则，还是应该优先使用synchronized。

公平锁

ReentrantLock构造函数提供了两种公平性选择：非公平锁(默认)或者公平锁。
公平锁：线程将按照它们发出请求的顺序来获得锁；
非公平锁：允许“插队”，如果在发出请求的同时，该锁的状态变为可用，那么这个线程将跳过队列中所有的等待线程并获得这个锁。只有当锁被某个线程持有时，新发出请求的线程才会被放入队列；

大多数情况下，非公平锁的性能高于公平锁：
1 公平锁由于在挂起线程和恢复线程时的开销而极大的降低性能；
2 恢复一个挂起的线程与该线程真正开始运行之间存在严重的延迟；
当持有锁的时间相对较长，或者请求锁的平均时间间隔较长，那么应该使用公平锁。

读写锁

ReentrantLock的互斥规则过于强硬。可通过读写锁进行优化。
一个资源可以被多个读操作访问，或者被一个写操作访问，但两者不能同时进行。
接口：ReadWriteLock
实现类：ReentrantReadWriteLock

public interface ReadWriteLock
{
    Lock readLock();
    Lock writeLock();
}