ReentrantLock 简单使用

摘自:《Java 编程的逻辑》

Java 并发包中的提供了显式锁,它可以解决 synchronized 的一些限制。

Java 并发包中的显式锁接口和类位于包 java.util.concurrent.locks 下,主要接口和类有:

❑ 锁接口 Lock,主要实现类是 ReentrantLock;

❑ 读写锁接口 ReadWriteLock,主要实现类是 ReentrantReadWriteLock。

下面介绍接口 Lock 和实现类 ReentrantLock。

Lock 接口

public interface Lock {
    void lock();
    void lockInterruptibly() throws InterruptedException;
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock();
    Condition newCondition();
}

1)lock()/unlock():就是普通的获取锁和释放锁方法,lock() 会阻塞直到成功。

2)lockInterruptibly():与 lock() 的不同是,它可以响应中断(参见 82219997),如果被其他线程中断了,则抛出 InterruptedException。

3)tryLock():只是尝试获取锁,立即返回,不阻塞,如果获取成功,返回 true,否则返回 false。

4)tryLock(long time, TimeUnit unit):先尝试获取锁,如果能成功则立即返回 true,否则阻塞等待,但等待的最长时间由指定的参数设置,在等待的同时响应中断,如果发生了中断,抛出 InterruptedException,如果在等待的时间内获得了锁,返回 true,否则返回 false。

5)newCondition:新建一个条件,一个 Lock 可以关联多个条件。

可重入锁 ReentrantLock

1.基本用法

Lock 接口的主要实现类是 ReentrantLock,它的基本用法 lock/unlock 实现了与 synchronized 一样的语义,包括:

❑ 可重入,一个线程在持有一个锁的前提下,可以继续获得该锁;

❑ 可以解决竞态条件问题;

❑ 可以保证内存可见性。

ReentrantLock 有两个构造方法:

public ReentrantLock()
public ReentrantLock(boolean fair)

参数 fair 表示是否保证公平,不指定的情况下,默认为 false,表示不保证公平。所谓公平是指,等待时间最长的线程优先获得锁。保证公平会影响性能,一般也不需要,所以默认不保证,synchronized 锁也是不保证公平的。

使用显式锁,一定要记得调用 unlock。一般而言,应该将 lock 之后的代码包装到 try 语句内,在 finally 语句内释放锁。比如,使用 ReentrantLock 实现 Counter,代码可以为:

public class Counter {
    private final Lock lock = new ReentrantLock();
    private volatile int count;
    public void incr() {
        lock.lock();
        try {
            count++;
        } finally {
            lock.unlock();
        }
    }
    public int getCount() {
        return count;
    }
}

2.使用 tryLock 避免死锁

使用 tryLock(),可以避免死锁。在持有一个锁获取另一个锁而获取不到的时候,可以释放已持有的锁,给其他线程获取锁的机会,然后重试获取所有锁。

我们来看个例子,银行账户之间转账,用类 Account 表示账户。

代码清单 1 表示账户的类 Account

public class Account {
    private Lock lock = new ReentrantLock();
    private volatile double money;
    public Account(double initialMoney) {
        this.money = initialMoney;
    }
    public void add(double money) {
        lock.lock();
        try {
            this.money += money;
        } finally {
            lock.unlock();
        }
    }
    public void reduce(double money) {
        lock.lock();
        try {
            this.money -= money;
        } finally {
            lock.unlock();
        }
    }
    public double getMoney() {
        return money;
    }
    void lock() {
        lock.lock();
    }
    void unlock() {
        lock.unlock();
    }
    boolean tryLock() {
        return lock.tryLock();
    }
}

Account 里的 money 表示当前余额,add/reduce 用于修改余额。在账户之间转账,需要两个账户都锁定,如果不使用 tryLock,而直接使用 lock,则代码如代码清单 2 所示。

代码清单 2 转账的错误写法

public class AccountMgr {
    public static class NoEnoughMoneyException extends Exception {}
    public static void transfer(Account from, Account to, double money)
            throws NoEnoughMoneyException {
        from.lock();
        try {
            to.lock();
            try {
                if(from.getMoney() >= money) {
                    from.reduce(money);
                    to.add(money);
                } else {
                    throw new NoEnoughMoneyException();
                }
            } finally {
                to.unlock();
            }
        } finally {
            from.unlock();
        }
    }
}

但这么写是有问题的,如果两个账户都同时给对方转账,都先获取了第一个锁,则会发生死锁。我们写段代码来模拟这个过程,如代码清单 3 所示。

代码清单 3 模拟账户转账的死锁过程

public static void simulateDeadLock() {
    final int accountNum = 10;
    final Account[] accounts = new Account[accountNum];
    final Random rnd = new Random();
    for(int i = 0; i < accountNum; i++) {
        accounts[i] = new Account(rnd.nextInt(10000));
    }
    int threadNum = 100;
    Thread[] threads = new Thread[threadNum];
    for(int i = 0; i < threadNum; i++) {
        threads[i] = new Thread() {
            public void run() {
                int loopNum = 100;
                for(int k = 0; k < loopNum; k++) {
                    int i = rnd.nextInt(accountNum);
                    int j = rnd.nextInt(accountNum);
                    int money = rnd.nextInt(10);
                    if(i ! = j) {
                        try {
                              transfer(accounts[i], accounts[j], money);
                        } catch (NoEnoughMoneyException e) {
                        }
                    }
                }
            }
        };
        threads[i].start();
    }
}

以上代码创建了 10 个账户,100 个线程,每个线程执行 100 次循环,在每次循环中,随机挑选两个账户进行转账。

我们使用 tryLock 来进行修改,先定义一个 tryTransfer 方法,如代码清单 4 所示。

代码清单 4 使用 tryLock 尝试转账

public static boolean tryTransfer(Account from, Account to, double money)
              throws NoEnoughMoneyException {
    if(from.tryLock()) {
        try {
            if(to.tryLock()) {
                try {
                    if(from.getMoney() >= money) {
                        from.reduce(money);
                        to.add(money);
                    } else {
                        throw new NoEnoughMoneyException();
                    }
                    return true;
                } finally {
                    to.unlock();
                }
            }
        } finally {
            from.unlock();
        }
    }
    return false;
}

如果两个锁都能够获得,且转账成功,则返回 true,否则返回 false。不管怎样,结束都会释放所有锁。transfer 方法可以循环调用该方法以避免死锁,代码可以为:

public static void transfer(Account from, Account to, double money)
        throws NoEnoughMoneyException {
    boolean success = false;
    do {
        success = tryTransfer(from, to, money);
        if(!success) {
            Thread.yield();
        }
    } while (!success);
}

除了实现 Lock 接口中的方法,ReentrantLock 还有一些其他方法,通过它们,可以获取关于锁的一些信息,这些信息可以用于监控和调试目的,具体可参看 API 文档,就不介绍了。

对比 ReentrantLock 和 synchronized

相比 synchronized, ReentrantLock 可以实现与 synchronized 相同的语义,而且支持以非阻塞方式获取锁,可以响应中断,可以限时,更为灵活。不过,synchronized 的使用更为简单,写的代码更少,也更不容易出错。

synchronized 代表一种声明式编程思维,程序员更多的是表达一种同步声明,由 Java 系统负责具体实现,程序员不知道其实现细节;显式锁代表一种命令式编程思维,程序员实现所有细节。

声明式编程的好处除了简单,还在于性能,在较新版本的 JVM 上,ReentrantLock 和 synchronized 的性能是接近的,但 Java 编译器和虚拟机可以不断优化 synchronized 的实现,比如自动分析 synchronized 的使用,对于没有锁竞争的场景,自动省略对锁获取/释放的调用。

简单总结下,能用 synchronized 就用 synchronized,不满足要求时再考虑 ReentrantLock。

posted @ 2024-07-13 18:53  Higurashi-kagome  阅读(3)  评论(0编辑  收藏  举报