厦门市城乡建设局网站,关于做膳食的一些网站,建网站logo怎么做,啥是网络推广为了线程间更高效的共享数据及解决竞争问题#xff0c;提高程序执行效率#xff0c;JDK 6 做了大量锁优化#xff0c;如适应性自旋#xff08;Adaptive Spinning#xff09;、锁消除#xff08;Lock Elimination#xff09;、锁膨胀#xff08;Lock Coarsening#xf…为了线程间更高效的共享数据及解决竞争问题提高程序执行效率JDK 6 做了大量锁优化如适应性自旋Adaptive Spinning、锁消除Lock Elimination、锁膨胀Lock Coarsening、轻量级锁Lightweight Locking、偏向锁Biased Locking等 文章目录1. 自旋锁与自适应自旋2. 锁消除3. 锁粗化4. 轻量级锁5. 偏向锁1. 自旋锁与自适应自旋
自旋锁让后面请求锁的线程稍等一会但不放弃处理器的执行时间看持有锁的线程是否很快释放锁为了让线程等待需让线程执行一个忙循环自旋
自旋等待不能代替阻塞它虽然避免了线程切换的开销但会占用处理器时间锁被占用的时间很短时自旋等待效果很好但长时间自旋的线程会浪费 CPU 资源
-XX:PreBlockSpin设置自旋次数超过后使用传统方式挂起线程
自适应自旋自旋时间不是固定的而是由前一次在同一锁上自旋时间及锁的拥有者的状态来决定上次自旋成功获得锁则可能允许自旋等待更长的时间上次自旋失败则可能不在允许自旋等待
2. 锁消除
锁消除JVM 在即时编译期对一些代码要求同步但被检测到不可能存在共享数据竞争逃逸分析堆上所有数据都不会逃逸出线程就可以把它们当做栈上数据对待即线程私有的锁进行消除
JDK 5 之前同步代码示例
public String concatString(String s1, String s2, String s3) {return s1 s2 s3;
}javac 编译后的连接操作
public String concatString(String s1, String s2, String s3) {StringBuffer sb new StringBuffer();sb.append(s1);sb.append(s2);sb.append(s3);return sb.toString();
}每个 append() 方法内部都是一个同步块锁对象是 sb经过逃逸分析发现 sb 的所有引用都不会逃逸出 concatString() 方法其他线程无法访问到它因此可以在即时编译阶段安全的消除锁在解释执行存在锁在编译执行没有锁JDK 5 之后改用非线程安全的 StringBuilder 就不会自动加锁了
3. 锁粗化
原则上编写代码时推荐奖同步块的作用范围限制得尽量小只有共享数据的实际作用域才进行同步这样即使存在锁竞争也可尽可能快地拿到锁
但若频繁对同一个对象反复加锁和解锁甚至在循环体上加锁即使没有线程竞争频繁互斥操作也会导致不必要的性能损耗因此 JVM 会直接把加锁同步的范围扩展粗化到整个操作序列的外部如上例直接在第一个 append() 之前加锁在最后一个 append() 之后解锁
4. 轻量级锁
不是用来代替重量级锁的而是在没有多线程竞争时减少传统重量级锁的操作系统互斥产生的性能消耗 在线程即将进入同步块时若此同步对象还没有被锁定01 状态JVM 会先在当前线程的栈帧中建立一个锁记录Lock Record空间用于存储锁对象目前 Mark Work 的拷贝Displace Mark Word
然后 JVM 尝试使用 CAS 操作把对象的 Mark Word 更新为执行 Lock Record 的指针若 CAS 操作成功代表该线程拥有了这个对象的锁对象 Mark Word 的锁标志为将转变为 00 状态
若 CAS 操作失败代表至少有一个线程与当前线程竞争获取该对象的锁JVM 会先检查对象的 Mark Word 是否指向当前线程的栈帧若是说明当前线程已拥有这个对象的锁直接进入同步块继续执行即可若否则说明这个对象的锁已经被其他线程占有若出现两条以上线程占用同一个锁则轻量级锁不再有效必须膨胀为重量级锁锁标志状态变为 10此时 Mark Word 中存储的是指向重量级锁互斥量的指针等待锁的线程必须进入阻塞状态
轻量级锁的解锁过程同样使用 CAS 操作若对象的 Mark Word 任然指向线程的锁记录就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来若成功则整个同步过程顺利完成否则说明有其他线程尝试过获取锁就要释放锁并唤醒被挂起的线程
轻量级锁的适用场景是绝大部分锁在整个同步周期内部存在竞争没有竞争的情况下轻量级锁通过 CAS 操作可以成功避免使用互斥量的开销但若竞争存在除了互斥量本身的开销额外的 CAS 操作开销会让消耗比传统重量级锁更大
5. 偏向锁
JDK 6 引入的锁优化措施用于消除数据在无竞争情况下的同步原语轻量级锁是消除无竞争状态下的互斥量
如果第一个获得锁的线程在接下来的执行中一致没有其他线程竞争则持有偏向锁线程永远不需要再进行同步
锁对象第一次被线程获取时JVM 会把对象头中的标志位设置为 01把偏向模式设置为 1表示进入偏向模式同时使用 CAS 操作把获得这个锁的线程的 ID 记录在对象的 Mark Word 中若 CAS 操作成功持有偏向锁的线程以后每次进入这个锁相关的同步块都不再进行同步操作加锁、解锁、Mark Word 更新操作等
一旦出现另外的线程去尝试获取这个锁偏向模式立刻结束若对象未被锁定撤销偏向偏向模式置为 0后标志位恢复到未锁定01若对象已被锁定则标志位置为 00使用轻量级锁 当一个对象已经计算过一次一致性哈希码它就无法再进入偏向锁状态而当一个对象正处理偏向锁状态又收到计算一致性哈希码请求时它的偏向状态会立即测校且锁会膨胀为重量级锁对象头指向重量级锁的位置代表重量级锁的 ObjectMonitor 类里可以记录非加锁状态下的 Mark Word也可以存储原来的哈希码
若程序中大多数的锁总是被多个不同线程访问偏向模式就是多余的可能使用 -XX:-UseBiasedLocking 禁用偏向锁优化反而可使性能提升
-XX:UseBiasedLocking启用偏向锁JDK 6 开始 HotSpot VM 默认开启 上一篇「JVM 高效并发」线程安全 专栏《JVM 体系梳理》
PS感谢每一位志同道合者的阅读欢迎关注、评论、赞 参考资料
[1]《深入理解 Java 虚拟机》
