公平锁与非公平锁_公平锁和非公平锁区别

大家好，又见面了，我是你们的朋友全栈君。

公平锁和非公平锁

一、如果一个锁是公平的，那么获取的顺序就应该符合请求的绝对顺序，即FIFO。

二、测试结果

非公平性锁可能使线程“饥饿”，为什么它又被设定成默认的实现呢？再次观察上表的结 果，如果把每次不同线程获取到锁定义为1次切换，公平性锁在测试中进行了10次切换，而非 公平性锁只有5次切换，这说明非公平性锁的开销更小。

三、，公平性锁保证了锁的获取按照FIFO原则，而代价是进行大量的线程切换。非公平性锁虽 然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。

读写锁

一、之前提到锁（如Mutex和ReentrantLock）基本都是排他锁，这些锁在同一时刻只允许一个线 程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读 线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写 锁，使得并发性相比一般的排他锁有了很大提升。

在没有读写锁支持的（Java 5之前）时候，如果需要完成上述工作就要使用Java的等待通知 机制，就是当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并 进行通知之后，所有等待的读操作才能继续执行（写操作之间依靠synchronized关键进行同 步），这样做的目的是使读操作能读取到正确的数据，不会出现脏读。改用读写锁实现上述功 能，只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续（非当前写 操作线程）的读写操作都会被阻塞，写锁释放之后，所有操作继续执行，编程方式相对于使用 等待通知机制的实现方式而言，变得简单明了。

二、因为大多数场景读是多于写的。在读多于写 的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是 ReentrantReadWriteLock，

特性：

三、读写锁接口

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/169985.html原文链接：https://javaforall.cn