synchronize偏向锁底层实现原理

1 偏向锁的意义

无多线程竞争时&＃xff0c;减少不必要的轻量级锁执行路径。大多数情况下&＃xff0c;锁不仅不存在多线程竞争&＃xff0c;而且总是由同一条线程去多次获得锁&＃xff0c;为了让线程获得锁的性能代价更低而引入了偏向锁。

偏向锁主要用来优化同一线程多次申请同一个锁的竞争&＃xff0c;即当对象被当做同步锁并有一个线程抢到了锁时&＃xff0c;则在Mark Word设置该线程的线程ID、是否偏向锁设置1、锁标志位设置01等信息&＃xff0c;此时的Mark Word 存储的就是偏向锁状态信息。

在&＃xff1a;

• 创建一个线程并在线程中执行循环监听的场景下

• 或单线程操作一个线程安全集合时

同一线程每次都需获取和释放锁&＃xff0c;每次操作都会发生用户态与内核态的切换。

获取偏向锁的场景&＃xff1a;

在自己的线程栈生成一条Lock Record&＃xff0c;然后Object Reference指向对象头&＃xff0c;此时Lock Record与对象头就建立了联系&＃xff1a;

① : 先判断Mard Word的Thread ID是否有值

• 没有&＃xff0c;则表示当前资源没有被其他线程占用&＃xff0c;把当前线程ID等信息记录到Mark Word&＃xff08;这需CAS&＃xff0c;可能多条线程修改Mark Word&＃xff0c;需要保证原子性&＃xff09;
• 有&＃xff0c;则表示当前资源被线程占用&＃xff0c;需要判断该线程是不是自己
  • 该线程ID是自己的&＃xff0c;则表示可重入&＃xff0c;直接获取(此时在自己的线程栈中继续生成一条新的Lock Record)
  • 该线程ID不是自己的&＃xff0c;说明出现其他线程竞争&＃xff0c;当前持有偏向锁的线程就需要撤销了&＃xff0c;即当其他线程尝试获取偏向锁才释放锁

轻量级锁的获取及释放依赖多次的CAS操作&＃xff0c;而偏向锁只依赖一次CAS置换ThreadID。

一旦出现多个线程竞争时必须撤销偏向锁&＃xff0c;所以&＃xff1a;

撤销偏向锁消耗的性能必须 &＃xff1c; 之前节省下来的CAS原子操作的性能消耗

不然得不偿失!

JDK6默认开启偏向锁&＃xff0c;可通过-XX:-UseBiasedLocking禁用偏向锁。

2 偏向锁的获取

偏向锁的入口&＃xff0c;synchronizer.cpp 文件的

ObjectSynchronizer::fast_enter

由BiasedLocking::revoke_and_rebias实现

2.1 markOop mark &＃61; obj->mark()

获取对象的markOop数据mark&＃xff0c;即对象头的Mark Word

2.2 判断mark是否为可偏向状态

mark的偏向锁的锁标志位为 01

2.3 判断mark中JavaThread的状态

• 若指向当前线程&＃xff0c;则执行同步代码块
• 若为空&＃xff0c;则走4
• 若指向其它线程&＃xff0c;则走5

2.4 执行CAS原子指令

设置mark中JavaThread为当前线程ID。

若CAS成功&＃xff0c;则执行同步代码块&＃xff0c;否则走5。

2.5 执行CAS失败

说明当前存在多个线程竞争锁&＃xff0c;当达到全局安全点&＃xff08;safepoint&＃xff09;&＃xff0c;获得偏向锁的线程就会被挂起&＃xff0c;撤销偏向锁&＃xff0c;并升级为轻量级锁。

升级完成后被阻塞在安全点的线程继续执行同步代码块。

BiasedLocking::Condition BiasedLocking::revoke_and_rebias(Handle obj, bool attempt_rebias, TRAPS) {assert(!SafepointSynchronize::is_at_safepoint(), "must not be called while at safepoint");// We can revoke the biases of anonymously-biased objects// efficiently enough that we should not cause these revocations to// update the heuristics because doing so may cause unwanted bulk// revocations (which are expensive) to occur.// step1markOop mark &＃61; obj->mark();if (mark->is_biased_anonymously() && !attempt_rebias) {// We are probably trying to revoke the bias of this object due to// an identity hash code computation. Try to revoke the bias// without a safepoint. This is possible if we can successfully// compare-and-exchange an unbiased header into the mark word of// the object, meaning that no other thread has raced to acquire// the bias of the object.markOop biased_value &＃61; mark;markOop unbiased_prototype &＃61; markOopDesc::prototype()->set_age(mark->age());markOop res_mark &＃61; (markOop) Atomic::cmpxchg_ptr(unbiased_prototype, obj->mark_addr(), mark);if (res_mark &＃61;&＃61; biased_value) {return BIAS_REVOKED;}} else if (mark->has_bias_pattern()) {Klass* k &＃61; obj->klass();markOop prototype_header &＃61; k->prototype_header();if (!prototype_header->has_bias_pattern()) {// This object has a stale bias from before the bulk revocation// for this data type occurred. It&＃39;s pointless to update the// heuristics at this point so simply update the header with a// CAS. If we fail this race, the object&＃39;s bias has been revoked// by another thread so we simply return and let the caller deal// with it.markOop biased_value &＃61; mark;markOop res_mark &＃61; (markOop) Atomic::cmpxchg_ptr(prototype_header, obj->mark_addr(), mark);assert(!(*(obj->mark_addr()))->has_bias_pattern(), "even if we raced, should still be revoked");return BIAS_REVOKED;} else if (prototype_header->bias_epoch() !&＃61; mark->bias_epoch()) {// The epoch of this biasing has expired indicating that the// object is effectively unbiased. Depending on whether we need// to rebias or revoke the bias of this object we can do it// efficiently enough with a CAS that we shouldn&＃39;t update the// heuristics. This is normally done in the assembly code but we// can reach this point due to various points in the runtime// needing to revoke biases.if (attempt_rebias) {assert(THREAD->is_Java_thread(), "");markOop biased_value &＃61; mark;markOop rebiased_prototype &＃61; markOopDesc::encode((JavaThread*) THREAD, mark->age(), prototype_header->bias_epoch());markOop res_mark &＃61; (markOop) Atomic::cmpxchg_ptr(rebiased_prototype, obj->mark_addr(), mark);if (res_mark &＃61;&＃61; biased_value) {return BIAS_REVOKED_AND_REBIASED;}} else {markOop biased_value &＃61; mark;markOop unbiased_prototype &＃61; markOopDesc::prototype()->set_age(mark->age());markOop res_mark &＃61; (markOop) Atomic::cmpxchg_ptr(unbiased_prototype, obj->mark_addr(), mark);if (res_mark &＃61;&＃61; biased_value) {return BIAS_REVOKED;}}}}HeuristicsResult heuristics &＃61; update_heuristics(obj(), attempt_rebias);if (heuristics &＃61;&＃61; HR_NOT_BIASED) {return NOT_BIASED;} else if (heuristics &＃61;&＃61; HR_SINGLE_REVOKE) {Klass *k &＃61; obj->klass();markOop prototype_header &＃61; k->prototype_header();if (mark->biased_locker() &＃61;&＃61; THREAD &&prototype_header->bias_epoch() &＃61;&＃61; mark->bias_epoch()) {// A thread is trying to revoke the bias of an object biased// toward it, again likely due to an identity hash code// computation. We can again avoid a safepoint in this case// since we are only going to walk our own stack. There are no// races with revocations occurring in other threads because we// reach no safepoints in the revocation path.// Also check the epoch because even if threads match, another thread// can come in with a CAS to steal the bias of an object that has a// stale epoch.ResourceMark rm;if (TraceBiasedLocking) {tty->print_cr("Revoking bias by walking my own stack:");}EventBiasedLockSelfRevocation event;BiasedLocking::Condition cond &＃61; revoke_bias(obj(), false, false, (JavaThread*) THREAD, NULL);((JavaThread*) THREAD)->set_cached_monitor_info(NULL);assert(cond &＃61;&＃61; BIAS_REVOKED, "why not?");if (event.should_commit()) {event.set_lockClass(k);event.commit();}return cond;} else {EventBiasedLockRevocation event;VM_RevokeBias revoke(&obj, (JavaThread*) THREAD);VMThread::execute(&revoke);if (event.should_commit() && (revoke.status_code() !&＃61; NOT_BIASED)) {event.set_lockClass(k);// Subtract 1 to match the id of events committed inside the safepointevent.set_safepointId(SafepointSynchronize::safepoint_counter() - 1);event.set_previousOwner(revoke.biased_locker());event.commit();}return revoke.status_code();}}assert((heuristics &＃61;&＃61; HR_BULK_REVOKE) ||(heuristics &＃61;&＃61; HR_BULK_REBIAS), "?");EventBiasedLockClassRevocation event;VM_BulkRevokeBias bulk_revoke(&obj, (JavaThread*) THREAD,(heuristics &＃61;&＃61; HR_BULK_REBIAS),attempt_rebias);VMThread::execute(&bulk_revoke);if (event.should_commit()) {event.set_revokedClass(obj->klass());event.set_disableBiasing((heuristics !&＃61; HR_BULK_REBIAS));// Subtract 1 to match the id of events committed inside the safepointevent.set_safepointId(SafepointSynchronize::safepoint_counter() - 1);event.commit();}return bulk_revoke.status_code();
}


3 偏向锁的撤销

只有当其它线程尝试竞争偏向锁时&＃xff0c;持有偏向锁的线程才会释放锁。

偏向锁的撤销由BiasedLocking::revoke_at_safepoint实现&＃xff1a;

void BiasedLocking::revoke_at_safepoint(Handle h_obj) {assert(SafepointSynchronize::is_at_safepoint(), "must only be called at safepoint");oop obj &＃61; h_obj();HeuristicsResult heuristics &＃61; update_heuristics(obj, false);if (heuristics &＃61;&＃61; HR_SINGLE_REVOKE) {revoke_bias(obj, false, false, NULL, NULL);} else if ((heuristics &＃61;&＃61; HR_BULK_REBIAS) ||(heuristics &＃61;&＃61; HR_BULK_REVOKE)) {bulk_revoke_or_rebias_at_safepoint(obj, (heuristics &＃61;&＃61; HR_BULK_REBIAS), false, NULL);}clean_up_cached_monitor_info();
}


1. 偏向锁的撤销动作必须等待全局安全点&＃xff08;safepoint&＃xff0c;GC时会让所有线程阻塞的停顿点&＃xff09;
2. 暂停拥有偏向锁的线程&＃xff0c;判断锁对象是否处于被锁定状态
3. 撤销偏向锁&＃xff0c;恢复到无锁&＃xff08;标志位 01&＃xff09;或轻量级锁&＃xff08;标志位 00&＃xff09;状态

偏向锁在Java 1.6后默认启用&＃xff0c;但在应用程序启动几s后才激活&＃xff0c;可关闭延迟&＃xff1a;

-XX:BiasedLockingStartupDelay&＃61;0


若确定应用程序中所有锁通常情况下处于竞争状态&＃xff0c;可关闭偏向锁&＃xff1a;

XX:-UseBiasedLocking&＃61;false&＃xff08;默认打开&＃xff09;


偏向锁的释放

遍历线程栈的所有Lock Record,把ObjectReference切断,即ObjectReference &＃61; null.

把ObjectReference置null&＃xff0c;但锁对象的对象头的Mark Word还是没改变&＃xff0c;依然偏向之前的线程&＃xff0c;那还是没释放锁的嘛&＃xff0c;的确是&＃xff0c;线程退出临界区时候&＃xff0c;并没有释放偏向锁&＃xff0c;这么做是为 : 当再次需要获取锁时&＃xff0c;只需要简单判断是否是重入&＃xff0c;即可快速获取锁&＃xff0c;而不用每次都CAS&＃xff0c;这也是偏向锁在只有一个线程访问锁的情景下高效的核心。

总结

• 当出现锁资源访问的时候&＃xff0c;都会在当前线程栈生成一条Lock Record&＃xff0c;并且ObjectReference将指向锁对象的对象头 的Mark Word&＃xff0c;该设置可能出现多线程&＃xff0c;需CAS操作
• 多线程情况下竞争同一个锁资源&＃xff0c;偏向锁的撤销会影响效率
• 偏向锁的重入计数依靠线程栈里Lock Record个数
• 偏向锁撤销失败&＃xff0c;最终会升级为轻量级锁
• 偏向锁退出时并没有修改Mark Word&＃xff0c;也就是没有释放锁
• 偏向锁相对轻量级锁来说&＃xff0c;当同一线程去再次获取锁的时候,不用进行CAS操作,提高了性能.(轻量级锁在同一线程情况下每次去获取锁,在无锁的状态下,每次都要进行一次CAS操作)
• 偏向锁只有遇到其他线程尝试竞争偏向锁时,持有偏向锁的线程才会释放锁,线程不会主动去释放偏向锁
• 偏向锁的撤销是很复杂&＃xff0c;成为理解代码的障碍&＃xff0c;也阻碍了对同步系统重构&＃xff0c;而且现如今基本都是多核系统&＃xff0c;偏向锁的劣势越来越明显&＃xff0c;所以在Java 15废弃了偏向锁