百度搜索网站在第一次输入搜索内容后点搜索键没有反应家庭局域网设计方案

百度搜索网站在第一次输入搜索内容后点搜索键没有反应,家庭局域网设计方案,集团网站策划,淘宝网站建设合同#x1f4d6;目录前言1. 为什么需要 ReentrantLock#xff1f;它解决了什么痛点#xff1f;2. 可重入#xff1a;同一个线程的“免检通行证”3. 源码关键#xff1a;AQS 与 CLH 队列4. 公平锁 vs 非公平锁5. 除了 ReentrantLock#xff0c;还有哪些可重入锁#xff1f;6…目录前言1. 为什么需要 ReentrantLock它解决了什么痛点2. 可重入同一个线程的“免检通行证”3. 源码关键AQS 与 CLH 队列4. 公平锁 vs 非公平锁5. 除了 ReentrantLock还有哪些可重入锁6. 谁在用 ReentrantLock—— JDK 内部的应用7. 从 JDK 2 到 JDK 21ReentrantLock 的演进8. 下一篇预告9. 经典书籍推荐10. 前文参考前言在并发编程的世界里synchronized是我们的老朋友它像一把坚固但略显笨重的门锁简单可靠。然而随着应用复杂度的提升这把“内置锁”开始显得力不从心。我们需要一把更智能、更灵活、功能更强大的“瑞士军刀”——这就是java.util.concurrent.locks.ReentrantLock可重入锁被设计出来的根本目的。1. 为什么需要 ReentrantLock它解决了什么痛点想象一下你在一家大型超市购物。收银台就是共享资源比如一个银行账户顾客就是线程。synchronized的局限无法中断如果你排在长队里线程阻塞突然想起家里煤气没关想放弃结账中断线程对不起做不到你只能乖乖等到前面所有人结完账。无法超时如果前面的人在和收银员激烈争论死锁你可能要等上几个小时。synchronized没有“等5分钟就走人”的选项。单一条件synchronized只有一个“等待区”。但在复杂的业务逻辑中我们可能需要多个等待条件。比如在生产者-消费者模型中生产者要等“缓冲区不满”消费者要等“缓冲区不空”。用synchronized实现起来非常别扭。ReentrantLock 的诞生就是为了提供synchronized所不具备的高级功能响应中断(lockInterruptibly)排队时可以随时“拔腿就走”。超时获取(tryLock(timeout))设定一个最大等待时间超时自动放弃。公平/非公平选择可以选择“先到先得”公平锁也可以允许“插队”以提高吞吐量非公平锁默认。多条件变量(newCondition())可以创建多个“VIP等待室”每个等待室对应不同的唤醒条件。这些特性让ReentrantLock成为构建高性能、高可靠并发应用的基石。2. 可重入同一个线程的“免检通行证”“可重入”是ReentrantLock的核心特性之一。大白话解释如果一个线程已经持有了这把锁那么它再次请求这把锁时不会被自己挡住而是可以直接进入。这就像你在家拿着自家大门的钥匙。你从客厅去厨房第一次获取锁再从厨房去卧室第二次获取锁不需要每次都把钥匙拔出来再插进去。系统知道“哦是你啊随便进”。技术实现ReentrantLock内部通过两个关键变量实现可重入private volatile int state记录锁被持有的次数。0表示未被持有0表示已被持有数值即为重入次数。private transient Thread exclusiveOwnerThread记录当前持有锁的线程。当一个线程尝试获取锁时如果发现state 0且exclusiveOwnerThread就是自己那么它只需将state加1即可无需排队。释放锁时则将state减1直到减为0才真正释放锁并唤醒其他线程。3. 源码关键AQS 与 CLH 队列ReentrantLock的强大并非凭空而来其背后是 Java 并发包的灵魂——AbstractQueuedSynchronizer(AQS)。你可以把 AQS 想象成一个极其高效的“排队管理系统”。当多个线程争抢一把ReentrantLock失败时AQS 会将它们组织成一个CLH (Craig, Landin, and Hagersten) 队列。这是一个虚拟的双向链表每个节点代表一个等待中的线程。核心流程抢占线程首先尝试通过 CAS (Compare-And-Swap) 原子操作直接修改state为1抢到锁就走。入队如果抢不到就把自己包装成一个Node节点追加到 CLH 队列的尾部。挂起入队后线程会检查前驱节点的状态。如果前驱是有效的等待节点当前线程就会调用LockSupport.park()进入“睡眠”状态不再消耗 CPU。唤醒当持有锁的线程执行unlock()时它会将state减1。如果state变为0说明锁已完全释放此时它会唤醒 CLH 队列中的头节点的下一个节点即队首等待者。重试被唤醒的线程从park()中返回再次尝试获取锁此时有很大概率成功成功后将自己设为新的头节点。类图关系has-a«interface»Locklock()unlock()tryLock()newCondition()ReentrantLock-Sync synclock()unlock()«abstract»AbstractQueuedSynchronizer-volatile int state-Node head-Node tailacquire(int)release(int)«abstract»Sync-NonfairSync nonfairSync-FairSync fairSyncNonfairSynclock()FairSynclock()4. 公平锁 vs 非公平锁这是ReentrantLock提供的一个重要选择。非公平锁 (NonfairSync, 默认)行为新来的线程会无视CLH队列直接尝试抢占锁。优点吞吐量更高因为减少了线程上下文切换的开销。缺点可能导致队列中的线程“饿死”长时间得不到锁。生活比喻就像食堂打饭新来的人看到窗口空了不管后面有没有排队的人直接冲上去打饭。公平锁 (FairSync)行为新来的线程会先检查 CLH 队列。如果队列不为空它会乖乖排到队尾保证“先来后到”。优点保证了线程调度的公平性避免饿死。缺点吞吐量较低因为每次都要检查队列。生活比喻严格的排队制度后来者必须站到最后。如何选择除非你的业务对公平性有硬性要求如金融交易系统否则强烈建议使用默认的非公平锁以获得最佳性能。5. 除了 ReentrantLock还有哪些可重入锁在 Java 的世界里可重入是一个非常普遍且重要的特性。synchronized关键字这是最经典的可重入锁。它的实现基于 JVM 的 Monitor 对象原理与ReentrantLock类似只是由 JVM 底层管理。ReentrantReadWriteLock读写锁其内部的ReadLock和WriteLock都是可重入的。允许多个读线程同时访问但写线程独占。StampedLock(JDK 8)一种更高级的读写锁提供了乐观读模式性能在某些场景下优于ReentrantReadWriteLock。它的写锁也是可重入的。6. 谁在用 ReentrantLock—— JDK 内部的应用ReentrantLock是java.util.concurrent(JUC) 包的基石许多我们常用的线程安全数据结构都依赖于它数据结构使用的锁类型ArrayBlockingQueueReentrantLockLinkedBlockingQueueReentrantLock(takeLock putLock)DelayQueueReentrantLockPriorityBlockingQueueReentrantLockConcurrentHashMap(JDK 7)ReentrantLock(分段锁)ThreadPoolExecutorReentrantLock(用于管理 worker 线程)可以看到几乎所有需要精细控制同步逻辑的 JUC 组件背后都有ReentrantLock的身影。7. 从 JDK 2 到 JDK 21ReentrantLock 的演进JDK 1.5 (JSR-166)ReentrantLock首次被引入 Doug Lea 的java.util.concurrent包彻底改变了 Java 并发编程的格局。JDK 6对锁的性能进行了大量优化包括偏向锁、轻量级锁等但这些主要针对synchronized。ReentrantLock的 AQS 框架也日趋成熟。JDK 9ReentrantLock的实现细节持续优化但 API 保持稳定。社区的关注点逐渐转向更高级的并发工具如CompletableFuture、VarHandle等。JDK 21 (Loom 项目预览)虽然 Loom 引入了虚拟线程Virtual Threads极大地简化了并发编程但ReentrantLock在平台线程Platform Threads和需要精确控制的场景中依然是不可替代的。值得注意的是虚拟线程与synchronized锁兼容但与ReentrantLock不兼容因为后者会阻塞底层平台线程。示例代码基本用法与中断响应下面是一个完整的例子展示了ReentrantLock的基本用法、可重入性以及响应中断的能力。// 【插入】完整类代码ReentrantLockDemo.javaimportjava.util.concurrent.locks.ReentrantLock;importjava.util.concurrent.TimeUnit;publicclassReentrantLockDemo{privatestaticfinalReentrantLocklocknewReentrantLock();// 展示可重入性publicstaticvoidreentrantMethod(){lock.lock();try{System.out.println(Thread.currentThread().getName() entered reentrantMethod);// 同一线程再次获取锁innerMethod();}finally{lock.unlock();}}privatestaticvoidinnerMethod(){lock.lock();try{System.out.println(Thread.currentThread().getName() entered innerMethod);}finally{lock.unlock();}}// 展示中断响应publicstaticvoidinterruptibleMethod()throwsInterruptedException{// 使用 lockInterruptibly 可以响应中断lock.lockInterruptibly();try{System.out.println(Thread.currentThread().getName() acquired lock in interruptibleMethod);// 模拟长时间持有锁TimeUnit.SECONDS.sleep(10);}finally{lock.unlock();System.out.println(Thread.currentThread().getName() released lock);}}publicstaticvoidmain(String[]args)throwsInterruptedException{// 测试可重入Threadt1newThread(ReentrantLockDemo::reentrantMethod,Thread-Reentrant);t1.start();t1.join();System.out.println(----- Separation Line -----);// 测试中断Threadt2newThread(()-{try{interruptibleMethod();}catch(InterruptedExceptione){System.out.println(Thread.currentThread().getName() was interrupted!);// 中断后线程会退出不会持有锁return;}},Thread-Interruptible);t2.start();// 主线程等待1秒后中断t2TimeUnit.SECONDS.sleep(1);t2.interrupt();t2.join();}}执行结果Thread-Reentrant entered reentrantMethod Thread-Reentrant entered innerMethod ----- Separation Line ----- Thread-Interruptible acquired lock in interruptibleMethod Thread-Interruptible released lock Thread-Interruptible was interrupted!8. 下一篇预告【Java线程安全实战】⑤ 原子类Atomic深度解析无锁编程Lock-Free的终极奥义9. 经典书籍推荐《Java并发编程实战》(Java Concurrency in Practice)作者: Brian Goetz 等这本书被誉为 Java 并发领域的“圣经”。它不仅详细讲解了ReentrantLock、AQS 等核心组件更重要的是传授了一套完整的并发设计思想和最佳实践。尽管出版较早但其核心原理至今仍是金科玉律是每一位 Java 工程师的必读书目。《Java并发编程的艺术》作者: 方腾飞, 魏鹏, 程晓明这是一本国人撰写的优秀著作对ReentrantLock、AQS、ConcurrentHashMap等 JUC 组件的源码剖析极为深入非常适合希望从源码层面理解 Java 并发机制的读者。参考链接ReentrantLock——可重入锁的实现原理 - 内在的天空 - CSDN博客Java中的公平锁和非公平锁实现详解ReentrantLock实现原理-盗帅_tim-博客园10. 前文参考【Java线程安全实战】① 从ArrayList并发翻车说起2025年主流线程安全集合全景图解【Java线程安全实战】② ConcurrentHashMap 源码深度拆解如何做到高性能并发【Java线程安全实战】③ ThreadLocal 源码深度拆解如何做到线程隔离