电子商务网站建设答辩记录,做汽配的外贸网站,网站推广的基本手段有哪些,青海 网站开发 图灵简单来说在JVM中的monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的#xff0c;但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行#xff0c;这种切换的代价是非常昂贵的#xff1b;然而在现实中大部分情况下#xff0c;同…简单来说在JVM中的monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行这种切换的代价是非常昂贵的然而在现实中大部分情况下同步方法是运行在单线程环境无锁竞争环境如果每次都调用Mutex Lock那么将严重的影响程序的性能。不过在jdk1.6中对锁的实现引入了大量的优化如锁粗话Lock Coarsening、锁消除Lock Elimination、轻量级锁Lightweight Locking、偏向锁Biased Locking、适应性自旋Adaptive Spinning等技术来减少锁操作的开销。
锁粗化Lock Coarsening也就是减少不必要的紧连在一起的unlocklock操作将多个连续的锁扩展成一个范围更大的锁。锁消除Lock Elimination通过运行时JIT编译器的逃逸分析来消除一些没有在当前同步块以外被其他线程共享的数据的锁保护通过逃逸分析也可以在线程本地Stack上进行对象空间的分配同时还可以减少Heep上的垃圾收集开销。轻量级锁Lightweight Locking这种锁实现的背后基于这样一种假设即在真实的情况下我们程序中的大部分同步代码一般都处于无锁竞争状态即但线程执行环境在无锁竞争的情况下完全可以避免调用操作系统层面的重量级互斥锁取而代之的是在monitorenter 和 monitorexit中只需要依靠一条CAS原子指令就可以完成锁的获取及释放。当存在锁竞争的情况下执行CAS指令失败的线程将调用操作系统互斥锁进入到阻塞状态当锁被释放的时候唤醒。偏向锁Biased Locking是为了在无锁竞争的情况下避免在锁获取过程中执行不必要的CAS原子指令因为CAS原子指令虽然相对于重量级锁来说开销比较小但还是存在非常客观的本地延迟。适应性自旋Adaptive Spinning当线程在获取轻量级锁的过程中执行CAS操作失败时在进入与monitor相关联的操作系统重量级锁mutex semaphore前会进入忙等待Spinning然后再次尝试当尝试一定的次数后如果仍然没有成功则调用与该monitor关联的semaphore即互斥锁进入到阻塞状态。
下面来详细讲解下先从Synchronized同步锁开始讲起
锁的类型
在java SE 1.6 里 Synchronized同步锁一共有四种状态无锁、偏向锁、轻量级锁、重量级锁它会随着竞争情况逐渐升级。锁可以升级但是不能降级目的是为了提供获取锁和释放锁的效率。 锁膨胀方向无锁-偏向锁-轻量级锁-重量级锁此过程是不可逆的 自旋锁与自适应锁
自旋锁 引入背景:大家都知道在没有加入锁优化时Synchronized是一个非常“胖大”的家伙。在多线程竞争锁时当一个线程获取锁时它会阻塞所有正在竞争的线程这样对性能带来了极大的影响。在挂起线程和恢复线程的操作都需要转入内核态中完成这些操作对系统的并发性能带来了很大的压力。同时HotSpot团队注意到在很多情况下共享数据的锁定状态只会持续很短的一段时间为了这段时间去挂起和回复阻塞线程并不值得。在如今多处理器环境下完全可以让另一个没有获取到锁的线程在门外等待一会(自旋)但不放弃CPU的执行时间。等待持有锁的线程是否很快就会释放锁。为了让线程等待我们只需要让线程执行一个忙循环(自旋)这便是自旋锁由来的原因。 自旋锁早在JDK1.4 中就引入了只是当时默认时关闭的。在JDK 1.6后默认为开启状态。自旋锁本质上与阻塞并不相同先不考虑其对多处理器的要求如果锁占用的时间非常的短那么自旋锁的性能会非常的好相反其会带来更多的性能开销(因为在线程自旋时始终会占用CPU的时间片如果锁占用的时间太长那么自旋的线程会白白消耗掉CPU资源)。因此自旋等待的时间必须要有一定的限度如果自旋超过了限定的次数仍然没有成功获取到锁就应该使用传统的方式去挂起线程了在JDK定义中自旋锁默认的自旋次数为10次用户可以使用参数-XX:PreBlockSpin 来更改。 可是现在又出现了一个问题:如果线程锁在线程自旋刚结束就释放掉了锁那么是不是有点得不偿失。所以这时候我们需要更加聪明的锁来实现更加灵活的自旋。来提高并发的性能。(这里则需要自适应自旋锁!) 自适应自旋锁 在JDK 1.6中引入了自适应自旋锁。这就意味着自旋的时间不再固定了而是由前一次在同一个锁上的自旋 时间及锁的拥有者的状态来决定的。如果在同一个锁对象上自旋等待刚刚成功获取过锁并且持有锁的线程正在运行中那么M会认为该锁自旋获取到锁的可能性很大会自动增加等待时间。比如增加到100此循环。相反如果对于某个锁自旋很少成功获取锁。那再以后要获取这个锁时将可能省略掉自旋过程以避免浪费处理器资源。有了自适应自旋IM对程序的锁的状态预测会越来越准确JM也会越来越聪明。 锁消除 锁消除是指虚拟机即时编译器再运行时对一些代码上要求同步但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持。意思就是:IM会判断再一段程序中的同步明显不会逃逸出去从而被其他线程访问到那M就把它们当作栈上数据对待认为这些数据是线程独有的不需要加同步。此时就会进行锁消除。 当然在实际开发中我们很清楚的知道哪些是线程独有的不需要加同步锁但是在Java API中有很多方法都是加了同步的那么此时JM会判断这段代码是否需要加锁。如果数据并不会逃逸则会进行锁消除。比如如下操作:在操作String类型数据时由于String是一个不可变类对字符串的连接操作总是通过生成的新的String对象来进行的。因此Javac编译器会对String连接做自动优化。在JDK1.5之前会使用StringBuffer对象的连续append0)操作在JDK 1.5及以后的版本中会转化为StringBuidler对象的连续append()操作。 众所周知StringBuilder不是安全同步的但是在上述代码中IM判断该段代码并不会逃逸则将该代码带默认为线程独有的资源并不需要同步所以执行了锁消除操作。(还有Vector中的各种操作也可实现锁消除。在没有逃逸出数据安全防卫内) 锁粗化 原则上我们都知道在加同步锁时尽可能的将同步块的作用范围限制到尽量小的范围(只在共享数据的实际作用域中才进行同步这样是为了使得需要同步的操作数量尽可能变小。在存在锁同步竞争中也可以使得等待锁的线程尽早的拿到锁)。 大部分上述情况是完美正确的但是如果存在连串的一系列操作都对同一个对象反复加锁和解锁,甚至加锁操作时出现在循环体中的那即使没有线程竞争频繁的进行互斥同步操作也会导致不必要的性能操作。 这里贴上根据上述Javap 编译的情况编写的实例iava类 在上述的连续append0)操作中就属于这类情况。IM会检测到这样一连串的操作都是对同一个对象加锁那么JM会将加锁同步的范围扩展(粗化)到整个一系列操作的 外部使整个一连串的append0操作只需要加锁一次就可以了。 轻量级锁 在JDK 1.6之后引入的轻量级锁需要注意的是轻量级锁并不是替代重量级锁的而是对在大多数情况下同步块并不会有竞争出现提出的一种优化。它可以减少重量级锁对线程的阻塞带来的线程开销。从而提高并发性能。 如果要理解轻量级锁那么必须先要了解HotSpot虚拟机中对象头的内存布局。上面介绍Java对象头也详细介绍过。在对象头中(object Header )存在两部分。第一部分用于存储对象自身的运行时数据 Hashcode、Gc Age、锁标记位、是否为偏向锁 。等。一般为32位或者64位(视操作系统位数定)。官方称之为 Mark word 它是实现轻量级锁和偏向锁的关键。另外一部分存储的是指向方法区对象类型数据的指针(Klass Point)如果对象是数组的话还会有一个额外的部分用于存储数据的长度。 轻量级锁加锁 在线程执行同步块之前IM会先在当前线程的栈帧中创建一个名为锁记录(Lock Record )的空间用于存储锁对象目前的 Mark word 的拷贝(VM会将对象头中的 Mark word 拷贝到锁记录中官方称为 Displaced Mark ward )这个时候线程堆栈与对象头的状态如图: 如上图所示:如果当前对象没有被锁定那么锁标志位为01状态IM在执行当前线程时首先会在当前线程栈帧中创建锁记录 Lock Record 的空间用于存储锁对象目前的 Mark Word 的拷贝。 然后虚拟机使用CAS操作将标记字段Mark Word拷贝到锁记录中并且将 Mark word 更新为指向 Lock Record 的指针。如果更新成功了那么这个线程就拥用了该对象的锁并目对象MarkWord的锁标志位更新为( Mark word 中最后的2bit)00即表示此对象处于轻量级锁定状态如图: 如果这个更新操作失败JM会检査当前的 Mark word 中是否存在指向当前线程的栈帧的指针如果有说明该锁已经被获取可以直接调用。如果没有则说明该锁被其他线程抢占了如果有两条以上的线程竞争同一个锁那轻量级锁就不再有效直接膨胀为重量级锁没有获得锁的线程会被阻塞。此时锁的标志位为 10.Mark word 中存储的指向重量级锁的指针。 轻量级解锁时会使用原子的CAS操作将 Displaced Mark Word 替换回到对象头中如果成功则表示没有发生竞争关系。如果失败表示当前锁存在竞争关系。锁就会膨胀成重量级锁。两个线程同时争夺锁导致锁膨胀的流程图如下: 偏向锁 引入背景:在大多实际环境下锁不仅不存在多线程竞争而且总是由同一个线程多次获取那么在同一个线程反复获取所释放锁中其中并还没有锁的竞争那么这样看上去多次的获取锁和释放锁带来了很多不必要的性能开销和上下文切换。 为了解决这一问题Hotspot的作者在Java SE 1.6 中对Synchronized进行了优化引入了偏向锁。当一个线程访问同步块并获取锁时会在对象头和栈帧中的锁记录里存储锁偏向的线程ID以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁。只需要简单的测试一下对象头的 Mark Word 里是否存储着指向当前线程的偏向锁。如果成功表示线程已经获取到了锁。 偏向锁的撤销 偏向锁使用了一种等待竞争出现才会释放锁的机制。所以当其他线程尝试获取偏向锁时持有偏向锁的线程才会释放锁。但是偏向锁的撤销需要等到全局安全点(就是当前线程没有正在执行的字节码)。它会首先暂停拥有偏向锁的线程让你后检查持有偏向锁的线程是否活着。如果线程不处于活动状态直接将对象头设置为无锁状态。如果线程活着IM会遍历栈帧中的锁记录栈帧中的锁记录和对象头要么偏向于其他线程要么恢复到无锁状态或者标记对象不适合作为偏向锁。 锁的优缺点对比
锁优点缺点使用场景偏向锁加锁和解锁不需要CAS操作没有额外的性能消耗和执行非同步方法相比仅存在纳秒级的差距如果线程间存在锁竞争会带来额外的锁撤销的消耗适用于只有一个线程访问同步块的场景轻量级锁竞争的线程不会阻塞提高了响应速度如线程始终得不到锁竞争的线程使用自旋会消耗CPU性能追求响应时间同步块执 行速度非常快重量级锁线程竞争不适用自旋不会消耗CPU线程阻塞响应时间缓 慢在多线程下频繁的获取释放锁会带来巨大的性能消耗追求吞吐量同步块执行 速度较长
