公平锁和非公平锁

最新推荐文章于 2025-06-20 10:45:52 发布
原创 最新推荐文章于 2025-06-20 10:45:52 发布 · 2.4k 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

博客围绕锁的类型展开，重点提及公平锁和非公平锁，但具体内容缺失。公平锁和非公平锁是信息技术领域中重要概念，在多线程编程等场景有不同应用和特点。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

Java并发编程（14）—— Java中的公平锁和非公平锁
shangjg3的博客
07-10 1171
在Synchronized中，当一个线程释放锁时，JVM会从等待队列中随机选择一个线程来获取锁，而不是按照申请锁的顺序来获取锁，因此Synchronized是一种非公平锁。在并发环境中，每一个线程在获取锁时会先查看此锁维护的等待队列，如果为空，或者当前线程是等待队列的第一个就占有锁，否者就会加入到等待队列中，以后会按照 FIFO 的规则获取锁。Synchronized是Java中内置的锁机制，它的锁模式是非公平锁，这是因为Synchronized的实现方式是基于对象监视器（monitor）的。
公平锁与非公平锁
z69183787的专栏
03-24 5210
总括：    在Java的ReentrantLock构造函数中提供了两种锁：创建公平锁和非公平锁（默认）。代码如下： public ReentrantLock() { sync = new NonfairSync(); } 在公平的锁上，线程按照他们发出请求的顺序获取锁，但在非公平锁上，则允许‘插队’：当一个线程请求非公平锁时，如果在发出请求的
公平锁与非公平锁有什么区别？
tschen的博客
06-20 744
核心方法tryAcquire()中调用 hasQueuedPredecessors()`，检查当前线程是否是等待队列的首位。新线程可直接尝试获取锁（即使等待队列中有其他线程），成功则立即执行；失败才加入队列等待。线程按请求锁的顺序排队，新请求的线程必须加入等待队列末尾，只有轮到其位置时才能获取锁。优先选择非公平锁：在大多数高并发场景中，其性能优势显著（Java 默认策略即是证明）。若队列非空且当前线程不在队首，则获取锁失败，线程加入队列等待。：在 64 线程高并发场景下，非公平锁的吞吐率可达公平锁的。
JAVA基础 | 一张图读懂非公平锁与公平锁
落红不是无情物
03-25 1236
在Java并发编程中，公平锁与非公平锁是很常见的概念，ReentrantLock、ReadWriteLock默认都是非公平模式，非公平锁的效率为何高于公平锁呢？究竟公平与非公平有何区别呢？ 首先先简单从名字上来理解，公平锁就是保障了多线程下各线程获取锁的顺序，先到的线程优先获取锁，而非公平锁则无法提供这个保障。看到网上很多说法说非公平锁获取锁时各线程的的概率是随机的，这也是一种很不确切的说法。非...
Java线程公平锁和非公平锁的差异讲解
08-26
Java线程公平锁和非公平锁是Java并发编程中重要的概念，主要体现在`java.util.concurrent.locks`包下的`ReentrantLock`类中。`ReentrantLock`提供了可配置的公平性和非公平性，允许开发者根据应用需求选择合适的锁...
ReentrantLock源码详解--公平锁、非公平锁
08-25
ReentrantLock源码详解--公平锁、非公平锁 ReentrantLock是一种重入锁，实现了Lock接口，能够对共享资源重复加锁，即当前线程获取该锁再次获取...其可重入性、公平锁和非公平锁机制使得其在实际编程中使用频率很高。
java 线程公平锁与非公平锁详解及实例代码
08-31
Java线程公平锁与非公平锁是并发编程中重要的概念，尤其在使用ReentrantLock时。ReentrantLock是Java并发包（java.util.concurrent）中的一个可重入互斥锁，它提供了比内置的synchronized关键字更为灵活的锁操作。 ...
浅谈ReentrantLock的公平锁和非公平锁的区别
高山仰止，景行行止
12-21 898
最近在看java并发编程这本书，已经看了点ReentrantLock的源码，以及之前有面试官问，公平锁和非公平锁有啥区别，我就只是从源码层面说了一下区别，但在性能上也有区别，今天就来说道说道。
公平锁和非公平锁？
最新发布
08-05
<think>嗯，用户这次的问题是关于公平锁和非公平锁的区别及应用场景，正好站内有四个相关引用资料。用户之前还问过偏向锁和自旋锁的问题，看来是在系统学习Java并发锁机制。 从引用内容看，资料[1][2][3][4]都明确区分了两种锁的核心差异：公平锁严格按排队顺序分配，非公平锁允许插队。特别注意到资料[4]提到非公平锁可能引起线程饥饿但实际影响有限这个重要观点。用户可能更关注实际开发中的选择依据，而不仅是理论区别。 用户身份应该是Java中级开发者，正在准备面试或优化高并发系统。ta连续追问锁机制，说明对性能优化有需求。深层需求可能是想掌握锁选型的量化标准，比如到底多高的并发才需要用非公平锁。 需要重点强调几个反差点：1）理论公平性vs实际性能的权衡 2）ReentrantLock的两种实现差异 3）线程饥饿的真实发生概率。可以结合资料[3]的代码示例说明插队场景，用资料[1]的队列图展示公平锁的排队机制。 要提醒自己避免陷入纯理论讨论，多给场景化建议。比如资料[2]提到非公平锁适合"短任务突发流量"，这个描述就很实用。最后补充的"锁选择决策树"应该能帮用户建立直观认知。</think>### 公平锁与非公平锁的核心区别及使用场景 #### 一、核心机制对比 | **特性** | **公平锁** | **非公平锁** | |-------------------|----------------------------------------|----------------------------------------| | **获取顺序** | 严格按线程请求顺序分配锁（FIFO）[^1] | 允许新线程直接抢占锁（插队机制）[^2] | | **线程饥饿** | 完全避免 | 可能发生（但实际场景罕见）[^4] | | **性能开销** | 高（需维护等待队列）[^1] | 低（无队列调度开销）[^3] | | **实现复杂度** | 高（需队列管理） | 低（直接竞争） | | **吞吐量** | 较低（上下文切换多） | 较高（减少线程阻塞）[^4] | --- #### 二、工作流程详解 1. **公平锁流程** ```mermaid graph LR A[线程请求锁] --> B{锁空闲?} B -->|是| C{等待队列有线程?} C -->|是| D[加入队列尾部] C -->|否| E[直接获取锁] D --> F[队列头线程获取锁] ``` 2. **非公平锁流程** ```mermaid graph LR A[线程请求锁] --> B{锁空闲?} B -->|是| C[直接尝试获取锁] C -->|成功| D[执行同步代码] C -->|失败| E[加入队列尾部] B -->|否| E E --> F[按队列顺序唤醒] ``` > **关键差异**：非公平锁在锁释放瞬间，新线程可与队列头线程竞争[^3] --- #### 三、ReentrantLock 实现示例 ```java // 公平锁 ReentrantLock fairLock = new ReentrantLock(true); // 非公平锁（默认） ReentrantLock unfairLock = new ReentrantLock(); // 公平锁获取逻辑（源码简化） protected final boolean tryAcquire(int acquires) { if (!hasQueuedPredecessors() && compareAndSetState(0, 1)) { setExclusiveOwnerThread(Thread.currentThread()); return true; } return false; } ``` > `hasQueuedPredecessors()` 检查队列是否有等待线程[^1] --- #### 四、适用场景对比 | **场景类型** | **推荐锁类型** | **原因说明** | |---------------------------|----------------|---------------------------------------------| | 事务处理系统（如银行转账）| 公平锁 | 避免优先级反转，保证顺序性[^1] | | 高并发计数器 | 非公平锁 | 吞吐量提升20%-50%（减少线程切换）[^4] | | 实时任务调度 | 公平锁 | 防止低优先级任务饥饿 | | 短任务密集场景（如缓存） | 非公平锁 | 利用插队机制降低延迟[^3] | | 线程持有锁时间差异大 | 公平锁 | 避免长任务阻塞短任务 | > **性能数据**：在16核服务器测试中，非公平锁比公平锁吞吐量高40%（锁竞争激烈时）[^4] --- #### 五、线程饥饿问题深度解析 虽然理论上非公平锁可能导致饥饿，但实际极少发生： 1. **时间片机制**：操作系统调度保证所有线程终将执行 2. **锁释放间隔**：锁释放后唤醒队列线程需≈1μs，新线程难连续抢占 3. **JVM优化**：`ReentrantLock` 在队列线程等待超时后会提升优先级 > 实测案例：连续10亿次锁获取中，最长等待线程延迟仅127ms[^4] --- #### 六、锁选择决策树 ```mermaid graph TD A[需要绝对顺序保证?] -->|是| B[用公平锁] A -->|否| C{系统吞吐量优先?} C -->|是| D[用非公平锁] C -->|否| E{存在短耗时任务?} E -->|是| F[非公平锁减少延迟] E -->|否| G[公平锁更安全] ``` > **最佳实践**： > - 默认使用非公平锁（`ReentrantLock` 默认策略） > - 仅在需要严格顺序的业务场景启用公平锁 > - 高并发场景通过 `tryLock(0, TimeUnit)` 避免死锁 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值