郑州网站搭建的公司视频网站是怎么做的

郑州网站搭建的公司,视频网站是怎么做的,18+网站推广,建造自己的网站Java并发编程#xff1a;synchronized 与 ReentrantLock Condition 的深度对比——从Monitor队列到惊群效应与精确唤醒前言正文一、每个Java对象天生都能当锁#xff1f;Monitor的底层结构形象比喻#xff1a;锁对象就像一个会议室。关键区别#xff1a;二、synchronized的…Java并发编程synchronized 与 ReentrantLock Condition 的深度对比——从Monitor队列到惊群效应与精确唤醒前言正文一、每个Java对象天生都能当锁Monitor的底层结构形象比喻锁对象就像一个会议室。关键区别二、synchronized的线程状态流转全过程完整过程演绎1. 抢锁阶段2. 条件不满足主动等待3. 被通知唤醒为什么被唤醒后还要再抢锁惊群效应的根源三、ReentrantLock Condition的高明之处按等待性质分类的多个队列四、生产者-消费者完整代码对比五、为什么JDK的高并发容器都用Condition总结从synchronized到Condition的进化前言最近和很多读者深入交流了Java多线程中两个核心的等待/通知机制synchronized wait/notify 和 ReentrantLock Condition。很多同学在学习时都会疑惑为什么Condition更高级为什么高并发容器都用Condition为什么synchronized容易出现“惊群效应”今天我们把这些问题全部串起来用最通俗易懂的语言从底层实现讲起一步步把Monitor的两个队列、线程状态流转、惊群效应、Condition的精确唤醒全部讲清楚。读完这篇你会对Java并发等待/通知机制有彻底的理解正文一、每个Java对象天生都能当锁Monitor的底层结构先来一个基础但超级重要的知识点Java中每个对象都可以作为锁对象因为它们都继承了Object类的wait()、notify()、notifyAll()方法。当一个对象第一次被用作锁比如进入synchronized(obj)块时JVM会给它分配一个叫Monitor对象监视器的结构。Monitor就像这个对象的“管家”里面主要有三样东西Owner当前持有锁的线程锁的“主人”。只有Owner才能执行临界区代码。Entry List入口等待队列还没抢到锁的线程被park阻塞在这里等着锁释放后一起竞争。Wait Set等待队列已经抢到锁但业务条件不满足主动调用wait()的线程会被放到这里深度睡眠。形象比喻锁对象就像一个会议室。Owner正在会议室里开会的人。Entry List门口排队的想进来开会的人抢不到门票。Wait Set已经进过会议室但发现“现在没内容可讨论”主动出去休息室睡觉的人。关键区别Entry List里的线程是因为抢不到锁而阻塞。Wait Set里的线程是抢到了锁但条件不满足主动释放锁去睡觉。二、synchronized的线程状态流转全过程我们用生产者-消费者场景来一步步看线程是怎么流动的。完整过程演绎1. 抢锁阶段线程A先进入synchronized(obj)成功抢到锁 → 成为Owner进入临界区。其他线程B、C、D也想进来发现锁被占了 → 被park到Entry List在门口排队。2. 条件不满足主动等待线程A在临界区发现“缓冲区满了没地方放东西”。调用obj.wait()立即释放锁Owner变为null会议室开门。自己走进Wait Set休息室睡觉完全不参与抢锁。锁释放后Entry List的线程B、C、D被唤醒开始竞争锁。3. 被通知唤醒假设线程B抢到锁消费后调用obj.notify()或notifyAll()。notify()从Wait Set随机选一个线程唤醒。notifyAll()把Wait Set里所有线程都唤醒。超级重要被唤醒的线程不会立刻拿到锁它们会从Wait Set转移到Entry List。然后和Entry List里其他线程一起重新竞争锁。只有抢到锁后才能继续执行wait()后面的代码。为什么被唤醒后还要再抢锁wait()必须在持有锁的情况下调用从wait()恢复也必须重新持有锁确保条件检查和修改是原子的。这也是为什么要用while检查条件防止虚假唤醒而不是if。惊群效应的根源synchronized只有一个Wait Set所有等待原因的线程生产者因为“满”、消费者因为“空”都挤在这里。一次notifyAll() → 把所有人转移到Entry List → 所有人抢锁 → 大部分醒来发现条件不满足又wait()回去 → 大范围惊群大量无谓的上下文切换性能很差。三、ReentrantLock Condition的高明之处按等待性质分类的多个队列Java为了解决synchronized的痛点引入了java.util.concurrent.locks包。ReentrantLock基于AQSAbstractQueuedSynchronizer底层更灵活。AQS有一个同步队列类似Entry List用来排队等锁。lock.newCondition()可以创建多个Condition对象每个Condition都有自己独立的等待队列类似Wait Set但可以有多个。JavaLock lock new ReentrantLock();Condition notFull lock.newCondition(); // 生产者专用缓冲区满时等待Condition notEmpty lock.newCondition(); // 消费者专用缓冲区空时等待关键点不是每个线程一个队列而是按“等待性质”分类一个Condition队列里可以有多个线程但这些线程的等待原因是相同的同一种性质。比如notFull队列里可能有50个生产者在等都因为缓冲区满。notEmpty队列里可能有30个消费者在等都因为缓冲区空。await/signal的工作原理await()释放锁 → 进入这个Condition的专属队列睡觉。signal()从这个队列头部取一个线程 → 转移到AQS同步队列 → 去抢锁和synchronized唤醒后去Entry List一样。signal()默认只唤醒一个先进先出signalAll()唤醒整个队列但只限同类线程。惊群范围大幅缩小消费者消费后只调用notEmpty.signal() → 只唤醒notEmpty队列里的消费者。生产者的50个线程完全不受影响继续睡觉。即使signalAll()也只影响同类线程远比synchronized的“唤醒所有人”好太多。加上signal()默认只醒一个在大多数场景几乎杜绝了惊群。“遥控器”比喻Condition对象就像一个遥控器你用哪个遥控器就操作哪个队列完全隔离。四、生产者-消费者完整代码对比synchronized版本容易大范围惊群JavapublicclassBuffer{privatefinal Object locknewObject();privatefinal QueueIntegerqueuenewLinkedList();privatefinal int capacity10;publicvoidproduce(int item)throws InterruptedException{synchronized(lock){while(queue.size()capacity){lock.wait();// 所有生产者进入同一个Wait Set}queue.offer(item);lock.notifyAll();// 唤醒所有人生产者消费者 → 大惊群}}publicintconsume()throws InterruptedException{synchronized(lock){while(queue.isEmpty()){lock.wait();// 所有消费者也进同一个Wait Set}int itemqueue.poll();lock.notifyAll();// 同上returnitem;}}}ReentrantLock Condition版本按性质分类精确唤醒JavapublicclassBuffer{privatefinal Lock locknewReentrantLock();privatefinal Condition notFulllock.newCondition();// 生产者队列privatefinal Condition notEmptylock.newCondition();// 消费者队列privatefinal QueueIntegerqueuenewLinkedList();privatefinal int capacity10;publicvoidproduce(int item)throws InterruptedException{lock.lock();try{while(queue.size()capacity){notFull.await();// 只进生产者专属队列}queue.offer(item);notEmpty.signal();// 只唤醒一个消费者推荐}finally{lock.unlock();}}publicintconsume()throws InterruptedException{lock.lock();try{while(queue.isEmpty()){notEmpty.await();// 只进消费者专属队列}int itemqueue.poll();notFull.signal();// 只唤醒一个生产者}finally{lock.unlock();}}}新版本代码更清晰、性能更高。五、为什么JDK的高并发容器都用Condition打开JDK源码ArrayBlockingQueue、LinkedBlockingQueue、ConcurrentHashMap部分等底层几乎全是用ReentrantLock Condition。原因多个独立队列 精确唤醒支持超时等待awaitNanos、可中断、公平锁等高级特性在高并发下性能远超synchronized总结从synchronized到Condition的进化synchronized wait/notify简单易用但只有一个Wait Set所有线程混在一起。wait()释放锁进Wait Setnotify后转移到Entry List再抢锁notifyAll()容易造成大范围惊群。ReentrantLock Condition按等待性质分类多个队列一个队列里多个同类线程。await/signal操作独立signal()默认只醒一个惊群范围大幅缩小几乎杜绝。推荐简单场景用synchronized复杂等待条件如生产者-消费者、读写锁强烈建议用Lock Condition。![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/c5721d2340f843d7bddc55fcf6369142.jpeg#pic_center