Lock应用之 线程公平竞争

最新推荐文章于 2025-09-09 09:10:31 发布
最新推荐文章于 2025-09-09 09:10:31 发布
阅读量132 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： java
原文链接：https://yq.aliyun.com/articles/477084
本文探讨了ReentrantLock中的公平锁与非公平锁的区别，通过具体的代码示例对比了不同场景下这两种锁机制的性能表现，并给出了选择建议。

Lock的实现类ReentrantLock的构造函数提供了两种锁获取公平性选择，公平与非公平，默认为非公平，这相比传统的内部锁只使用非公平机制提供了更灵活的选择。


何谓公平与非公平？简单的说就是非公平竞争机制允许插队，而公平竞争机制不允许插队。公平竞争机制下，所有线程都必须排队按顺序来获得锁，即先到先服务。非公平竞争机制下，新线程在请求锁时如果锁刚好释放，可以及时抢占锁，而不让给排在队头的线程，但如果锁已经被占用新线程也只能排队，排在队列中的线程还是先到先服务，所以保证每个线程都会最后得到锁以做到相对公平。


公平竞争机制下，刚开始锁可用：

  1. A请求锁，因为锁可用所以A直接占有锁。

  2. B请求锁，因为锁已经被占用所以B进入等待队列。

  3. C请求锁同时A释放锁，因为B已经在等待队列，所以C直接被放入等待队列，而B被唤醒并获取锁。


非公平竞争机制下，刚开始锁可用：

  1. A请求锁，因为锁可用所以A直接占有锁。

  2. B请求锁，以为锁已经被占用所以B进入等待队列。

  3. C请求锁同时A释放锁，此时虽然有B再等待队列而且会被唤醒，但C会直接参与竞争获取锁，一般情况下C会先获取到锁，而B则继续等待，这对B不公平，但B只能眼睁睁的看见锁被占。但恢复一个被挂起的线程与该线程真正开始运行之间存在着严重的延迟，所以如果C占用锁的时间不长，B被唤醒后C已经释放锁，此时B可以直接占用锁，这造成一种两全其美的局面，C线程见缝插针充分利用锁资源，大大提高系统吞吐量，何乐不为？这也是在竞争激烈的场景下，非公平锁的性能比公平锁好的原因。


那么实际应用中究竟选择公平锁还是非公平锁？据统计（本人的测试结果与统计相左），一般场景下非公平锁的性能好于公平锁，而且除非算法依赖于线程公平排队顺序，正常场景下非公平锁都能使程序正常运行，所以无特殊情况推荐使用非公平锁。哪些情况使用非公平锁：

  1. 算法依赖于公平的排队算法

  2. 线程持有锁的时间比较长

  3. 线程请求锁的平均间隔时间比较长


最后，谈谈自己对内部锁、公平锁、非公平锁的性能测试结果。测试环境为Win7 64bbit + JDK7 + 4GB + i5 4*2.67G，从测试结果看，线程少时（小于1000），性能相差无几，公平锁和内部锁反而微胜非公平锁，这也验证了内部锁的性能已经大大提升的说法；但当线程越多时竞争越激烈就能体现出非公平锁的优势。因为公平锁主要用于特殊场景，所以比较它们的性能意义不大，本测试代码只供参考。


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class TestLockFairness {
    private static final int JOB_NUM = 100;
    private static final int JOB_LOAD_FACTOR = 500;
                                         
    private Lock lock;
    private volatile boolean isUsingLock;
    private CountDownLatch countDownLatch;
                                         
    private void doShortJobWithLock(){
        lock.lock();
        try{
            for(int i=0; i<100; i++){
                ;;
            }
        }finally{
            lock.unlock();
        }
                                             
        for(int i=0; i<10000; i++){
            ;;
        }
    }
                                         
    private void doLongJobWithLock(){
        lock.lock();
        try{
            try {
                TimeUnit.MICROSECONDS.sleep(JOB_LOAD_FACTOR);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }finally{
            lock.unlock();
        }
                                             
        for(int i=0; i<10000; i++){
            ;;
        }
    }
                                         
    private void doShortJob(){
        synchronized(this){
            for(int i=0; i<100; i++){
                ;;
            }
        }
                                                     
        for(int i=0; i<10000; i++){
            ;;
        }
    }
                                         
    private void doLongJob(){    
        synchronized(this){
            try {
                TimeUnit.MICROSECONDS.sleep(JOB_LOAD_FACTOR);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
                                                         
        for(int i=0; i<10000; i++){
            ;;
        }
    }
                                         
    private class ShortJobWorker implements Runnable{    
        @Override
        public void run() {
            for(int i=0; i<JOB_NUM; i++){
                if(isUsingLock){
                    doShortJobWithLock();
                }
                else{
                    doShortJob();
                }
            }
                                                 
            countDownLatch.countDown();
        }    
    }
                                         
    private class LongJobWorker implements Runnable{
        @Override
        public void run() {
            for(int i=0; i<JOB_NUM; i++){
                if(isUsingLock){
                    doLongJobWithLock();
                }
                else{
                    doLongJob();
                }
            }
                                                 
            countDownLatch.countDown();
        }    
    }
    public static void main(String[] args) throws InterruptedException {
        TestLockFairness testLockFairness = new TestLockFairness();
        System.out.println("Type\tThreads\tTime");
        testLockFairness.test("synchronized", false, 10, null);
        testLockFairness.test("unfair Lock", true, 10, new ReentrantLock(false));
        testLockFairness.test("fair Lock  ", true, 10, new ReentrantLock(true));
                                             
        testLockFairness.test("synchronized", false, 100, null);
        testLockFairness.test("unfair Lock", true, 100, new ReentrantLock(false));
        testLockFairness.test("fair Lock  ", true, 100, new ReentrantLock(true));
                                             
        testLockFairness.test("synchronized", false, 500, null);
        testLockFairness.test("unfair Lock", true, 500, new ReentrantLock(false));
        testLockFairness.test("fair Lock  ", true, 500, new ReentrantLock(true));
    }
    private void test(String type, boolean isUsingLock, int threadNum, Lock lock) throws InterruptedException {
        this.isUsingLock = isUsingLock;
        this.lock = lock;
        countDownLatch = new CountDownLatch(2*threadNum);    
                                             
        long beginTime = System.currentTimeMillis();
                                             
        for(int i=0; i<threadNum; i++){
            new Thread(new LongJobWorker()).start();
            new Thread(new ShortJobWorker()).start();
        }
                                             
        countDownLatch.await();
        long endTime = System.currentTimeMillis();
        System.out.println(type + "        \t" + 2*threadNum + "   \t" + (endTime - beginTime));
    }
}


参考：《Java Currency in Practice》





     本文转自sarchitect 51CTO博客，原文链接：http://blog.51cto.com/stevex/1300760，如需转载请自行联系原作者



JAVA多线程之并发与同步，Lock与Syncronized
csdn_aiyang的博客
03-23 2万+
说到线程，就不得不先说线程和进程的关系。进程是系统的执行单位，一般一个应用程序即是一个进程，程序启动时系统默认有一个主线程，即是UI线程，我们知道不能做耗时任务，否则ANR程序无响应。这时需要借助子线程实现，即多线程。由于线程是系统CPU的最小单位，用多线程其实就是为了更好的利用cpu的资源。一、多线程创建方式//线程休眠1000毫秒，sleep使线程进入Block状态，并释放资源xx.start();//启动线程，run函数运行@Override@Override。
多线程编程全攻略：提升性能与线程安全的必备知识
热门推荐
张彦峰的博客
10-14 10万+
介绍多线程编程的相关概念、同步机制以及无锁编程。从线程的基础概念出发，包括逻辑线程和硬件线程的比较，以及线程、核心和函数的关系。随后，我们探讨了多线程编程的基本原则，包括时间分片、上下文切换、线程安全函数和可重入函数等。接着，我们讨论了为什么需要多线程同步、什么情况需要进行同步以及多线程同步的方式，包括串行化、原子操作和锁等。我们还深入研究了非阻塞的无锁同步机制，如CAS循环和无锁数据结构。最后，我们解释了程序序、内存序、乱序执行、存储缓冲区和失效队列等概念，以帮助更好地理解多线程编程。
Java多线程之Lock接口
weixin_34010949的博客
07-03 102
为什么80%的码农都做不了架构师？>>> ...
线程间竞争
weixin_56324038的博客
10-16 605
进程间通信：进程获取的内存空间是一块抽象的内存，然后会映射到实际的某一块物理内存，因此，每个进程都无法访问其他进程在内存里面数据。它是操作系统动态执行的基本单元，在传统的操作系统中，进程既是基本的分配单元，也是基本的执行单元。当一个进程或线程已经占有一个不可被剥夺的资源，并且在请求新资源无法被满足时，则释放已经占用的资源，等待一段时间后重新请求。多个进程或线程之间互相等待对方手中的资源，在得到新的资源之前不会主动释放自己手中的资源，如果形成了等待环路，称之为死锁现象。某进程内的线程在其它进程不可见。
多线程几种常用方法代码
code_mzh的博客
06-27 993
线程只能start一次 1.sleep，休眠 //增加事故发生问题 public class TestSleep implements Runnable{ //票 private int ticketNum=10; @Override public void run() { while(true){ if(ticketNum<=0){ break; }
Java线程锁之Lock的使用
m0_55887994的博客
03-11 1239
有且只有一个线程获取到锁，其余线程全部挂起，直到该拥有锁的线程释放锁，被挂起的线程被唤醒重新开始竞争锁ReentrantLock的内部类Sync 继承了AQS，分为公平锁FairSync和非公平锁NonfairSync。如果一个线程lock.lock()已经获取了锁，也可以多次调用这个方法(重入锁名称的来源)，都可以获取到锁，但是获取多少次锁必须通过lock.unlock。阻塞线程时会自动释放锁，不管调用了多少次lock.lock()，这时阻塞在lock.lock()方法上线程则可以获取锁。
多线程-锁Lock
存在,即合理
12-22 864
Lock.lock()：获取锁，如被锁定则等待。Lock.tryLock(long timeout, TimeUnit unit): 获取 锁，如已被锁定，则最多等待timeout时间后返回获 取锁状态。这是因为 synchronized 加解锁是由 JVM 实现的，在执行完 synchronized 块后会自动解锁，所以会按照 synchronized 的嵌套顺序加解锁，不能自行控制。但在高负载、高并发的情况下，Synchronized 同步锁由于竞争激烈会升级到重量级锁，性能则没有 Lock 锁稳定。
Java多线程之synchronzied锁和Lock锁
qq15035899256的博客
07-10 1281
本文是Java多线程的学习，认识了什么是锁，关键字synchronized和Lock这两种锁的用法，以及两者之间的区别。之后的学习内容将持续更新！！！
Java多线程-避免同步机制带来的死锁问题及用Lock锁解决线程安全问题
02-02
在多线程编程中，死锁是一种常见的问题，指的是两个或多个线程在执行过程中，因为竞争资源而造成的一种相互等待的现象。若线程A持有资源1，等待资源2；线程B持有资源2，等待资源1，则这两个线程就会陷入无限期的阻塞...
Java多线程：死锁防范与Lock锁的应用
1. **线程之间的资源竞争**：当两个或更多线程各自持有部分资源，并且都在等待其他线程持有的资源时，就可能导致死锁。例如，线程A持有锁1并等待锁2，而线程B持有锁2并等待锁1，两者进入无限等待状态。 2. **顺序...
Java 并发编程：使用 Lock 和 Condition 实现线程同步
数字魔方操控师的博客
04-21 826
Lock和Condition接口是 Java 并发编程中非常重要的工具，它们为开发者提供了比synchronized更灵活、更强大的同步机制。通过合理使用Lock和Condition，可以实现复杂的同步控制、高效的线程间通信，从而提升程序的性能和稳定性。在实际开发中，应根据具体的业务场景和需求，选择合适的同步方式。同时，在使用Lock和Condition时，要注意正确地获取和释放锁，避免出现死锁等问题。随着 Java 版本的不断更新，并发编程的工具和技术也在不断发展和完善。
基于SpringBoot和uni-app开发的陪诊陪护软件系统源码
程序员创业中
09-06 1317
中国60岁以上人口已突破3.1亿，独居老人超1.3亿，而一线城市三甲医院日均门诊量超万人次。在这组数据背后，是无数家庭面临的困境：子女异地工作无法陪同父母就医，独居老人因不会操作智能设备在挂号机前徘徊，异地患者因不熟悉流程在医院迷路……当“就医”从个人事务演变为社会难题，陪诊陪护系统正以“专业服务+技术赋能”的双重模式，成为破解这一困局的关键。
二叉树的前中后序遍历(迭代法)
mrjieke6的博客
09-07 1196
本文系统介绍了二叉树前序、中序和后序遍历的迭代实现方法。前序遍历采用栈结构，按;根→右→左 ;顺序入栈；中序遍历先全部左子树入栈再访问节点；后序遍历则通过修改前序遍历顺序为"根→右→左 ;后反转结果。三种遍历时间复杂度均为O(n)，空间复杂度最坏O(n)。与递归实现相比，迭代方法避免了栈溢出风险，处理大型树更稳定。每种遍历方式都配有详细代码解析、执行示例和复杂度分析，并讨论了实际应用场景，为掌握树结构操作提供了系统指导。
从Java全栈开发到微服务架构的实战经验分享
CatchLight的博客
09-09 641
应聘者：我认为最重要的是能够理解业务需求，并将其转化为技术方案。同时，持续学习新技术，保持对行业趋势的关注也很关键。毕竟，技术更新很快，只有不断学习才能跟上节奏。通过这次面试，我们可以看到一位资深Java全栈开发者的专业能力和实践经验。他不仅掌握了多种技术栈，还能在实际业务场景中灵活运用，解决实际问题。同时，他也展现了良好的沟通能力和学习能力，这些都是成为一名优秀工程师的关键素质。
Android8 binder源码学习分析笔记（二）
g_i_a_o_giao的博客
09-05 2441
本文分析了Android框架中Activity启动流程涉及的Binder通信机制。通过跟踪startActivity()调用链，重点解析了客户端进程通过IApplicationThread（Binder对象）与AMS（ActivityManagerService）的跨进程通信过程：1) 客户端通过ActivityManager.getService()获取AMS的Binder代理；2) 调用AMS的startActivity方法时传入本进程的IApplicationThread对象；3) AMS通过该Bin
Java内存区域与内存溢出
DKPT的博客
09-07 580
Java内存溢出的核心在于内存分配与回收失衡，需结合区域特性针对性解决。堆溢出最常见，需重点排查泄漏；方法区溢出多因动态类加载失控；直接内存溢出则需关注NIO使用。通过工具分析+代码优化+参数调优的组合策略，可显著降低OOM风险。二、内存溢出（OOM）类型与触发场景。三、内存溢出诊断与解决策略。一、Java内存区域划分。
【lucene】bitsetiterator
最新发布
risc123456的博客
09-09 213
某些自定义 `FieldCache` 或 `DocValues` 去重逻辑，会先把出现过的 docID 记到 `BitSet`，再用 `BitSetIterator` 一次性吐出。`BitSet` 本身只有 `get()/set()/nextSetBit(int)`，没有标准的迭代器语义，于是就有了 `BitSetIterator` 做适配。- `cost()` 直接返回 `cardinality()`，方便上层 `ConjunctionDISI/DisjunctionDISI` 做排序、选 lead。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值