网站建设捌金手指下拉一网上做任务的网站

网站建设捌金手指下拉一,网上做任务的网站,建设银行深圳分行网站,安装wordpress主题放哪里在多个线程访问共享资源的时候#xff0c;由于分时系统#xff0c;线程可能发生切换#xff0c;导致指令没有按照我们预想的顺序执行#xff0c;从而致使发生错误。例如商场系统中经典的库存超卖问题#xff0c;就是多线程并发导致的问题。 为了准确描述问题#xff0c;…在多个线程访问共享资源的时候由于分时系统线程可能发生切换导致指令没有按照我们预想的顺序执行从而致使发生错误。例如商场系统中经典的库存超卖问题就是多线程并发导致的问题。为了准确描述问题我们引入两个概念临界区(Critical Section)、竞态条件(Race Condition)临界区临界区是指访问共享资源的代码块区域并可能被多个线程同时执行竞态条件竞态条件是指多个线程同时在临界区执行由于执行的顺序未知导致结果不可预测要解决并发带来的问题就是要避免临界区的竞态条件常用的手段如下阻塞式方案synchronized、ReentrantLock非阻塞式方案原子化操作、乐观锁本文主要介绍synchronized方案并介绍synchronized的一些原理聊一聊不能唠的比磕~synchronized 用法对于想要保护的临界区我们可以直接用synchronized给这块区域上锁synchronized(obj) { // 临界区 } synchronized(obj.class) { // 临界区 }可以看到上面的示例代码我们既可以锁对象实例也可以锁对象的Class对象。我们把它们分别称作实例锁、类锁实例锁锁定的是堆中的实例对象类锁锁定的是方法区中的Class对象我们也可以直接在方法上加 synchronized 来上锁public class Example { public synchronized static void t1() { // 临界区 // 锁static方法相当于上类锁 } public synchronized void t2() { // 临界区 // 锁非static方法相当于上实例锁 } }synchronized 采取互斥的方式让同一时刻只有一个线程可以拿到锁对象只有拿到锁对象的线程才可以执行临界区的代码。这样就可以保证拿到锁的线程可以安全地执行临界区的代码不用担心线程上下文切换时其它线程执行临界区的代码。 syncrhonized 本质上是用对象锁保证了临界区中的代码的原子性让临界区的代码执行时不可分割不会被线程切换打断。锁升级synchronized 会在遇到不同的情况之后进行锁膨胀这对开发者是透明的。你只要上锁就行了synchronized考虑的可就多了 (bushi)。 在JDK15前锁膨胀的路径是无锁 - 偏向锁 - 轻量级锁 - 重量级锁。因为近年来大多数应用的并发模式中由偏向锁带来的收益已经小于其维护开销因此JDK15决定默认禁用它所以JDK15以后的锁膨胀的路径是无锁 - 轻量级锁 - 重量级锁。本文以JDK15以后的环境为准介绍轻量级锁和重量级锁对象头为了更好的介绍轻量级锁的上锁原理首先我们需要了解以下对象头。对象头是Java对象在内存中的一部分用于存储该对象的元数据和运行时信息。普通对象头主要由两部分组成Mark Word和Klass Word数组对象还要多一个数组长度。如下图其中Mark Word的结构为可以看到Mark Word中存储了线程上锁的状态无锁、偏向锁、轻量级锁、重量级锁这些正是锁膨胀的路径可以发现在状态为轻量级时有指针ptr_to_lock_record, 状态为重量级锁时有指针prt_to_heavyweight_monitor接下来我们一一介绍。轻量级锁当第一个线程首次抢到锁进入synchronized同步块的时候会变成轻量级锁的状态。JVM会在当前线程创建一个Lock Record的记录空间这个Lock Record包含两部分Displaced Mark Word、指向锁对象的引用。Displaced Mark Word会拷贝一份锁对象原来的Mark Word并保存起来以便以后释放锁的时候恢复。然后线程使用CAS原子操作尝试将锁对象头中的Mark Word中的ptr_to_lock_record指针指向该线程栈帧中Lock Record。如果CAS成功即当前锁对象的Mark Word仍然是Lock Record之前复制时的状态那么说明当前没有其它线程竞争则此时当前线程获得该锁对象的轻量级锁如果CAS失败那么说当前存在其它线程竞争此时会进入锁膨胀这个后面再说 所以加轻量级锁的逻辑如下图那么如果发生了锁重入呢这时JVM会在线程栈创建一个新的Lock Record但是这个Lock Record的 displaced mark word 会被设置为 null起到一个计数器的作用而不是复制对象头中的 mark wordJVM不会对这个新的 Lock Record 执行CAS去修改锁的对象头。在解锁的时候会先解开内部同步块的锁对应到线程栈中就是先弹出栈中 displaced mark word 为 null 的 LockRecord这样就实现了可重入锁。回到之前的线程竞争问题如果CAS失败那么说明当前线程存在竞争此时当前线程会进入自旋也可以说是忙等待也就是不断尝试获取锁如果自旋期间锁被释放了那么就可能抢到锁否则如果自旋期间没有抢到锁就会进行锁膨胀升级为重量级锁。所以我们可以发现轻量级锁只适应无线程竞争或者少量线程竞争的场景一旦面临多线程竞争时就需要用到重量级锁重量级锁对于每一个锁对象都会关联一个Monitor这个Monitor就是真正的“锁”Monitor的结构如下可以看到Monitor中有Owner、EntryList、WaitSet整个重量级锁就是由这三个字段给管理起来的。当轻量级锁膨胀升级为重量级锁时原先持有锁的线程就会让owner指向该线程而竞争失败的线程会进入EntryList进入阻塞状态等待锁释放后被唤醒。WaitSet 是WAITING状态线程呆的地方比如在线程中调用了obj.wait()就会进入WAITING状态如果再被notify给叫醒就会重新与其它线程进行竞争。这时发生线程竞争和锁重入就很好办了。首先对于锁重入Monitor中有个锁计数器在第一次获取锁的时候线程会基于CAS将owner指向当前线程并将锁计数器加一而在第二次时如果发现目前要获取的锁已经是当前持有的锁时就直接不执行CAS操作直接将锁计数器加一就行。在后面退出锁的时候将计数器减一直到计数器为1时把计数器减为0然后置owner为null。发生线程竞争时如果当前竞争锁的线程发现目前的owner已经指向其它线程了那么与轻量级锁近似竞争失败的线程在进入EntryList之前会有一个短暂的自旋优化尝试。这个自旋操作是为了在锁可能很快释放的情况下避免线程阻塞和唤醒的成本。synchronized 的秘密可以和你一起竞争锁这件事本身就已经很带派了当你写下synchronized(obj)这一行代码时就像是与 JVM 立下了一个默契的约定。JVM 则在背后默默地为你上演着一出出锁升级、自旋、排队、唤醒的精彩大戏。所以下次当你使用它时或许可以会心一笑想起这一切背后的精妙设计。