手机网站app制作公司网站seo 工具
Java Synchronized 重量级锁原理深入剖析上(互斥篇)
为什么映入Monitor
处在重量级锁状态时说明有线程没拿到锁需要阻塞等待锁，当拥有锁的线程释放锁后唤醒它继续竞争锁。此处就引入了一个问题：其它线程如何找到被阻塞的线程？我们很容易想到：把阻塞的线程放到多线程共享的(能访问)的列表里。
mark word
偏向锁
轻量级锁
锁重入
// 如果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操作失败则调用monitorenterCALL_VM(InterpreterRuntime::monitorenter(THREAD, entry), handle_exception);}
偏向锁到轻量锁
线程1当前拥有偏向锁对象,线程2是需要竞争到偏向锁。
- 1.线程2来竞争锁对象;
- 2.判断当前对象头是否是偏向锁;
- 3.判断拥有偏向锁的线程1是否还存在;
- 4-1.线程1不存在,直接设置偏向锁标识为0(线程1执行完毕后,不会主动去释放偏向锁);
- 5-1.使用cas替换偏向锁线程ID为线程2,锁不升级，仍为偏向锁;
- 4-2.线程1仍然存在,暂停线程1；
- 5.2.设置锁标志位为00(变为轻量级锁),偏向锁为0;
- 6-2.从线程1的空闲monitor record中读取一条,放至线程1的当前monitor record中;
- 7-2.更新mark word，将mark word指向线程1中monitor record的指针;
- 8-2.继续执行线程1的代码;
- 9-2.线程2自旋来获取锁对象;
轻量级到重量级锁
当获取锁冲突多，时间越长的时候，线程肯定无法继续在这里死等了，所以只好先挂起，然后等前面获取锁的线程释放了锁之后，再开启下一轮的锁竞争，而这种形式就是我们的重量级锁。
