synchronized底层实现

java里synchronized锁分为方法锁和代码块锁两种

• 静态方法默认以class对象作为锁，普通方法默认以对象实例作为锁。

• 方法锁和代码块锁jvm底层实现有一些区别,
  a) 代码块同步是使用monitorenter和monitorexit指令实现，而方法同步是使用另外一种方式实现的，细节在JVM规范里并没有详细说明，但是方法的同步同样可以使用这两个指令来实现。monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处， JVM要保证每个monitorenter必须有对应的monitorexit与之配对。
  b) 而synchronized方法则会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法，而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1，表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。

• 由于monitor指令底层都依赖操作系统的mutex lock实现，由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的；然而在现实中的大部分情况下，同步方法是运行在单线程环境。所以jdk1.6之后引入轻量锁，偏向锁等优化手段。

java对象在内存中分布

• 对象头

锁，gc标记gc年龄等信息都存储在这一块！！！！！！当出于有锁状态时数据格式如下，无所状态很简单，只有dc年龄和标记和无锁等信息。

Paste_Image.png

• 实例数据
• 对齐填充区域

按重量级别划分的几种锁机制

!!!!!!!偏，轻，重锁，分别解决三个问题，只有一个线程进入临界区，多个线程交替进入临界区，多线程同时进入临界区。!!!!!!!!

• 偏向锁

线程第一次进入临界区时，记录下当前线程id以及标记当前对象锁状态为偏向状态，只要没有其他线程来访问这个临界区，这个临界区的锁将会永远被这个线程持有。(所以，偏向锁倾向于临界区永远只有某一条线程访问，不是说同时只有一条线程访问，是永远只有唯一的一条(如id为5的那一条)访问)。

当有另外一条线程进入时，偏向锁将会被打破直接升级(膨胀)到轻量级锁(<b>这里另外的线程进入时，之前的偏向线程如果正在执行，那么升级到轻量级锁后又会马上升级到重量级锁，以为存在了两条竞争线程。如果之前的偏向线程没有正在执行，就升级到轻量级锁就好了</b>)，升级到轻量级锁时必须等到当前拥有偏向锁的线程执行完同步代码块，并暂停该线程。

如果确定自身代码基本都会有很多线程进入同一临界区，大可禁用偏向锁 -XX:-UseBiasedLocking 。java6，7都默认开启，8应该也默认开启了，待确认！！

• 轻量锁

轻量锁也只能同时只有一条线程竞争临界区。当多条线程交替执行临界区的时候最适合轻量锁，因为轻量锁使用cas来获取锁，不会阻塞挂起线程发生线程上下文切换。
当有多条线程同时cas时，轻量锁将会提升(膨胀)为重量级悲观锁。

膨胀的时机可能在两个时间点：
a) 另外一个线程B通过cas获取锁失败时(发现锁存在了竞争)，此时线程B将会自旋一段时间(这里自旋结束时其实所已经是重量级锁了)，并升级锁到重量级锁
b) 拥有锁的线程A释放锁时，尝试cas更新displaced header,失败直接膨胀！

// If the object is stack-locked by the current thread, try to
  // swing the displaced header from the box back to the mark.
 // 只有当前线程可以cas更新成功，所以这里更新失败也说明锁存在竞争，将会膨胀
  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;
     }
  }

  ObjectSynchronizer::inflate(THREAD, object)->exit (THREAD) ;

• 重量级锁

直接调用操作系统的互斥锁，首先阻塞线程，有极大的上下文切换开销。具体加锁流程图：

a) ContentionList
所有后续进来排队获取锁的线程都将以cas的方式添加到头结点上。
b) EntryList
有资格去竞争锁的线程队列。由当前owner线程释放锁时从ContentionList队尾弹出元素添加进来（这样避免了ContentionList上的尾部并发竞争）。另外WaitSet中阻塞的线程被唤醒后也会加入到EntryList队列。
c) OnDeck
owner线程释放锁后会从EntryList头部拿出一条线程作为ondeck线程（ondeck线程得到真正可以竞争锁的权利，不是owner线程直接把锁交给ondeck线程，这里不怎么好理解好处，个人觉得是对一条线程来说，竞争锁等过程还是比较复杂，不应该对另外一条线程加锁过程绑定在当前线程上）
d) owner
ondeck线程竞争成功后成为当前锁持有者线程（！！这里没太明白，只有ondeck一条线程，还会存在竞争失败的情况吗？？？？这里的失败是指与竞争无关的其他异常情况导致的吗？？？？）
e) WaitSet
当前owner线程如果被wait方法阻塞，将会被转移到waitset。

可以看到，wait阻塞被notify唤醒后仅仅是在entrylist而已，相比其他刚进来竞争锁的线程领先了一步优势，但是并不一定能竞争到锁~~~~