myblog
myblog copied to clipboard
farmerjohngit
死磕Synchronized底层实现--轻量级锁
死磕Synchronized底层实现--轻量级锁
本文为死磕Synchronized底层实现第三篇文章，内容为轻量级锁实现。
轻量级锁并不复杂，其中很多内容在偏向锁一文中已提及过，与本文内容会有部分重叠。
另外轻量级锁的背景和基本流程在概论中已有讲解。强烈建议在看过两篇文章的基础下阅读本文。
本系列文章将对HotSpot的synchronized锁实现进行全面分析，内容包括偏向锁、轻量级锁、重量级锁的加锁、解锁、锁升级流程的原理及源码分析，希望给在研究synchronized路上的同学一些帮助。主要包括以下几篇文章：
更多文章见个人博客：https://github.com/farmerjohngit/myblog
本文分为两个部分：
1.轻量级锁获取流程
2.轻量级锁释放流程
本人看的JVM版本是jdk8u，具体版本号以及代码可以在这里看到。
轻量级锁获取流程
下面开始轻量级锁获取流程分析，代码在bytecodeInterpreter.cpp#1816。
CASE(_monitorenter): {
oop lockee = STACK_OBJECT(-1);
...
if (entry != NULL) {
...
// 上面省略的代码中如果CAS操作失败也会调用到InterpreterRuntime::monitorenter
// traditional lightweight locking
if (!success) {
// 构建一个无锁状态的Displaced Mark Word
markOop displaced = lockee->mark()->set_unlocked();
// 设置到Lock Record中去
entry->lock()->set_displaced_header(displaced);
bool call_vm = UseHeavyMonitors;
if (call_vm || Atomic::cmpxchg_ptr(entry, lockee->mark_addr(), displaced) != displaced) {
// 如果CAS替换不成功，代表锁对象不是无锁状态，这时候判断下是不是锁重入
// Is it simple recursive case?
if (!call_vm && THREAD->is_lock_owned((address) displaced->clear_lock_bits())) {
entry->lock()->set_displaced_header(NULL);
} else {
// CAS操作失败则调用monitorenter
CALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);
}
}
}
UPDATE_PC_AND_TOS_AND_CONTINUE(1, -1);
} else {
istate->set_msg(more_monitors);
UPDATE_PC_AND_RETURN(0); // Re-execute
}
}
如果锁对象不是偏向模式或已经偏向其他线程，则success为false。这时候会构建一个无锁状态的mark word设置到Lock Record中去，我们称Lock Record中存储对象mark word的字段叫Displaced Mark Word。
如果当前锁的状态不是无锁状态，则CAS失败。如果这是一次锁重入，那直接将Lock Record的 Displaced Mark Word设置为null。
我们看个demo，在该demo中重复3次获得锁，
synchronized(obj){
synchronized(obj){
synchronized(obj){
}
}
}
假设锁的状态是轻量级锁，下图反应了mark word和线程栈中Lock Record的状态，可以看到右边线程栈中包含3个指向当前锁对象的Lock Record。其中栈中最高位的Lock Record为第一次获取锁时分配的。其Displaced Mark word的值为锁对象的加锁前的mark word，之后的锁重入会在线程栈中分配一个Displaced Mark word为null的Lock Record。
为什么JVM选择在线程栈中添加Displaced Mark word为null的Lock Record来表示重入计数呢？首先锁重入次数是一定要记录下来的，因为每次解锁都需要对应一次加锁，解锁次数等于加锁次数时，该锁才真正的被释放，也就是在解锁时需要用到说锁重入次数的。一个简单的方案是将锁重入次数记录在对象头的mark word中，但mark word的大小是有限的，已经存放不下该信息了。另一个方案是只创建一个Lock Record并在其中记录重入次数，Hotspot没有这样做的原因我猜是考虑到效率有影响：每次重入获得锁都需要遍历该线程的栈找到对应的Lock Record，然后修改它的值。
所以最终Hotspot选择每次获得锁都添加一个Lock Record来表示锁的重入。
接下来看看InterpreterRuntime::monitorenter方法
IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem))
...
Handle h_obj(thread, elem->obj());
assert(Universe::heap()->is_in_reserved_or_null(h_obj()),
"must be NULL or an object");
if (UseBiasedLocking) {
// Retry fast entry if bias is revoked to avoid unnecessary inflation
ObjectSynchronizer::fast_enter(h_obj, elem->lock(), true, CHECK);
} else {
ObjectSynchronizer::slow_enter(h_obj, elem->lock(), CHECK);
}
...
IRT_END
fast_enter的流程在偏向锁一文已经分析过，如果当前是偏向模式且偏向的线程还在使用锁，那会将锁的mark word改为轻量级锁的状态，同时会将偏向的线程栈中的Lock Record修改为轻量级锁对应的形式。代码位置在biasedLocking.cpp#212。
// 线程还存活则遍历线程栈中所有的Lock Record
GrowableArray<MonitorInfo*>* cached_monitor_info = get_or_compute_monitor_info(biased_thread);
BasicLock* highest_lock = NULL;
for (int i = 0; i < cached_monitor_info->length(); i++) {
MonitorInfo* mon_info = cached_monitor_info->at(i);
// 如果能找到对应的Lock Record说明偏向的线程还在执行同步代码块中的代码
if (mon_info->owner() == obj) {
...
// 需要升级为轻量级锁，直接修改偏向线程栈中的Lock Record。为了处理锁重入的case，在这里将Lock Record的Displaced Mark Word设置为null，第一个Lock Record会在下面的代码中再处理
markOop mark = markOopDesc::encode((BasicLock*) NULL);
highest_lock = mon_info->lock();
highest_lock->set_displaced_header(mark);
} else {
...
}
}
if (highest_lock != NULL) {
// 修改第一个Lock Record为无锁状态，然后将obj的mark word设置为指向该Lock Record的指针
highest_lock->set_displaced_header(unbiased_prototype);
obj->release_set_mark(markOopDesc::encode(highest_lock));
...
} else {
...
}
我们看slow_enter的流程。
void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {
markOop mark = obj->mark();
assert(!mark->has_bias_pattern(), "should not see bias pattern here");
// 如果是无锁状态
if (mark->is_neutral()) {
//设置Displaced Mark Word并替换对象头的mark word
lock->set_displaced_header(mark);
if (mark == (markOop) Atomic::cmpxchg_ptr(lock, obj()->mark_addr(), mark)) {
TEVENT (slow_enter: release stacklock) ;
return ;
}
} else
if (mark->has_locker() && THREAD->is_lock_owned((address)mark->locker())) {
assert(lock != mark->locker(), "must not re-lock the same lock");
assert(lock != (BasicLock*)obj->mark(), "don't relock with same BasicLock");
// 如果是重入，则设置Displaced Mark Word为null
lock->set_displaced_header(NULL);
return;
}
...
// 走到这一步说明已经是存在多个线程竞争锁了 需要膨胀为重量级锁
lock->set_displaced_header(markOopDesc::unused_mark());
ObjectSynchronizer::inflate(THREAD, obj())->enter(THREAD);
}
轻量级锁释放流程
CASE(_monitorexit): {
oop lockee = STACK_OBJECT(-1);
CHECK_NULL(lockee);
// derefing's lockee ought to provoke implicit null check
// find our monitor slot
BasicObjectLock* limit = istate->monitor_base();
BasicObjectLock* most_recent = (BasicObjectLock*) istate->stack_base();
// 从低往高遍历栈的Lock Record
while (most_recent != limit ) {
// 如果Lock Record关联的是该锁对象
if ((most_recent)->obj() == lockee) {
BasicLock* lock = most_recent->lock();
markOop header = lock->displaced_header();
// 释放Lock Record
most_recent->set_obj(NULL);
// 如果是偏向模式，仅仅释放Lock Record就好了。否则要走轻量级锁or重量级锁的释放流程
if (!lockee->mark()->has_bias_pattern()) {
bool call_vm = UseHeavyMonitors;
// header!=NULL说明不是重入，则需要将Displaced Mark Word CAS到对象头的Mark Word
if (header != NULL || call_vm) {
if (call_vm || Atomic::cmpxchg_ptr(header, lockee->mark_addr(), lock) != lock) {
// CAS失败或者是重量级锁则会走到这里，先将obj还原，然后调用monitorexit方法
most_recent->set_obj(lockee);
CALL_VM(InterpreterRuntime::monitorexit(THREAD, most_recent), handle_exception);
}
}
}
//执行下一条命令
UPDATE_PC_AND_TOS_AND_CONTINUE(1, -1);
}
//处理下一条Lock Record
most_recent++;
}
// Need to throw illegal monitor state exception
CALL_VM(InterpreterRuntime::throw_illegal_monitor_state_exception(THREAD), handle_exception);
ShouldNotReachHere();
}
轻量级锁释放时需要将Displaced Mark Word替换到对象头的mark word中。如果CAS失败或者是重量级锁则进入到InterpreterRuntime::monitorexit方法中。
//%note monitor_1
IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorexit(JavaThread* thread, BasicObjectLock* elem))
Handle h_obj(thread, elem->obj());
...
ObjectSynchronizer::slow_exit(h_obj(), elem->lock(), thread);
// Free entry. This must be done here, since a pending exception might be installed on
//释放Lock Record
elem->set_obj(NULL);
...
IRT_END
monitorexit调用完slow_exit方法后,就释放Lock Record。
void ObjectSynchronizer::slow_exit(oop object, BasicLock* lock, TRAPS) {
fast_exit (object, lock, THREAD) ;
}
void ObjectSynchronizer::fast_exit(oop object, BasicLock* lock, TRAPS) {
...
markOop dhw = lock->displaced_header();
markOop mark ;
if (dhw == NULL) {
// 重入锁，什么也不做
...
return ;
}
mark = object->mark() ;
// 如果是mark word==Displaced Mark Word即轻量级锁，CAS替换对象头的mark word
if (mark == (markOop) lock) {
assert (dhw->is_neutral(), "invariant") ;
if ((markOop) Atomic::cmpxchg_ptr (dhw, object->mark_addr(), mark) == mark) {
TEVENT (fast_exit: release stacklock) ;
return;
}
}
//走到这里说明是重量级锁或者解锁时发生了竞争，膨胀后调用重量级锁的exit方法。
ObjectSynchronizer::inflate(THREAD, object)->exit (true, THREAD) ;
}
该方法中先判断是不是轻量级锁，如果是轻量级锁则将替换mark word，否则膨胀为重量级锁并调用exit方法，相关逻辑将在重量级锁的文章中讲解。
revoke_bias方法代码中有一行注解 // 修改第一个Lock Record为无锁状态，然后将obj的mark word设置为执行该Lock Record的指针 此处应说的设置为指向该Lock Record的指针 偏向锁那一章也是如此吧
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
另外，在轻量级锁加锁中，CAS的原值若不是从对象中取，而是通过调用对象的hashcode()方法获取，那如果对象所属类的hashcode方法被重写了，获取锁的线程在代码块里头更改锁对象的某个属性值了，岂不是，当线程释放完锁之后，锁对象头里的hashcode变成了一个过期的脏数据hashcode值，那以后所有的线程都没法对这个对象加锁了？
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
没看懂你在说什么。。你说的是轻量级加锁的cas过程？ 原值是无锁的markword，期望值是当前的Lock Record。所以不会有两个线程同时执行同步块
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
大致明白了你的意思，你可以看下博主上面的源码，每次CAS的话，走的是Atomic::cmpxchg_ptr这个方法，对于compareValue的话，是构建一个无锁状态的Displaced Mark Word，所以线程A获得轻量级锁，修改了markword，但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的，所以无法cas成功
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
大致明白了你的意思，你可以看下博主上面的源码，每次CAS的话，走的是Atomic::cmpxchg_ptr这个方法，对于compareValue的话，是构建一个无锁状态的Displaced Mark Word，所以线程A获得轻量级锁，修改了markword，但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的，所以无法cas成功
我理解应该和内存可见性相关，线程A，B几乎在同时得到monitor enter指令，那么此时二者在各自线程中都存有对象O的缓存，此时必然会导致如果线程A的CAS成功，B的CAS失败
你还是成功绕开了我的问题，虽然你回答了不少。你回答：但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的 我的疑问一直都是：怎么会不一样？ 传入的无锁状态值从什么地方取来的？难道不是从对象头中取出来？线程A已经获取了锁，现在对象头存储的是线程A的LR，线程B从对象头中取出的是线程A的LR，做CAS替换时，怎么和对象头中存储的不一样？什么叫无锁状态值？我们现在讨论的就是这个东西，你来了个糊弄的回答
在 2019-06-12 16:22:48，"scn7th" [email protected] 写道：
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
大致明白了你的意思，你可以看下博主上面的源码，每次CAS的话，走的是Atomic::cmpxchg_ptr这个方法，对于compareValue的话，是构建一个无锁状态的Displaced Mark Word，所以线程A获得轻量级锁，修改了markword，但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的，所以无法cas成功
我理解应该和内存可见性相关，线程A，B几乎在同时得到monitor enter指令，那么此时二者在各自线程中都存有对象O的缓存，此时必然会导致如果线程A的CAS成功，B的CAS失败
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
你还是成功绕开了我的问题，虽然你回答了不少。你回答：但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的 我的疑问一直都是：怎么会不一样？ 传入的无锁状态值从什么地方取来的？难道不是从对象头中取出来？线程A已经获取了锁，现在对象头存储的是线程A的LR，线程B从对象头中取出的是线程A的LR，做CAS替换时，怎么和对象头中存储的不一样？什么叫无锁状态值？我们现在讨论的就是这个东西，你来了个糊弄的回答 在 2019-06-12 16:22:48，"scn7th" [email protected] 写道： 我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？ 大致明白了你的意思，你可以看下博主上面的源码，每次CAS的话，走的是Atomic::cmpxchg_ptr这个方法，对于compareValue的话，是构建一个无锁状态的Displaced Mark Word，所以线程A获得轻量级锁，修改了markword，但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的，所以无法cas成功 我理解应该和内存可见性相关，线程A，B几乎在同时得到monitor enter指令，那么此时二者在各自线程中都存有对象O的缓存，此时必然会导致如果线程A的CAS成功，B的CAS失败 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
我也有这个疑问。
你还是成功绕开了我的问题，虽然你回答了不少。你回答：但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的 我的疑问一直都是：怎么会不一样？ 传入的无锁状态值从什么地方取来的？难道不是从对象头中取出来？线程A已经获取了锁，现在对象头存储的是线程A的LR，线程B从对象头中取出的是线程A的LR，做CAS替换时，怎么和对象头中存储的不一样？什么叫无锁状态值？我们现在讨论的就是这个东西，你来了个糊弄的回答 在 2019-06-12 16:22:48，"scn7th" [email protected] 写道： 我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？ 大致明白了你的意思，你可以看下博主上面的源码，每次CAS的话，走的是Atomic::cmpxchg_ptr这个方法，对于compareValue的话，是构建一个无锁状态的Displaced Mark Word，所以线程A获得轻量级锁，修改了markword，但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的，所以无法cas成功 我理解应该和内存可见性相关，线程A，B几乎在同时得到monitor enter指令，那么此时二者在各自线程中都存有对象O的缓存，此时必然会导致如果线程A的CAS成功，B的CAS失败 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
我理解线程B中存放的是无锁状态时Mark word的拷贝，并不是引用，即使A已经获得锁，修改了Mark word的值，但是线程B中的Mark word拷贝中的值仍然是hashcode，在做CAS时，取出的线程栈桢里的拷贝值（hashcode），与对象的Mark word中的值（此时是线程A的Lock record地址）比较，必然是不一致的。
您好，我理解的轻量级锁加锁过程是： 当进行CAS替换对象头的mark world时，先判断内存中对象头mark world的值 是否等于 无锁状态的mark world，如果等于（即内存中的值 等于 预期值），则把对象头的mark world替换成指向lock record的指针。 当第二个线程到来的时候，获取内存中对象头mark world的值，该值不等于无锁状态的mark world，那么第二个线程就CAS替换失败。 因此，第二个线程无法获得锁，从而无法执行同步代码块。 这样子理解对吗？
如果当前是偏向模式且偏向的线程还在使用锁，那会将锁的mark word改为轻量级锁的状态
我不明白, 偏向线程正在使用锁, 我认为偏向线程还在执行, 另一个线程想要获取锁, 为什么会变成 轻量锁? 应该变成重量锁把?
你觉得他会直接变成重量级锁，而不会经过尝试变成轻量级锁失败后再变成重量级锁吗？偏向线程正在执行的时候，另一个线程想获取锁，发现对象头中存了不是自己的其他线程，线程二怎么会知道线程一还在运行中？他当然是尝试变成轻量级锁，变轻量级锁失败后他才知道此时存在竞争，存在竞争说明线程一还在运行中要不然哪来的竞争，这个时候才会升级重量级锁
在 2019-12-30 21:32:54，"sc-ik" [email protected] 写道：
如果当前是偏向模式且偏向的线程还在使用锁，那会将锁的mark word改为轻量级锁的状态
我不明白, 偏向线程正在使用锁, 我认为偏向线程还在执行, 另一个线程想要获取锁, 为什么会变成 轻量锁? 应该变成重量锁把?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
你还是成功绕开了我的问题，虽然你回答了不少。你回答：但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的 我的疑问一直都是：怎么会不一样？ 传入的无锁状态值从什么地方取来的？难道不是从对象头中取出来？线程A已经获取了锁，现在对象头存储的是线程A的LR，线程B从对象头中取出的是线程A的LR，做CAS替换时，怎么和对象头中存储的不一样？什么叫无锁状态值？我们现在讨论的就是这个东西，你来了个糊弄的回答 在 2019-06-12 16:22:48，"scn7th" [email protected] 写道： 我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？ 大致明白了你的意思，你可以看下博主上面的源码，每次CAS的话，走的是Atomic::cmpxchg_ptr这个方法，对于compareValue的话，是构建一个无锁状态的Displaced Mark Word，所以线程A获得轻量级锁，修改了markword，但当线程B想要获取锁的时候，传入的无锁状态值与本身对象头存储的markword是不一样的，所以无法cas成功 我理解应该和内存可见性相关，线程A，B几乎在同时得到monitor enter指令，那么此时二者在各自线程中都存有对象O的缓存，此时必然会导致如果线程A的CAS成功，B的CAS失败 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
两者不一样的点就在于最后一个bit的不同。线程B通过lockee->mark()->set_unlocked()拿到的markOop，是 ” 线程A设置的markOop | unlocked_value “，也就是线程B获取到的markOop的最后一位是1（无锁状态），而线程A设置的markOop的最后一位是0（轻量级锁状态）。
另外，在轻量级锁加锁中，CAS的原值若不是从对象中取，而是通过调用对象的hashcode()方法获取，那如果对象所属类的hashcode方法被重写了，获取锁的线程在代码块里头更改锁对象的某个属性值了，岂不是，当线程释放完锁之后，锁对象头里的hashcode变成了一个过期的脏数据hashcode值，那以后所有的线程都没法对这个对象加锁了？
你第一个问题是因为原值是markword被setunlock之后的（看源码），而不是直接拿的，所以最后的锁标志位会不同，第二个问题对象头的hashcode（此处学名是idendityhashcode）是不会改变的，重写hashcode方法只是对某些类例如HashMap这种显式调用有用，但是你任何时候都可以通过System.identityHashCode()获取到真正的hashcode。
请问为什么释放锁的时候也需要cas操作呢？为什么会有失败的情况，只有占了锁的线程才会释放啊
因为可能涉及到一个锁膨胀的过程，膨胀时要涉及到创建monitor对象，创建过程中要用到持有轻量级锁的displaced mark wrod 所以要在膨胀的过程中会设置一个INFLATING的状态标志位在对象头中(具体代码在膨胀的文中)来保证能用到 displaced mark wrod，因此CAS操作就是为这个准备的。至于为什么这样做我猜就是为了保证hashcode的一致性吧
咨询个关于自旋的问题，网上好多文章关于轻量级锁都说有个自旋的过程，当自旋尝试失败后才膨胀为重量级锁，但是从源码的角度来看，只要CAS失败就会引起锁膨胀；这块能帮忙解释一下吗？
咨询个关于自旋的问题，网上好多文章关于轻量级锁都说有个自旋的过程，当自旋尝试失败后才膨胀为重量级锁，但是从源码的角度来看，只要CAS失败就会引起锁膨胀；这块能帮忙解释一下吗？
没有自旋这回事，只有重量级锁获取失败才会自旋，网上的文章好多都是错的，我个人认为轻量级锁的意义就是在没有线程争用锁时不用创建monitor
咨询个关于自旋的问题，网上好多文章关于轻量级锁都说有个自旋的过程，当自旋尝试失败后才膨胀为重量级锁，但是从源码的角度来看，只要CAS失败就会引起锁膨胀；这块能帮忙解释一下吗？
没有自旋这回事，只有重量级锁获取失败才会自旋，网上的文章好多都是错的，我个人认为轻量级锁的意义就是在没有线程争用锁时不用创建monitor
没有自旋这回事，也就是说只要有竞争就升级为重量级锁，那和偏向锁没啥区别呀。自旋效率应该更高吧。
咨询个关于自旋的问题，网上好多文章关于轻量级锁都说有个自旋的过程，当自旋尝试失败后才膨胀为重量级锁，但是从源码的角度来看，只要CAS失败就会引起锁膨胀；这块能帮忙解释一下吗？ 没有自旋这回事，只有重量级锁获取失败才会自旋，网上的文章好多都是错的，我个人认为轻量级锁的意义就是在没有线程争用锁时不用创建monitor
没有自旋这回事，也就是说只要有竞争就升级为重量级锁，那和偏向锁没啥区别呀。自旋效率应该更高吧。
是的只要存在竞争就会升级重量级。轻量级锁的存在就是用于线程之间交替获取锁的场景，但是和偏向锁是有区别的啊。一个线程获取偏向锁之后，那么这个锁自然而然就属于这个线程（就算该线程释放了偏向锁也不会改变这把锁偏向这个线程的，这个前提是没有发生过批量重偏向使锁的epoch与其对应class类的epoch不相等）。所以说偏向锁的场景是用于一个线程不断的获取锁，如果把它放在轻量级锁的场景下线程之间交替获取的话会发生偏向锁的撤销的。 效率上来看偏向锁只有在获取的时候进行一次CAS，以后的释放和获取只需要简单的一些判断操作。而轻量级锁的获取和释放都要都要CAS，单纯的看效率还是偏向锁效率高。
咨询个关于自旋的问题，网上好多文章关于轻量级锁都说有个自旋的过程，当自旋尝试失败后才膨胀为重量级锁，但是从源码的角度来看，只要CAS失败就会引起锁膨胀；这块能帮忙解释一下吗？ 没有自旋这回事，只有重量级锁获取失败才会自旋，网上的文章好多都是错的，我个人认为轻量级锁的意义就是在没有线程争用锁时不用创建monitor
没有自旋这回事，也就是说只要有竞争就升级为重量级锁，那和偏向锁没啥区别呀。自旋效率应该更高吧。
是的只要存在竞争就会升级重量级。轻量级锁的存在就是用于线程之间交替获取锁的场景，但是和偏向锁是有区别的啊。一个线程获取偏向锁之后，那么这个锁自然而然就属于这个线程（就算该线程释放了偏向锁也不会改变这把锁偏向这个线程的，这个前提是没有发生过批量重偏向使锁的epoch与其对应class类的epoch不相等）。所以说偏向锁的场景是用于一个线程不断的获取锁，如果把它放在轻量级锁的场景下线程之间交替获取的话会发生偏向锁的撤销的。 效率上来看偏向锁只有在获取的时候进行一次CAS，以后的释放和获取只需要简单的一些判断操作。而轻量级锁的获取和释放都要都要CAS，单纯的看效率还是偏向锁效率高。
好的，谢谢，看了一篇文章说轻量级锁有自旋，还说的挺有道理的，哈哈。。。。。还是源码出真理啊。
咨询个关于自旋的问题，网上好多文章关于轻量级锁都说有个自旋的过程，当自旋尝试失败后才膨胀为重量级锁，但是从源码的角度来看，只要CAS失败就会引起锁膨胀；这块能帮忙解释一下吗？ 没有自旋这回事，只有重量级锁获取失败才会自旋，网上的文章好多都是错的，我个人认为轻量级锁的意义就是在没有线程争用锁时不用创建monitor 没有自旋这回事，也就是说只要有竞争就升级为重量级锁，那和偏向锁没啥区别呀。自旋效率应该更高吧。 是的只要存在竞争就会升级重量级。轻量级锁的存在就是用于线程之间交替获取锁的场景，但是和偏向锁是有区别的啊。一个线程获取偏向锁之后，那么这个锁自然而然就属于这个线程（就算该线程释放了偏向锁也不会改变这把锁偏向这个线程的，这个前提是没有发生过批量重偏向使锁的epoch与其对应class类的epoch不相等）。所以说偏向锁的场景是用于一个线程不断的获取锁，如果把它放在轻量级锁的场景下线程之间交替获取的话会发生偏向锁的撤销的。 效率上来看偏向锁只有在获取的时候进行一次CAS，以后的释放和获取只需要简单的一些判断操作。而轻量级锁的获取和释放都要都要CAS，单纯的看效率还是偏向锁效率高。
好的，谢谢，看了一篇文章说轻量级锁有自旋，还说的挺有道理的，哈哈。。。。。还是源码出真理啊。
对的网上很多都是这样说的，我以前也是这样认为的。估计是被并发编程艺术这本书误导了，把重量级中的锁的自旋看成了轻量级也有
@flying81621 不知道你还有疑惑吗
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
首先A线程通过CAS替换markword替换成功，表明A线程获取了锁，这里应该大家都没问题。 然后是B线程，你的问题取决于B线程是什么时候到达synchronized的。 1.如果它和A几乎同时到达， B就会看到对象头当前处于无锁状态，B就会进行CAS去尝试替换对象的markword，那么A和B之中必定只有一个线程会成功，另一个就是失败的。 2.如果它是在A已经CAS完成后才到达的synchronized，那么B就会看到对象的markword就不是无锁状态，B就会知道当前存在并发，它接下去要做就是锁膨胀流程，这个时候B要把markword改成inflating状态就是全部都是0（同样也是使用CAS），来告诉其他线程正在进行锁膨胀。 不知道我的回答能否解决你心中的疑惑
@flying81621 不知道你还有疑惑吗
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
首先A线程通过CAS替换markword替换成功，表明A线程获取了锁，这里应该大家都没问题。 然后是B线程，你的问题取决于B线程是什么时候到达synchronized的。 1.如果它和A几乎同时到达， B就会看到对象头当前处于无锁状态，B就会进行CAS去尝试替换对象的markword，那么A和B之中必定只有一个线程会成功，另一个就是失败的。 2.如果它是在A已经CAS完成后才到达的synchronized，那么B就会看到对象的markword就不是无锁状态，B就会知道当前存在并发，它接下去要做就是锁膨胀流程，这个时候B要把markword改成inflating状态就是全部都是0（同样也是使用CAS），来告诉其他线程正在进行锁膨胀。 不知道我的回答能否解决你心中的疑惑
为什么轻量级解锁过程要处理线程栈中所有的lock record？假设有两个重入的lock record和一个非重入的lock record，那么第一次解锁过程不应该是释放一个非重入的lock record就行了吗？
我看了很多关于轻量级锁加锁解锁的文章，有个疑问一直没明白，包括看了你这篇。首先说CAS操作，三个要素，原值、期望值、对象，原值一定是从现对象里得到的没疑问吧？线程A加锁，CAS将锁对象对象头替换成指向线程A的Lock Record的地址，在这里，原值：对象mark word中的内容，也就是hashcode，期望值：本线程Lock Record地址，对象：锁对象，在替换成功后我们说线程A获得了锁，OK，线程A开始执行同步代码块，在它执行完之前，线程B来获取锁，发现属于轻量级锁标志，于是CAS替换mark word，此时CAS的原值仍然为为锁对象的mark word吧，而此时锁对象mark word中记录的不再是hashcode而是指向线程A的Lock Record的地址，但是对于CAS它管你对象头存的是什么，现在获取到什么，什么就是原值，于是：原值：对象头中指向线程A中LR的地址，期望值：线程B中LR（目前对他来说，是将锁对象中指向线程A中LR的地址存入本线程LR）的地址，目标对象：锁对象，怎么会CAS不成功？于是现在线程B也获取到锁，两个线程都会在执行同步代码块！这个问题你能解释下吗？希望不要用他就是这样就是那样来解释。另外，轻量级锁解锁时，除了现在锁对象已经变成了重量级锁外，解锁的CAS什么场景下会失败，能举出具体案例吗？
当线程B去尝试获取锁的时候，cas操作的原值不是锁对象的Mark word了，而是线程A的Lock Record的地址了，所以不能成功。
// 修改第一个Lock Record为无锁状态，然后将obj的mark word设置为指向该Lock Record的指针
highest_lock->set_displaced_header(unbiased_prototype);
obj->release_set_mark(markOopDesc::encode(highest_lock));
当线程 A 正在执行同步代码块时，线程 B 尝试获取锁失败，由 JVM 线程来执行锁撤销流程时，这里为什么是设置为无锁状态（看源码是设置最后 1 位为 1）？难道不应该是直接设置为轻量级锁的状态吗？这里我理解不是已经把连锁对象指向 lock record 的指针都设置好了的吗？
// 修改第一个Lock Record为无锁状态，然后将obj的mark word设置为指向该Lock Record的指针 highest_lock->set_displaced_header(unbiased_prototype); obj->release_set_mark(markOopDesc::encode(highest_lock));当线程 A 正在执行同步代码块时，线程 B 尝试获取锁失败，由 JVM 线程来执行锁撤销流程时，这里为什么是设置为无锁状态（看源码是设置最后 1 位为 1）？难道不应该是直接设置为轻量级锁的状态吗？这里我理解不是已经把连锁对象指向 lock record 的指针都设置好了的吗？
看了一下概论的图，轻量级锁指向的 displaced mark word 里的锁状态是 001（无锁）的，但是我没明白这里轻量级锁的状态什么时候改的（🤦♂️