java 并发——ReentrantLock

简介

public class ReentrantLock implements Lock, java.io.Serializable {

    // 继承了 AbstractQueuedSynchronizer 具体操作的执行者

    private final Sync sync;

    abstract static class Sync extends AbstractQueuedSynchronizer {

        // ...

    }

}

重入锁: 一种可重入互斥锁具有与使用 synchronized 方法和语句访问的隐式监视锁相同的基本行为和语义，但是具有扩展功能。

ReentrantLock 类的构造方法可以接收一个布尔值，当设置为 true 的情况下就是公平锁模式，在竞争的情况下有利于授予等待最长时间的线程。否则 false 是非公平锁该锁不保证任何特定的访问顺序。使用多线程访问的情况下非公平锁比公平锁具有更快的吞吐量。但是请注意，锁的公平性不能保证线程调度的公平性。因此，使用公平锁的许多线程之一可以连续获得多次，而其他活动线程不进行而不是当前持有锁。另请注意，未定义的 tryLock() 方法不符合公平性设置。如果锁可用，即使其他线程正在等待，它也会成功。

建议使用方法是 lock 始终与 try 块成对出现。

方法分析

首先我们先来看看构造器

public ReentrantLock() {

    // 默认使用非公平锁

    sync = new NonfairSync();

}

// 传递 boolean 值来选择锁的类型

public ReentrantLock(boolean fair) {

    sync = fair ? new FairSync() : new NonfairSync();

}

lock 非公平加锁操作

public void lock() {

    sync.lock();

}

final void lock() {

    // 首先进行 cas 操作修改 state 状态

    if (compareAndSetState(0, 1))

        // 如果状态修改成功则设置为当前线程所有

        setExclusiveOwnerThread(Thread.currentThread());

    else

        // 没有修改成功则调用 AQS 的 acquire(int arg) 方法

        acquire(1);

}

上面代码主要做了:

将 state 状态值设置为 1.
如果设置成功则将锁设置为当前线程所有.
如果 state 状态已经被其他线程设置了则会失败则调用 AQS 的 acquire(int arg) 方法.

public final void acquire(int arg) {

    // 调用子类重写的 tryAcquire 方法

    if (!tryAcquire(arg) &&

        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))

        selfInterrupt();

}

上面我们可以看到在 AQS 抽象类中我们发现了提供给子类重写 tryAcquire 的方法，那么我们就去 NonfairSync 类中看下其中实现代码

protected final boolean tryAcquire(int acquires) {

    // 调用父类 Sync.nonfairTryAcquire

    return nonfairTryAcquire(acquires);

}

final boolean nonfairTryAcquire(int acquires) {

    // 获取当前线程

    final Thread current = Thread.currentThread();

    // 获取状态

    int c = getState();

    // 如果发现状态等于 0 说明没有锁处理空闲状态

    if (c == 0) {

        // 再次尝试修改 state 如果获取成功则设置当前线程所有

        if (compareAndSetState(0, acquires)) {

            setExclusiveOwnerThread(current);

            return true;

        }

    }

    // 如果 state 不是 0 并且锁持有者的线程就是当前线程判定为重入

    else if (current == getExclusiveOwnerThread()) {

        // 将 state 的值 + 1

        int nextc = c + acquires;

        if (nextc < 0) // overflow

            throw new Error("Maximum lock count exceeded");

        // 为 state 赋予新值

        setState(nextc);

        return true;

    }

    return false;

}

上面代码主要做了:

首先判断同步状态 state == 0
如果是表示该锁还没有被线程持有，直接通过 cas 获取同步状态，如果成功返回 true
如果 state != 0，则判断当前线程是否为获取锁的线程，如果是则获取锁，成功返回 true

unlock 释放锁操作

public void unlock() {

    // 调用 AQS release

    sync.release(1);

}

public final boolean release(int arg) {

    // 调用子类重写的 Sync.tryRelease

    if (tryRelease(arg)) {

        Node h = head;

        if (h != null && h.waitStatus != 0)

            unparkSuccessor(h);

        return true;

    }

    return false;

}

protected final boolean tryRelease(int releases) {

    // 获取状态减去 releases 如果没有重入则 c = 0

    int c = getState() - releases;

    // 如果锁持有者线程不是该线程则抛出异常

    if (Thread.currentThread() != getExclusiveOwnerThread())

        throw new IllegalMonitorStateException();

    boolean free = false;

    // 如果 c=state==0 表示已经释放

    if (c == 0) {

        free = true;

        // 设置锁持有者线程为 null

        setExclusiveOwnerThread(null);

    }

    // 重新设置 state

    setState(c);

    return free;

}

上面代码可以看到只有同步状态 state == 0 时才算时真正的彻底释放锁，会将锁持有者线程设置为 null 表示释放成功。

lock 公平锁加锁操作

公平锁与非公平锁的区别在于获取锁的时候是否按照FIFO的顺序来。释放锁不存在公平性和非公平性。我们来看加锁操作。

final void lock() {

    // 调用 AQS acquire

    acquire(1);

}

public final void acquire(int arg) {

    // 调用子类公平锁的实现 tryAcquire

    if (!tryAcquire(arg) &&

        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))

        selfInterrupt();

}

protected final boolean tryAcquire(int acquires) {

    final Thread current = Thread.currentThread();

    int c = getState();

    if (c == 0) {

        // 我们发现多了一行 !hasQueuedPredecessors()

        if (!hasQueuedPredecessors() &&

            compareAndSetState(0, acquires)) {

            setExclusiveOwnerThread(current);

            return true;

        }

    }

    else if (current == getExclusiveOwnerThread()) {

        int nextc = c + acquires;

        if (nextc < 0)

            throw new Error("Maximum lock count exceeded");

        setState(nextc);

        return true;

    }

    return false;

}

public final boolean hasQueuedPredecessors() {

    // 尾部节点

    Node t = tail;

    // 头部节点

    Node h = head;

    Node s;

    // 头部节点不等于尾部节点并且(头部节点没有后继节点或者头部节点线程不等于当前线程)

    return h != t &&

        ((s = h.next) == null || s.thread != Thread.currentThread());

}

我们发现公平锁和非公平锁的代码很大一部分都是一模一样的，只是多了一行 !hasQueuedPredecessors() 判断.

hasQueuedPredecessors 主要是判断同步队列中是否还有等待的节点线程，如果有则返回 true 没有返回 false.

总结

ReentrantLock 与 synchronized 比较

ReentrantLock 提供了更多，更加全面的功能，具备更强的扩展性。
ReentrantLock 还提供了条件 Condition，对线程的等待、唤醒操作更加详细和灵活。
ReentrantLock 提供了可轮询的锁请求。它会尝试着去获取锁，如果成功则继续，否则可以等到下次运行时处理，而synchronized 则一旦进入锁请求要么成功要么阻塞，所以相比 synchronized 而言，ReentrantLock 会不容易产生死锁些。
ReentrantLock 支持更加灵活的同步代码块，但是使用 synchronized 时，只能在同一个 synchronized 块结构中获取和释放。
ReentrantLock 支持中断处理，且性能较 synchronized 会好些。

巴特西

java 并发——ReentrantLock

java 并发——ReentrantLock

简介

方法分析

lock 非公平加锁操作

unlock 释放锁操作

lock 公平锁加锁操作

总结

最新文章

热门文章