JDK早期，synchronized 叫做重量级锁， 因为申请锁资源必须通过kernel, 系统调用
;hello.asm ;write(int fd, const void *buffer, size_t nbytes) section data msg db "Hello", 0xA len equ $ - msg section .text global _start _start: mov edx, len mov ecx, msg mov ebx, 1 ;文件描述符1 std_out mov eax, 4 ;write函数系统调用号 4 int 0x80 mov ebx, 0 mov eax, 1 ;exit函数系统调用号 int 0x80Compare And Swap(Set) (Compare And Exchange)又被称为： 自旋 / 自旋锁 / 无锁 （无重量锁）
因为经常配合循环操作，直到完成为止，所以泛指一类操作
cas(V, Expected, NewValue) ，变量V，期待值Expected, 修改值NewValue if (v == a){ v = b } else{ try again or fail }CAS操作得到了CPU的原语支持，也就是说CAS操作是CPU指令级别的操作，它中途是不可能被打断的
ABA问题，也就是原来a=1，之后有一个线程把它改成了 a=2，之后又把它改回成1；对于int类型肯定对结果无伤大雅，但是有一些数据结构不行，比如说对象，这可能会导致错误的结果，
解决办法：加一个版本号 (AtomicStampedReference)，在这个对象做任何修改之前就改一下它的版本号，在if判断的时候连同版本号一起检查，比如版本好递增1。当然基础类型简单值不需要版本号，因为它们对结果没有影响。有影响就加一个版本号
CAS操作根本没有用到锁，就完成了锁的功能，但是它付出的代价就是占用CPU的资源，所以在原子类，轻量级锁等地方用到的都是CAS操作
所有的原子类的操作都是使用的Unsafe中的CompareAndSwap方法，这个方法的原理就是上面所说的CAS操作的原理，而这个方法是Unsafe这个类里面的。所以原子类的底层原理就是CAS
unsafe类是用来直接操作JVM里面的内存。比如要修改一个对象的属性，是直接通过偏移量在找到这块内存，直接修改。再比如我们可以调用Unsafe类的allocateMemory来分配指定大小的内存，之前的java可是没有这个功能的。这个只有在c，c++里面有
这个类了解就好，它里面又很多的方法，在JDK8之前，我们这些普通的用户是不能直接使用这个类，这个类是给那些JDK的作者来使用，我们必须通过反射来使用。但在之后的版本，Unsafe类提供了懒汉式的单例，使得我们可以直接拿到它。
AtomicInteger:
public final int incrementAndGet() { for (;;) { int current = get(); int next = current + 1; if (compareAndSet(current, next)) return next; } } public final boolean compareAndSet(int expect, int update) { return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }Unsafe:
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);运用：
package com.mashibing.jol; import sun.misc.Unsafe; import java.lang.reflect.Field; public class T02_TestUnsafe { int i = 0; private static T02_TestUnsafe t = new T02_TestUnsafe(); public static void main(String[] args) throws Exception { //Unsafe unsafe = Unsafe.getUnsafe(); Field unsafeField = Unsafe.class.getDeclaredFields()[0]; unsafeField.setAccessible(true); Unsafe unsafe = (Unsafe) unsafeField.get(null); Field f = T02_TestUnsafe.class.getDeclaredField("i"); long offset = unsafe.objectFieldOffset(f); System.out.println(offset); boolean success = unsafe.compareAndSwapInt(t, offset, 0, 1); System.out.println(success); System.out.println(t.i); //unsafe.compareAndSwapInt() } }jdk8u: unsafe.cpp:
cmpxchg = compare and exchange
UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x)) UnsafeWrapper("Unsafe_CompareAndSwapInt"); oop p = JNIHandles::resolve(obj); jint* addr = (jint *) index_oop_from_field_offset_long(p, offset); return (jint)(Atomic::cmpxchg(x, addr, e)) == e; UNSAFE_ENDjdk8u: atomic_linux_x86.inline.hpp 93行
is_MP = Multi Processor
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) { int mp = os::is_MP(); __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)" : "=a" (exchange_value) : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp) : "cc", "memory"); return exchange_value; }jdk8u: os.hpp is_MP()
static inline bool is_MP() { // During bootstrap if _processor_count is not yet initialized // we claim to be MP as that is safest. If any platform has a // stub generator that might be triggered in this phase and for // which being declared MP when in fact not, is a problem - then // the bootstrap routine for the stub generator needs to check // the processor count directly and leave the bootstrap routine // in place until called after initialization has ocurred. return (_processor_count != 1) || AssumeMP; }jdk8u: atomic_linux_x86.inline.hpp
#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "最终实现：
cmpxchg = cas修改变量值
lock cmpxchg 指令硬件：
lock指令在执行后面指令的时候锁定一个北桥信号
（不采用锁总线的方式）
jdk8u: markOop.hpp
// Bit-format of an object header (most significant first, big endian layout below): // // 32 bits: // -------- // hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object) // size:32 ------------------------------------------>| (CMS free block) // PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object) // // 64 bits: // -------- // unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object) // PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object) // size:64 ----------------------------------------------------->| (CMS free block) // // unused:25 hash:31 -->| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object) // JavaThread*:54 epoch:2 cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && biased object) // narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object) // unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)synchronized(o)
monitorenter moniterexit
InterpreterRuntime:: monitorenter方法
IRT_ENTRY_NO_ASYNC(void, InterpreterRuntime::monitorenter(JavaThread* thread, BasicObjectLock* elem)) #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif if (PrintBiasedLockingStatistics) { Atomic::inc(BiasedLocking::slow_path_entry_count_addr()); } 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); } assert(Universe::heap()->is_in_reserved_or_null(elem->obj()), "must be NULL or an object"); #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif IRT_ENDsynchronizer.cpp
revoke_and_rebias
void ObjectSynchronizer::fast_enter(Handle obj, BasicLock* lock, bool attempt_rebias, TRAPS) { if (UseBiasedLocking) { if (!SafepointSynchronize::is_at_safepoint()) { BiasedLocking::Condition cond = BiasedLocking::revoke_and_rebias(obj, attempt_rebias, THREAD); if (cond == BiasedLocking::BIAS_REVOKED_AND_REBIASED) { return; } } else { assert(!attempt_rebias, "can not rebias toward VM thread"); BiasedLocking::revoke_at_safepoint(obj); } assert(!obj->mark()->has_bias_pattern(), "biases should be revoked by now"); } slow_enter (obj, lock, THREAD) ; } void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) { markOop mark = obj->mark(); assertinflate方法：膨胀为重量级锁
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CS8a4cXB-1603325999235)(.\lock_step.png)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9aeREjvQ-1603325999242)(.\markword-64.png)]
为什么有自旋锁还需要重量级锁？
自旋是消耗CPU资源的，如果锁的时间长，或者自旋线程多，CPU会被大量消耗
重量级锁有等待队列，所有拿不到锁的进入等待队列，不需要消耗CPU资源
偏向锁是否一定比自旋锁效率高？
不一定，在明确知道会有多线程竞争的情况下，偏向锁肯定会涉及锁撤销，这时候直接使用自旋锁
JVM启动过程，会有很多线程竞争（明确），所以默认情况启动时不打开偏向锁，过一段儿时间再打开
new - 偏向锁 - 轻量级锁 （无锁, 自旋锁，自适应自旋）- 重量级锁
synchronized优化的过程和markword息息相关
用markword中最低的三位代表锁状态 其中1位是偏向锁位 两位是普通锁位
Object o = new Object() 锁 = 0 01 无锁态 注意：如果偏向锁打开，默认是匿名偏向状态
o.hashCode() 001 + hashcode
00000001 10101101 00110100 00110110 01011001 00000000 00000000 00000000little endian big endian
00000000 00000000 00000000 01011001 00110110 00110100 10101101 00000000
默认synchronized(o) 00 -> 轻量级锁 默认情况 偏向锁有个时延，默认是4秒 why? 因为JVM虚拟机自己有一些默认启动的线程，里面有好多sync代码，这些sync代码启动时就知道肯定会有竞争，如果使用偏向锁，就会造成偏向锁不断的进行锁撤销和锁升级的操作，效率较低。
-XX:BiasedLockingStartupDelay=0如果设定上述参数 new Object () - > 101 偏向锁 ->线程ID为0 -> Anonymous BiasedLock 打开偏向锁，new出来的对象，默认就是一个可偏向匿名对象101
如果有线程上锁 上偏向锁，指的就是，把markword的线程ID改为自己线程ID的过程 偏向锁不可重偏向 批量偏向 批量撤销
如果有线程竞争 撤销偏向锁，升级轻量级锁 线程在自己的线程栈生成LockRecord ，用CAS操作将markword设置为指向自己这个线程的LR的指针，设置成功者得到锁
如果竞争加剧 竞争加剧：有线程超过10次自旋， -XX:PreBlockSpin， 或者自旋线程数超过CPU核数的一半， 1.6之后，加入自适应自旋 Adapative Self Spinning ， JVM自己控制 升级重量级锁：-> 向操作系统申请资源，linux mutex , CPU从3级-0级系统调用，线程挂起，进入等待队列，等待操作系统的调度，然后再映射回用户空间
(以上实验环境是JDK11，打开就是偏向锁，而JDK8默认对象头是无锁)
偏向锁默认是打开的，但是有一个时延，如果要观察到偏向锁，应该设定参数
如果计算过对象的hashCode，则对象无法进入偏向状态！
轻量级锁重量级锁的hashCode存在与什么地方？
答案：线程栈中，轻量级锁的LR中，或是代表重量级锁的ObjectMonitor的成员中
关于epoch: (不重要)
批量重偏向与批量撤销渊源：从偏向锁的加锁解锁过程中可看出，当只有一个线程反复进入同步块时，偏向锁带来的性能开销基本可以忽略，但是当有其他线程尝试获得锁时，就需要等到safe point时，再将偏向锁撤销为无锁状态或升级为轻量级，会消耗一定的性能，所以在多线程竞争频繁的情况下，偏向锁不仅不能提高性能，还会导致性能下降。于是，就有了批量重偏向与批量撤销的机制。
原理以class为单位，为每个class维护解决场景批量重偏向（bulk rebias）机制是为了解决：一个线程创建了大量对象并执行了初始的同步操作，后来另一个线程也来将这些对象作为锁对象进行操作，这样会导致大量的偏向锁撤销操作。批量撤销（bulk revoke）机制是为了解决：在明显多线程竞争剧烈的场景下使用偏向锁是不合适的。
一个偏向锁撤销计数器，每一次该class的对象发生偏向撤销操作时，该计数器+1，当这个值达到重偏向阈值（默认20）时，JVM就认为该class的偏向锁有问题，因此会进行批量重偏向。每个class对象会有一个对应的epoch字段，每个处于偏向锁状态对象的Mark Word中也有该字段，其初始值为创建该对象时class中的epoch的值。每次发生批量重偏向时，就将该值+1，同时遍历JVM中所有线程的栈，找到该class所有正处于加锁状态的偏向锁，将其epoch字段改为新值。下次获得锁时，发现当前对象的epoch值和class的epoch不相等，那就算当前已经偏向了其他线程，也不会执行撤销操作，而是直接通过CAS操作将其Mark Word的Thread Id 改成当前线程Id。当达到重偏向阈值后，假设该class计数器继续增长，当其达到批量撤销的阈值后（默认40），JVM就认为该class的使用场景存在多线程竞争，会标记该class为不可偏向，之后，对于该class的锁，直接走轻量级锁的逻辑。
没错，我就是厕所所长
加锁，指的是锁定对象
锁升级的过程
JDK较早的版本 OS的资源 互斥量 用户态 -> 内核态的转换 重量级 效率比较低
现代版本进行了优化
无锁 - 偏向锁 -轻量级锁（自旋锁）-重量级锁
偏向锁 - markword 上记录当前线程指针，下次同一个线程加锁的时候，不需要争用，只需要判断线程指针是否同一个，所以，偏向锁，偏向加锁的第一个线程 。hashCode备份在线程栈上 线程销毁，锁降级为无锁
有争用 - 锁升级为轻量级锁 - 每个线程有自己的LockRecord在自己的线程栈上，用CAS去争用markword的LR的指针，指针指向哪个线程的LR，哪个线程就拥有锁
自旋超过10次，升级为重量级锁 - 如果太多线程自旋 CPU消耗过大，不如升级为重量级锁，进入等待队列（不消耗CPU）-XX:PreBlockSpin
自旋锁在 JDK1.4.2 中引入，使用 -XX:+UseSpinning 来开启。JDK 6 中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。
自适应自旋锁意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。
偏向锁由于有锁撤销的过程revoke，会消耗系统资源，所以，在锁争用特别激烈的时候，用偏向锁未必效率高。还不如直接使用轻量级锁。
sychronized是可重入锁
重入次数必须记录，因为要解锁几次必须得对应
偏向锁 自旋锁 -> 线程栈 -> LR + 1
重量级锁 -> ? ObjectMonitor字段上
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly T
C1 Compile Level 1 (一级优化)
C2 Compile Level 2 (二级优化)
找到m() n()方法的汇编码，会看到 lock comxchg …指令
我们都知道 StringBuffer 是线程安全的，因为它的关键方法都是被 synchronized 修饰过的，但我们看上面这段代码，我们会发现，sb 这个引用只会在 add 方法中使用，不可能被其它线程引用（因为是局部变量，栈私有），因此 sb 是不可能共享的资源，JVM 会自动消除 StringBuffer 对象内部的锁。
JVM 会检测到这样一连串的操作都对同一个对象加锁（while 循环内 100 次执行 append，没有锁粗化的就要进行 100 次加锁/解锁），此时 JVM 就会将加锁的范围粗化到这一连串的操作的外部（比如 while 虚幻体外），使得这一连串操作只需要加一次锁即可。
http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html
