读写锁ReentrantReadWriteLock原理

最新推荐文章于 2022-10-17 13:24:00 发布
最新推荐文章于 2022-10-17 13:24:00 发布
阅读量553 收藏 1
点赞数 1
分类专栏： Java并发编程 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ZSA222/article/details/123593146
版权

文章目录

1.ReentrantReadWriteLock使用

当读操作远远高于写操作时，这时候使用 读写锁让 读-读可以并行，提高性能。读-写，写-写操作都是相互互斥的！

代码举例
提供一个 数据容器类内部分别使用读锁保护数据的read()方法，写锁保护数据的 write()方法

/**
 * @ClassName TestReadWriteLock
 * @author: shouanzh
 * @Description 读读可以并发、读写、写写互斥
 * @date 2022/3/19 13:27
 */
@Slf4j
public class TestReadWriteLock {

    public static void main(String[] args) throws InterruptedException {

        DataContainer dataContainer = new DataContainer();

        Thread t1 = new Thread(()->{
            // dataContainer.read();
            dataContainer.write();
        },"t1");

        Thread t2 = new Thread(()->{
            // dataContainer.read();
            dataContainer.write();
        },"t2");

        t1.start();
        Thread.sleep(100);
        t2.start();
    }

}

@Slf4j
class DataContainer {

    // 要保护的共享数据
    private Object data;

    private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
    // 读锁
    private final ReentrantReadWriteLock.ReadLock readLock = readWriteLock.readLock();
    // 写锁
    private final ReentrantReadWriteLock.WriteLock writeLock = readWriteLock.writeLock();

    /**
     * 读操作
     * @return Object
     */
    public Object read() {
        log.debug("获取读锁...");
        readLock.lock();
        try {
            log.debug("读取操作");
            Thread.sleep(1000);
            return data;
        } catch (InterruptedException e) {
            e.printStackTrace();
            return null;
        } finally {
            log.debug("释放读锁...");
            readLock.unlock();
        }
    }


    /**
     * 写操作
     */
    public void write() {
        log.debug("获取写锁...");
        writeLock.lock();
        try {
            log.debug("写入操作");
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            log.debug("释放写锁...");
            writeLock.unlock();
        }
    }

}

注意事项

  • 读锁不支持条件变量
  • 重入时升级不支持：即持有读锁的情况下去获取写锁，会导致获取写锁永久等待
	 readLock.lock();
	 try {
	     // ...
	     writeLock.lock();
	     try {
	         // ...
	     } finally{
	         writeLock.unlock();
	     }
	 } finally{
	     readLock.unlock();
	 }
  • 重入时降级支持：即持有写锁的情况下去获取读锁
class CachedData {
    Object data;
    // 是否有效，如果失效，需要重新计算 data
    volatile boolean cacheValid;
    final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    void processCachedData() {
        rwl.readLock().lock();
        if (!cacheValid) {
            // 获取写锁前必须释放读锁
            rwl.readLock().unlock();
            rwl.writeLock().lock();
            try {
                // 判断是否有其它线程已经获取了写锁、更新了缓存, 避免重复更新
                if (!cacheValid) {
                    data = ...
                    cacheValid = true;
                }
                // 降级为读锁, 释放写锁, 这样能够让其它线程读取缓存
                rwl.readLock().lock();
            } finally {

                rwl.writeLock().unlock();
            }
        }
        // 自己用完数据, 释放读锁
        try {
            use(data);
        } finally {
            rwl.readLock().unlock();
        }
    }
}

2.ReentrantReadWriteLock原理

读写锁用的是同一个Sycn同步器，因此等待队列、 state等也是同一个

2.1 图解流程

t1 writeLock.lock()，t2 readLock.lock() ，t1线程加写锁 t2线程加读锁

1） t1成功上锁，流程与 ReentrantLock加锁相比没有特殊之处，不同是写锁状态占了 state的低16位，而读锁使用的是 state的高16位
在这里插入图片描述
2）t2 执行 readLock.lock() ,这时进入读锁的 sync.acquireShared(1)流程,首先会进入 tryAcquireShared流程.如果有写锁占据,那么 tryAcquireShared 返回-1表示失败

tryAcquireShared 返回值表示
-1表示失败
0表示成功，但后继节点不会继续唤醒
正数表示成功，而且数值是还有几个后继节点需要唤醒，读写锁返回1

在这里插入图片描述
3)这时会进入 sync.doAcquireShared(1)流程,首先也是调用addWaiter 添加节点,不同 之处在于节点被设置为Node.SHARED模式而非Node.EXCLUSIVE模式,注意此时t2 仍处于活跃状态

在这里插入图片描述
4) t2会看看自己的节点是不是老二，如果是，还会再次调用tryAcquireShared(1)来尝 试获取锁

5）如果没有成功,在doAcquireShared 内 for(;; )循环一次,把前驱节点的 waitStatus 改 为-1,再 for(;; )循环一次尝试 tryAcquireShared(1)如果还不成功,那么在 parkAndCheckInterrupt() 处 park
在这里插入图片描述
又继续执行：t3 r.lock，t4 w.lock
这种状态下，假设又有t3加读锁和t4加写锁，这期间t1仍然持有锁，就变成了下面的 样子

在这里插入图片描述
继续执行 t1 w.unlock
这时会走到写锁的 sync.release(1)流程，调用sync.tryRelease(1)成功，变成下面的样子
在这里插入图片描述
接下来执行唤醒流程 sync.unparkSuccessor,即让老二恢复运行,这时 t2 在 doAcquireShared 内 parkAndCheckInterrupt() 处恢复运行

这回再来一次for(;; )执行 tryAcquireShared 成功则让读锁计数加一
在这里插入图片描述
这时t2已经恢复运行，接下来t2调用 setHeadAndPropagate(node， 1)，它原本所在节点 被置为头节点

在这里插入图片描述
事情还没完，在 setHeadAndPropagate 方法内还会检查下一个节点是否是 shared， 如果 是则调用 doReleaseShared() 将 head 的状态从-1 改为0并唤醒老二，这时t3 在 doAcquireShared 内 parkAndCheckInterrupt() 处恢复运行
在这里插入图片描述
这回再来一次for(;; )执行 tryAcquireShared 成功则让读锁计数加一
在这里插入图片描述
这时t3已经恢复运行，接下来t3调用 setHeadAndPropagate(node， 1)，它原本所在节点 被置为头节点

在这里插入图片描述
下一个节点不是 shared了，因此不会继续唤醒t4所在节点

再继续执行t2 r.unlock，t3 r.unlock

t2进入 sync.releaseShared(1)中,调用tryReleaseShared(1)让计数减一,但由于计数还不 为零
在这里插入图片描述
t3进入 sync.releaseShared(1)中,调用 tryReleaseShared(1)让计数减一,这回计数为零 了,进入 doReleaseShared()将头节点从-1改为0并唤醒老二,即
在这里插入图片描述
之后t4在 acquireQueued 中 parkAndCheckInterrupt 处恢复运行,再次 for(;; )这次自己是 老二,并且没有其他竞争,tryAcquire(1)成功,修改头结点,流程结束

2.2 源码分析

写锁上锁流程

static final class NonfairSync extends Sync {
    // ... 省略无关代码

    // 外部类 WriteLock 方法, 方便阅读, 放在此处
    public void lock() {
        sync.acquire(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final void acquire(int arg) {
        if (
            // 尝试获得写锁失败
                !tryAcquire(arg) &&
                        // 将当前线程关联到一个 Node 对象上, 模式为独占模式
                        // 进入 AQS 队列阻塞
                        acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
        ) {
            selfInterrupt();
        }
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final boolean tryAcquire(int acquires) {
        // 获得低 16 位, 代表写锁的 state 计数
        Thread current = Thread.currentThread();
        int c = getState();
        int w = exclusiveCount(c);

        if (c != 0) {
            if (
                // c != 0 and w == 0 表示有读锁返回错误，读锁不支持锁升级, 或者
                    w == 0 ||
                            // c != 0 and w == 0 表示有写，如果 exclusiveOwnerThread 不是自己
                            current != getExclusiveOwnerThread()
            ) {
                // 获得锁失败
                return false;
            }
            // 写锁计数超过低 16 位, 报异常
            if (w + exclusiveCount(acquires) > MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
            // 写锁重入, 获得锁成功
            setState(c + acquires);
            return true;
        }
        if (
            // 判断写锁是否该阻塞这里返回false, 或者
                writerShouldBlock() ||
                        // 尝试更改计数失败
                        !compareAndSetState(c, c + acquires)
        ) {
            // 获得锁失败
            return false;
        }
        // 获得锁成功
        setExclusiveOwnerThread(current);
        return true;
    }

    // 非公平锁 writerShouldBlock 总是返回 false, 无需阻塞
    final boolean writerShouldBlock() {
        return false;
    }
}

写锁释放流程：

static final class NonfairSync extends Sync {
    // ... 省略无关代码

    // WriteLock 方法, 方便阅读, 放在此处
    public void unlock() {
        sync.release(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final boolean release(int arg) {
        // 尝试释放写锁成功
        if (tryRelease(arg)) {
            // unpark AQS 中等待的线程
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final boolean tryRelease(int releases) {
        if (!isHeldExclusively())
            throw new IllegalMonitorStateException();
        int nextc = getState() - releases;
        // 因为可重入的原因, 写锁计数为 0, 才算释放成功
        boolean free = exclusiveCount(nextc) == 0;
        if (free) {
            setExclusiveOwnerThread(null);
        }
        setState(nextc);
        return free;
    }
}

读锁上锁流程

static final class NonfairSync extends Sync {

    // ReadLock 方法, 方便阅读, 放在此处
    public void lock() {
        sync.acquireShared(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final void acquireShared(int arg) {
        // tryAcquireShared 返回负数, 表示获取读锁失败
        if (tryAcquireShared(arg) < 0) {
            doAcquireShared(arg);
        }
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final int tryAcquireShared(int unused) {
        Thread current = Thread.currentThread();
        int c = getState();
        // 如果是其它线程持有写锁, 获取读锁失败
        if (
                exclusiveCount(c) != 0 &&
                        getExclusiveOwnerThread() != current
        ) {
            return -1;
        }
        int r = sharedCount(c);
        if (
            // 读锁不该阻塞(如果老二是写锁，读锁该阻塞), 并且
                !readerShouldBlock() &&
                        // 小于读锁计数, 并且
                        r < MAX_COUNT &&
                        // 尝试增加计数成功
                        compareAndSetState(c, c + SHARED_UNIT)
        ) {
            // ... 省略不重要的代码
            return 1;
        }
        return fullTryAcquireShared(current);
    }

    // 非公平锁 readerShouldBlock 看 AQS 队列中第一个节点是否是写锁
    // true 则该阻塞, false 则不阻塞
    final boolean readerShouldBlock() {
        return apparentlyFirstQueuedIsExclusive();
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    // 与 tryAcquireShared 功能类似, 但会不断尝试 for (;;) 获取读锁, 执行过程中无阻塞
    final int fullTryAcquireShared(Thread current) {
        HoldCounter rh = null;
        for (;;) {
            int c = getState();
            if (exclusiveCount(c) != 0) {
                if (getExclusiveOwnerThread() != current)
                    return -1;
            } else if (readerShouldBlock()) {
                // ... 省略不重要的代码
            }
            if (sharedCount(c) == MAX_COUNT)
                throw new Error("Maximum lock count exceeded");
            if (compareAndSetState(c, c + SHARED_UNIT)) {
                // ... 省略不重要的代码
                return 1;
            }
        }
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    private void doAcquireShared(int arg) {
        // 将当前线程关联到一个 Node 对象上, 模式为共享模式
        final Node node = addWaiter(Node.SHARED);
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                if (p == head) {
                    // 再一次尝试获取读锁
                    int r = tryAcquireShared(arg);
                    // 成功
                    if (r >= 0) {
                        // ㈠
						// r 表示可用资源数, 在这里总是 1 允许传播
                        //（唤醒 AQS 中下一个 Share 节点）
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        failed = false;
                        return;
                    }
                }
                if (
                    // 是否在获取读锁失败时阻塞（前一个阶段 waitStatus == Node.SIGNAL）
                        shouldParkAfterFailedAcquire(p, node) &&
                                // park 当前线程
                                parkAndCheckInterrupt()
                ) {
                    interrupted = true;
                }
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

    // ㈠ AQS 继承过来的方法, 方便阅读, 放在此处
    private void setHeadAndPropagate(Node node, int propagate) {
        Node h = head; // Record old head for check below
        // 设置自己为 head
        setHead(node);

        // propagate 表示有共享资源（例如共享读锁或信号量）
        // 原 head waitStatus == Node.SIGNAL 或 Node.PROPAGATE
        // 现在 head waitStatus == Node.SIGNAL 或 Node.PROPAGATE
        if (propagate > 0 || h == null || h.waitStatus < 0 ||
                (h = head) == null || h.waitStatus < 0) {
            Node s = node.next;
            // 如果是最后一个节点或者是等待共享读锁的节点
            if (s == null || s.isShared()) {
                // 进入 ㈡
                doReleaseShared();
            }
        }
    }

    // ㈡ AQS 继承过来的方法, 方便阅读, 放在此处
    private void doReleaseShared() {
        // 如果 head.waitStatus == Node.SIGNAL ==> 0 成功, 下一个节点 unpark
        // 如果 head.waitStatus == 0 ==> Node.PROPAGATE, 为了解决 bug, 见后面分析，参考这里：http://www.tianxiaobo.com/2018/05/01/AbstractQueuedSynchronizer-%E5%8E%9F%E7%90%86%E5%88%86%E6%9E%90-%E7%8B%AC%E5%8D%A0-%E5%85%B1%E4%BA%AB%E6%A8%A1%E5%BC%8F/#5propagate-%E7%8A%B6%E6%80%81%E5%AD%98%E5%9C%A8%E7%9A%84%E6%84%8F%E4%B9%89
        for (;;) {
            Node h = head;
            // 队列还有节点
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue; // loop to recheck cases
                    // 下一个节点 unpark 如果成功获取读锁
                    // 并且下下个节点还是 shared, 继续 doReleaseShared
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                        !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue; // loop on failed CAS
            }
            if (h == head) // loop if head changed
                break;
        }
    }
}

读锁释放流程

static final class NonfairSync extends Sync {

    // ReadLock 方法, 方便阅读, 放在此处
    public void unlock() {
        sync.releaseShared(1);
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    public final boolean releaseShared(int arg) {
        if (tryReleaseShared(arg)) {
            doReleaseShared();
            return true;
        }
        return false;
    }

    // Sync 继承过来的方法, 方便阅读, 放在此处
    protected final boolean tryReleaseShared(int unused) {
        // ... 省略不重要的代码
        for (;;) {
            int c = getState();
            int nextc = c - SHARED_UNIT;
            if (compareAndSetState(c, nextc)) {
                // 读锁的计数不会影响其它获取读锁线程, 但会影响其它获取写锁线程
                // 计数为 0 才是真正释放
                return nextc == 0;
            }
        }
    }

    // AQS 继承过来的方法, 方便阅读, 放在此处
    private void doReleaseShared() {
        // 如果 head.waitStatus == Node.SIGNAL ==> 0 成功, 下一个节点 unpark
        // 如果 head.waitStatus == 0 ==> Node.PROPAGATE
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                // 如果有其它线程也在释放读锁，那么需要将 waitStatus 先改为 0
                // 防止 unparkSuccessor 被多次执行
                if (ws == Node.SIGNAL) {
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue; // loop to recheck cases
                    unparkSuccessor(h);
                }
                // 如果已经是 0 了，改为 -3，用来解决传播性，见后文信号量 bug 分析
                else if (ws == 0 &&
                        !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue; // loop on failed CAS
            }
            if (h == head) // loop if head changed
                break;
        }
    }
}

3.StampedLock

该类自 JDK8加入，是为了进一步优化读性能，它的特点是在使用读锁、写锁时都必须配合【戳】使用

加解读锁

long stamp = lock.readLock();
lock.unlockRead(stamp);

加解写锁

long stamp = lock.writeLock();
lock.unlockWrite(stamp);

乐观读，StampedLock支持tryOptimisticRead()方法(乐观读)，读取完毕后需要做一次戳校验 如果校验 通过，表示这期间确实没有写操作，数据可以安全使用，如果校验没通过，需要重新获取读锁，保证数据安 全。

long stamp = lock.tryOptimisticRead();
// 验戳
if(!lock.validate(stamp)){
 // 锁升级
}

代码演示
提供一个 数据容器类 内部分别使用读锁保护数据的 read() 方法，写锁保护数据的 write() 方法。

/**
 * StampedLock 不支持条件变量
 * StampedLock 不支持可重入
 */
@Slf4j
public class StampedLockTest {

    public static void main(String[] args) throws InterruptedException {
        StampedLockDataContainer dataContainer = new StampedLockDataContainer(1);

        Thread t1 = new Thread(() -> {
            try {
                int read = dataContainer.read(1);
                log.debug("{}",read);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }, "t1");

        t1.start();

        Thread.sleep(500);

        Thread t2 = new Thread(() -> {
//            try {
//                dataContainer.read(0);
//            } catch (InterruptedException e) {
//                e.printStackTrace();
//            }
           dataContainer.write(1000);
        }, "t2");

        t2.start();
    }

}

@Slf4j
class StampedLockDataContainer {

    private int data;

    private final StampedLock stampedLock = new StampedLock();

    public StampedLockDataContainer(int data) {
        this.data = data;
    }

    public int read(int readTime) throws InterruptedException {
        long stamp = stampedLock.tryOptimisticRead();
        log.info("optimistic read locking ...{}", stamp);
        Thread.sleep(readTime * 1000L);

        if (stampedLock.validate(stamp)) {
            log.info("read finish... {}", stamp);
            return data;
        }

        // 锁升级 - 读锁
        log.info("update to read lock ...{}",stamp);
        try {
            stamp = stampedLock.readLock();
            log.info("read lock {}", stamp);
            Thread.sleep(readTime * 1000L);
            log.info("read finish ... {}", stamp);
            return data;
        } finally {
            stampedLock.unlockRead(stamp);
        }
    }

    public void write(int newData) {
        long stamp = stampedLock.writeLock();
        try {
            log.info("write lock {}", stamp);
            this.data = newData;
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            log.info("write finish ... {}", stamp);
            log.info("write newData ... {}", this.data);
        } finally {
            stampedLock.unlockWrite(stamp);
        }
    }

}

运行结果
读读操作

2022-03-19 17:19:33 [t1] - optimistic read locking ...256
2022-03-19 17:19:33 [t2] - optimistic read locking ...256
2022-03-19 17:19:33 [t2] - read finish... 256
2022-03-19 17:19:34 [t1] - read finish... 256
2022-03-19 17:19:34 [t1] - 1

Process finished with exit code 0

读写操作

2022-03-19 17:22:27 [t1] - optimistic read locking ...256
2022-03-19 17:22:28 [t2] - write lock 384
2022-03-19 17:22:28 [t1] - update to read lock ...256
2022-03-19 17:22:29 [t2] - write finish ... 384
2022-03-19 17:22:29 [t2] - write newData ... 1000
2022-03-19 17:22:29 [t1] - read lock 513
2022-03-19 17:22:30 [t1] - read finish ... 513
2022-03-19 17:22:30 [t1] - 1000

Process finished with exit code 0
Zhang_960110
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
8、读写锁ReentrantReadWriteLock&StampLock详解.pdf
02-28
6.JUC并发工具类在大厂的应用场景详解 (1).pdf ...8、读写锁ReentrantReadWriteLock&StampLock详解.pdf 9、并发容器 (Map、List、Set） 实战及其原理.pdf 10、阻塞队列BlockingQueue 实战及其原理分析.pdf
读写锁(read-write lock)机制-----多线程同步问题的解决
zhanggf的博客
01-12 4383
读写锁(read-write lock) 一 综述     在一些程序中存在读者写者问题，也就是说，对某些资源的访问会  存在两种可能的情况，一种是访问必须是排它行的，就是独占的意思，这称作写操作；另一种情况就是访问方式可以是共享的，就是说可以有多个线程同时去访问某个资源，这种就称作读操作。这个问题模型是从对文件的读写操作中引申出来的。     读写锁比起mutex具有更高的适用性，具有更高
线程池的使用步骤
weixin_49578980的博客
09-17 2707
线程池的使用步骤 使用线程池的工厂类Executors里面提供的静态方法newFixedThreadPool生产一个指定线程数量的线程池 创建一个类,实现Runnable接口,重写run方法,设置线程任务 调用ExecutorService中的方法submit,传递线程任务(实现类),开启线程,执行run方法 调用ExecutorService中的方法shutdown销毁线程池(不建议执行) public class ThreadPool{ public static void main(Str
ReentrantReadWriteLock简单理解和使用
qq_41451415的博客
11-28 259
ReentrantReadWriteLock此类不会将读取者优先或写入者优先强加给锁访问的排序。但是，它确实支持可选的公平 策略。 非公平模式（默认） 当非公平地（默认）构造时，未指定进入读写锁的顺序，受到 reentrancy 约束的限制。连续竞争的非公平锁可能无限期地推迟一个或多个 reader 或 writer 线程，但吞吐量通常要高于公平锁。 公平模式 当公平地构造线程时，线程利用一个近似...
5）lock锁（ReentrantLock与ReentrantReadWriteLock）
www.小白
02-17 369
1） Lock显示锁之ReentrantLock 1.1）创建锁常用方法 1.1.1）lock()与unlock() 1.1.2) lockInterruptibly()使用 1.1.3) tryLock()方法使用 1.2) condition 使用 1.3）公平锁与非公平锁 1.3.1）概述 1.3.2）公平锁与非公平锁区别： 1.4）常用的方法 2)ReentrantReadWriteLock读写锁 2.1)概述 2.2）读写锁的基本使用
Java通俗易懂30天 第19天:多线程(下)
程序员小刘
09-16 1154
文章目录 文章目录文章目录第8章 多线程线程的生命周期线程的同步同步代码块处理实现Runnable的线程安全问题同步代码块处理继承Thread类的线程安全问题同步方法处理实现Runnable的线程安全问题同步方法处理继承Thread类的线程安全问题线程安全的单例模式之懒汉式死锁的问题Lock锁方式解决线程安全问题线程的通信sleep()和wait()的异同经典例题：生产者/消费者问题JDK5.0新增线程创建方式创建多线程的方式三：实现Callable接口使用线程池的好处创建多线程的方式四：使用线程池 ..
Java 并发编程原理与实战视频
02-25
第25节读写锁认识与原理00:18:04分钟 | 第26节细读ReentrantReadWriteLock源码00:30:38分钟 | 第27节ReentrantReadWriteLock锁降级详解00:13:32分钟 | 第28节线程安全性问题简单总结00:15:34分钟 | 第29节线程...
龙果 java并发编程原理实战
01-26
第25节读写锁认识与原理00:18:04分钟 | 第26节细读ReentrantReadWriteLock源码00:30:38分钟 | 第27节ReentrantReadWriteLock锁降级详解00:13:32分钟 | 第28节线程安全性问题简单总结00:15:34分钟 | 第29节线程...
Java并发编程原理与实战
08-14
读写锁认识与原理.mp4 细读ReentrantReadWriteLock源码.mp4 ReentrantReadWriteLock锁降级详解.mp4 线程安全性问题简单总结.mp4 线程之间的通信之wait notify.mp4 通过生产者消费者模型理解等待唤醒机制.mp4 ...
并发编程 - Lock、ReentrantLock、ReentrantReadWriteLock、内置锁与显示锁
weixin_42666318的博客
05-01 189
什么是显示锁？ 显示锁，在Java开发中，是由程序可控的，例如lock方法，在调用lock方法之前，可以尝试调用tryLock来判断是否可以拿到锁，如果可以拿到锁，那么进行获取锁时执行的业务否则可以去执行其他不需要锁去执行的业务，在tryLock时可以指定等待超时时间，例如尝试拿锁超时了，可以直接调用lock无限时等待下去或者抛出异常。 什么是内置锁？ 内置锁，是由Java内部来调节锁的获取...
ReentrantReadWriteLock/ReentrantLock 重入锁
yjph83的专栏
04-21 125
转自：http://blog.csdn.net/vking_wang/article/details/9952063 （【Java线程】锁机制：synchronized、Lock、Condition）   一.ReentrantReadWriteLock(读写锁)的使用 Lock比传统线程模型中的synchronized方式更加面向对象，与生活中的锁类似，锁本身也应该是一个对象。两个线程执...
读写锁——ReentrantReadWriteLock原理详解
chuanyingcao2675的博客
07-21 1442
1.读写锁ReentrantReadWriteLock的原理 解决线程安全问题使用ReentrantLock就可以了，但是ReentrantLock是独占锁，某一时刻只有一个线程可以获取该锁，而实际中会有写少读多的场景，显然ReentrantLock满足不了这个需求，所以Reentr...
读写锁ReentrantReadWriteLock详解
CodePanda@GPF的博客
04-10 2944
读写锁、ReentrantReadWriteLock
Java并发包中的读写锁及其实现分析
极北三少
11-02 566
1. 前言 在Java并发包中常用的锁（如：ReentrantLock），基本上都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。 除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁
ReentrantReadWriteLock原理详解
m0_53127809的博客
12-02 3205
当读操作远远高于写操作时,这时候使用读写锁让读——读可以并发,提高性能。 类似于数据库中的select.,from..lockinsharemode 提供一个数据容器类内部分别使用读锁保护数据的read()方法,写锁保护数据的write()方法 简单来说，就是读锁可以共享，但是写锁必须独占 一、ReentrantReadWriteLock JUC为我们提供了一个可用于读和写的读写锁。 简单看下使用方法： ReentrantReadWriteLo...
通俗易懂读写锁ReentrantReadWriteLock的使用
m0_71777195的博客
10-17 5077
ReentrantReadWriteLock不知道大家熟悉吗？其实在实际的项目中用的比较少，反正我所在的项目没有用到过。ReentrantReadWriteLock称为读写锁，它提供一个读锁，支持多个线程共享同一把锁。它也提供了一把写锁，是独占锁，和其他读锁或者写锁互斥，表明只有一个线程能持有锁资源。通过两把锁的协同工作，能够最大化的提高读写的性能，特别是读多写少的场景，而往往大部分的场景都是读多写少的。本文主要讲解ReentrantReadWriteLock的使用和应用场景。
Java多线程（十）之ReentrantReadWriteLock深入分析
爱.NET
12-15 231
一、ReentrantReadWriteLock与ReentrantLock 说到ReentrantReadWriteLock，首先要做的是与ReentrantLock划清界限。它和后者都是单独的实现，彼此之间没有继承或实现的关系。 ReentrantLock 实现了标准的互斥操作，也就是一次只能有一个线程持有锁，也即所谓独占锁的概念。前面的章节中一直在强调这个特点。显然这个特...
2019.11.14学习总结
qq_41641761的博客
11-15 308
Java开发中几种常见的锁 1.公平锁 是指多个线程按照申请锁的顺序来获取资源，类似于队列，先进先出（FIFO）。 2.非公平锁 是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程先获得锁。在高并发的情况下，有可能造成优先级反转或饥饿现象。 源码： public ReentrantLock(boolean fair) { sync = fair ? new F...
ReenTrantLock之读写锁
qq_31142237的博客
03-23 804
ReenTrantLock之读写锁 上几篇我们介绍了多线程同步相关锁Synchronsize锁和JDK的JUC锁Lock以及ReentrantLock锁。现在准备介绍的时JDK的读写锁（测试代码借用别人的博客，我这边只做一个总结）。 先介绍下这个读写锁 ReentrantReadWriteLock 这个读写锁也是JDK工具java.util.concurrent.locks包下，和ReentrantLock 不同的是ReentrantLock是继承了Lock，ReentrantReadWriteLock继承
reentrantreadwritelock原理
最新发布
09-26
它的原理是基于读写锁的概念，读锁和写锁是互斥的，但读锁之间不互斥，因此多个线程可以同时读取共享资源，而写锁和读锁、写锁之间都是互斥的，因此只有一个线程可以写入共享资源。此外，ReentrantReadWriteLock还...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值