一、synchronized简介
synchronized是Java中的关键字，是一种同步锁。在多线程编程中，有可能会呈现多个线程同时争抢同一个共享资源的状况，这个资源个别被称为临界资源。这种共享资源能够被多个线程同时拜访，且又能够同时被多个线程批改，然而线程的执行是须要CPU的资源调度，其过程是不可控的，所以须要采纳一种同步机制来管制对共享资源的拜访，于是线程同步锁——synchronized就应运而生了。
二、如何解决线程并发平安问题
多线程并发读写访问临界资源的状况下，是会存在线程平安问题的，能够采纳的同步互斥拜访的形式，就是在同一时刻，只能有同一个线程可能拜访到临界资源。当多个线程执行同一个办法时，该办法外部的局部变量并不是临界资源，因为这些局部变量会在类加载的时候存在每个线程的公有栈的局部变量表中，因而不属于共享资源，所有不会导致线程平安问题。
三、synchronized用法
synchronized关键字最次要有以下3种应用形式：
- 润饰类办法，作用于以后类加锁，如果多个线程不同对象拜访该办法，则无奈保障同步。
- 润饰静态方法，作用于以后类对象加锁，进入同步代码前要取得以后类对象的锁，锁的是蕴含这个办法的类，也就是类对象，这样如果多个线程不同对象拜访该静态方法，也是能够保障同步的。
- 润饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要取得给定对象的锁。
四、Synchronized原理剖析
能够先通过一个简略的案例看一下同步代码块：
public class SynchTestDemo { public void print() { synchronized ("得物") { System.out.println("Hello World"); } } }synchronized属于Java关键字，没方法间接看到其底层源码，所以只能通过class文件进行反汇编。
先通过javac SynchTestDemo.java指令间接SynchTestDemo.java文件编译成SynchTestDemo.class文件；再通过javap -v SynchTestDemo.class指令再对SynchTestDemo.class文件进行反汇编，能够失去上面的字节码指令：
这些反编译的字节码指令这里就不具体解释了，对照着JVM指令手册也能看懂是什么意思。通过上图反编译的后果能够看出，monitorexit指令实际上是执行了两次，第一次是失常状况下开释锁，第二次为产生异常情况时开释锁，这样做的目标在于保障线程不死锁。
monitorenter
首先能够看一下JVM标准中对于monitorenter的形容：
翻译过去就是：任何一个对象都有一个monitor与其相关联，当且有一个monitor被持有后，它将处于锁定的状态，其余线程无奈来获取该monitor。当JVM执行某个线程的某个办法外部的monitorenter时，他会尝试去获取以后对应的monitor的所有权。其过程如下：
- 如果monitor的进入数为0，则该线程进入monitor，而后将进入数设置为1，该线程即为monitor的所有者；
- 如果线程曾经占有该monitor，只是从新进入，则进入monitor的进入数加1；
- 如果其余线程曾经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再从新尝试获取monitor的所有权；
monitorexit
也能够先看一下JVM标准中对monitorexit的形容：
翻译过去就是：
- 能执行monitorexit指令的线程肯定是领有以后对象的monitor的所有权的线程；
- 执行monitorexit时会将monitor的进入数减1。当monitor的进入数减为0时，以后线程退出monitor，不再领有monitor的所有权，此时其余被这个monitor阻塞的线程能够尝试去获取这个monitor的所有权；
synchronized关键字被编译成字节码后会被翻译成monitorenter和monitorexit两条指令别离在同步块逻辑代码的起始地位与完结地位，如下图所示：
每个同步对象都有一个本人的Monitor(监视器锁)，加锁过程如下图所示：
通过下面的形容能够看出synchronized的实现原理：synchronized的底层理论是通过一个monitor对象来实现的，其实wait/notify办法也是依赖于monitor对象来实现的，这就是为什么只有在同步代码块或者办法中能力调用该办法，否则就会抛出出java.lang.IllegalMonitorStateException的异样的起因。
上面能够再通过一个简略的案例看一下同步办法：
public class SynchTestDemo { public synchronized void print() { System.out.println("Hello World"); } }与下面同理能够查看到，该办法的字节码指令：
从字节码反编译的能够看出，同步办法并没有通过指令monitorenter和monitorexit来实现的，然而绝对于一般办法来说，其常量池多了了 ACC_SYNCHRONIZED 标示符。JVM理论就是依据该标识符来实现办法的同步的。
当办法被调用时，会查看ACC_SYNCHRONIZED标记是否被设置，若被设置，线程会先获取monitor，获取胜利能力执行办法体，办法执行实现后会再次开释monitor。在办法执行期间，其余线程都无奈取得同一个monitor对象。
其实两种同步形式从实质上看是没有区别的，两个指令的执行都是JVM调用操作系统的互斥原语mutex来实现的，被阻塞的线程会被挂起、期待从新调度，会导致线程在“用户态”和“内核态”进行切换，就会对性能有很大的影响。
五、什么是monitor？
monitor通常被形容为一个对象，能够将其了解为一个同步工具，或者能够了解为一种同步机制。所有的Java对象自打new进去的时候就自带了一把锁，就是monitor锁，也就是对象锁，存在于对象头（Mark Word），锁标识位为10，指针指向的是monitor对象起始地址。在Java虚拟机（HotSpot）中，Monitor是由其底层理论是由C++对象ObjectMonitor实现的:
ObjectMonitor() { _header = NULL; _count = 0; //用来记录该线程获取锁的次数 _waiters = 0， _recursions = 0; // 线程的重入次数 _object = NULL; // 存储该monitor的对象 _owner = NULL; // 标识领有该monitor的线程 _WaitSet = NULL; // 处于wait状态的线程，会被退出到_WaitSet _WaitSetLock = 0 ; _Responsible = NULL; _succ = NULL; _cxq = NULL; // 多线程竞争锁时的单向队列 FreeNext = NULL; _EntryList = NULL; // 处于期待锁block状态的线程，会被退出到该列表 _SpinFreq = 0; _SpinClock = 0; OwnerIsThread = 0;}- _owner：初始时为NULL。当有线程占有该monitor时，owner标记为该线程的惟一标识。当线程开释monitor时，owner又复原为NULL。owner是一个临界资源，JVM是通过CAS操作来保障其线程平安的;
- _cxq：竞争队列，所有申请锁的线程首先会被放在这个队列中（单向链接）。cxq是一个临界资源，JVM通过CAS原子指令来批改cxq队列。批改前cxq的旧值填入了node的next字段，_cxq指向新值（新线程）。因而_cxq是一个后进先出的stack（栈）;
- _EntryList：_cxq队列中有资格成为候选资源的线程会被挪动到该队列中;
- _WaitSet：因为调用wait办法而被阻塞的线程会被放在该队列中。
举个例子具体分析一下_cxq队列与_EntryList队列的区别：
public void print() throws InterruptedException { synchronized (obj) { System.out.println("Hello World"); //obj.wait(); } }若多线程执行下面这段代码，刚开始t1线程第一次进同步代码块，可能取得锁，之后马上又有一个t2线程也筹备执行这段代码，t2线程是没有抢到锁的，t2这个线程就会进入_cxq这个队列进行期待，此时又有一个线程t3筹备执行这段代码，t3当然也会没有抢到这个锁，那么t3也就会进入_cxq进行期待。接着，t1线程执行完同步代码块把锁开释了，这个时候锁是有可能被t1、t2、t3中的任何一个线程抢到的。如果此时又被t1线程给抢到了，那么上次曾经进入_cxq这个队列进行期待的线程t2、t3就会进入_EntryList进行期待，若此时来了个t4线程，t4线程没有抢到锁资源后，还是会先进入_cxq进行期待。
上面具体分析一下_WaitSet队列与_EntryList队列：
每个object的对象里 markOop->monitor() 里能够保留ObjectMonitor的对象。ObjectWaiter 对象里寄存thread(线程对象) 和unpark的线程, 每一个期待锁的线程都会有一个ObjectWaiter对象，而objectwaiter是个双向链表构造的对象。
联合上图monitor的结构图能够剖析出，当线程的拥有者执行完线程后，会开释锁，此时有可能是阻塞状态的线程去抢到锁，也有可能是处于期待状态的线程被唤醒抢到了锁。在JVM中每个期待锁的线程都会被封装成ObjectMonitor对象，_owner标识领有该monitor的线程，而_EntryList和_WaitSet就是用来保留ObjectWaiter对象列表的，_EntryList和_WaitSet最大的区别在于前者是用来寄存期待锁block状态的线程，后者是用来寄存处于wait状态的线程。
当多个线程同时拜访同一段代码时：
- 首先会进入_EntryList汇合每当线程获取到对象的monitor后，会将monitor中的_ower变成设置为以后线程，同时会将monitor中的计数器_count加1
- 若线程调用wait()办法时，将开释以后持有的monitor对象，将_ower设置为null，_count减1，同时该线程进入_WaitSet中期待被唤醒
<!---->
- 若以后线程执行结束，也将开释monitor锁，并将_count值还原，以便于其余线程获取锁
monitor对象存在于每个Java对象的对象头（Mark Word）中，所以Java中任何对象都能够作为锁，因为notify/notifyAll/wait等办法会应用到monitor锁对象，所以必须在同步代码块中应用。多线程状况下，线程须要同时拜访临界资源，监视器monitor能够确保共享数据在同一时刻只会有一个线程在拜访。
那么问题来了，synchronized是对象锁，加锁就是加在对象上，那对象时如何记录锁的状态的呢？答案就是锁的状态是记录在每个对象的对象头（Mark Word）中的，那什么是对象头呢？
六、什么是对象头
在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。如下图所示：
对象头又包含两局部信息，第一局部用于存储对象本身的运行时数据（Mark Word），如HashCode、GC分代年龄、锁状态标记、线程持有的锁、偏差线程ID、偏差工夫戳等。对象头的另外一部分是类型指针（Klass pointer），即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
Class<? extends SynchTestDemo> synchClass = synchTestDemo.getClass();
值得注意的是：类元信息存在于办法区，类元信息有区别与堆中的synchClass字节码对象，synchClass能够了解为类加载实现后，JVM将类的信息存在堆中，而后应用反射去拜访其全副信息(包含函数和字段)，然而在JVM外部大多数对象都是应用C++代码实现的，对于JVM外部如果须要类信息，JVM就会通过对象头的类型指针去拿办法区中类元信息的数据。
实例数据：寄存类的属性数据信息，包含父类的属性信息。
对齐填充：因为虚拟机要求 对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐。
上面能够看一下对像头的构造：
在32位虚拟机下，Mark Word是32bit大小的，其存储构造如下：
在64位虚拟机下，Mark Word是64bit大小的，其存储构造如下：
当初虚拟机根本是64位的，而64位的对象头有点节约空间，JVM默认会开启指针压缩，所以基本上也是按32位的模式记录对象头的。也能够通过上面参数进行管制JVM开启和敞开指针压缩：
开启压缩指针(-XX:+UseCompressedOops) 敞开压缩指针(-XX:-UseCompressedOops)
那为什么JVM须要默认开启指针压缩呢？起因在于在对象头上类元信息指针Klass pointer在32位JVM虚拟机中用4个字节存储，然而到了64位JVM虚拟机中Klass pointer用的就是8个字节来存储，一些对象在32位虚拟机用的也是4字节来存储，到了64位机器用的都是8字节来存储了，一个工程项目中有成千上万的对象，假使每个对象都用8字节来寄存的话，那这些对象无形中就会减少很多空间，导致堆的压力就会很大，堆很容易就会满了，而后就会更容易的触发GC，那指针压缩的最次要的作用就是压缩每个对象内存地址的大小，那么同样堆内存大小就能够放更多的对象。
这里刚好能够再说一个额定的小知识点：对象头中有4个字节用于寄存对象分代年龄的，4个字节就是2的四次方等于16，其范畴就是0~15，所以也就很好了解对象在GC的时候，JVM对象由年老代进入老年代的默认分代年龄是15了。
七、synchronized锁的优化
操作系统分为“用户空间”和“内核空间”，JVM是运行在“用户态”的，jdk1.6之前，在应用synchronized锁时须要调用底层的操作系统实现，其底层monitor会阻塞和唤醒线程，线程的阻塞和唤醒须要CPU从“用户态”转为“内核态”，频繁的阻塞和唤醒对CPU来说是一件累赘很重的工作，这些操作给零碎的并发性能 带来了很大的压力。同这个时候CPU就须要从“用户态”切向“内核态”，在这个过程中就十分损耗性能而且效率非常低，所以说jdk1.6之前的synchronized是重量级锁。如下图所示：
而后有位纽约州立大学的传授叫Doug Lea看到jdk自带的synchronized性能比拟低，于是他利用纯Java语言实现了基于AQS的ReentrantLock锁（底层当然也调用了底层的语言），如下图所示，能够说ReentrantLock锁的呈现齐全是为了补救synchronized锁的各种有余。
因为synchronized锁性能严重不足，所以oracle官网在jdk1.6之后对synchronized锁进行了降级，如上图所示的锁降级的整个过程。所以就有了以下的这些名词：
无锁
无锁没有对资源进行锁定，所有的线程都能拜访并批改同一个资源，但同时只有一个线程能批改胜利，其底层是通过CAS实现的。无锁无奈全方位代替有锁，但无锁在某些场合下的性能是十分高的。
偏差锁（无锁 -> 偏差锁）
偏差锁的“偏”，就是偏心的“偏”、偏袒的“偏”，它的意思是这个锁会偏差于第一个取得它的线程，会在对象头存储锁偏差的线程ID，当前该线程进入和退出同步块时只须要查看是否为偏差锁、锁标记位以及 ThreadID即可。
一开始无锁状态，JVM会默认开启“匿名”偏差的一个状态，就是一开始线程还未持有锁的时候，就事后设置一个匿名偏差锁，等一个线程持有锁之后，就会利用CAS操作将线程ID设置到对象的mark word 的高23位上【32位虚拟机】，下次线程若再次争抢锁资源的时，多线程竞争的状况下尽量减少不必要的轻量级锁执行门路，因为轻量级锁的获取及开释依赖屡次CAS原子指令，只须要在置换ThreadID的时候依赖一次CAS原子指令即可。
轻量级锁（偏差锁 -> 轻量锁）
当线程交替执行同步代码块时，且竞争不强烈的状况下，偏差锁就会降级为轻量级锁。在大多数状况下，锁总是由同一线程屡次取得，不存在多线程竞争，所以呈现了偏差锁。其指标就是在只有一个线程执行同步代码块时可能进步性能。当一个线程拜访同步代码块并获取锁时，会在Mark Word里存储锁偏差的线程ID。在线程进入和退出同步块时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向以后线程的偏差锁。引入偏差锁是为了在无多线程竞争的状况下尽量减少不必要的轻量级锁执行门路，因为轻量级锁的获取及开释依赖屡次CAS原子指令，而偏差锁只须要在置换ThreadID的时候依赖一次CAS原子指令即可。撤销偏差锁后复原到无锁（标记位为“01”）或轻量级锁（标记位为“00”）的状态。
自旋锁
在很多场景下，共享资源的锁定状态只会继续很短的一段时间，为了这段时间阻塞和唤醒线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，咱们就能够让前面申请锁的那个线程“稍等一下”，但不放弃处理器的执行工夫，看看持有锁的线程是否很快就会开释锁。为了让线程期待，咱们只需让线程执行一个忙循环(自旋) , 这就是自旋锁。
当一个线程t1、t2共事争抢同一把锁时，如果t1线程先抢到锁，锁不会立马升级成重量级锁，此时t2线程会自旋几次（默认自旋次数是10次，能够应用参数-XX : PreBlockSpin来更改），若t2自旋超过了最大自旋次数，那么t2就会当应用传统的形式去挂起线程了，锁也降级为重量级锁了。
自旋的期待不能代替阻塞，暂且不说对处理器数量的要求必须要两个核，自旋期待自身尽管防止了线程切换的开销，但它是要占用处理器工夫的，所以如果锁被占用的工夫很短，自旋等 待的成果就会十分好，如果锁被占用的工夫很长，那自旋的线程只会耗费处理器资源，而不会做任何有用的工作，反而会带来性能上的节约。
自旋锁在jdk1.4中就曾经引入，只不过默认是敞开的，能够应用-XX:+UseSpinning参数来开启，在jdk1.6之后自旋锁就曾经默认是关上状态了。
重量级锁
降级为重量级锁时，锁标记的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时期待锁的线程都会进入阻塞状态。
锁打消
锁打消是指虚拟机即时编译器（JIT）在运行时，对一些代码上要求同步，然而被检测到不可能存在共享数据竞争的锁进行打消。锁打消的次要断定根据来源于逃逸剖析的数据反对，如果判断在一段代码中，堆上的所有数据都不会逃逸进来从而被其余线程拜访到，那就能够把它们当做栈上数据看待，认为它们是线程公有的，同步加锁天然就毋庸进行。
public class SynchRemoveDemo { public static void main(String[] args) { stringContact("AA", "BB", "CC"); } public static String stringContact(String s1, String s2, String s3) { StringBuffer sb = new StringBuffer(); return sb.append(s1).append(s2).append(s3).toString(); }}//append()办法源码@Overridepublic synchronized StringBuffer append(String str) { toStringCache = null; super.append(str); return this;}StringBuffer的append()是一个同步办法，锁就是this也就是sb对象。虚拟机发现它的动静作用域被限度在stringContact()办法外部。也就是说, sb对象的援用永远不会“逃逸”到stringContact()办法之外，其余线程无法访问到它，因而，尽管这里有锁，然而能够被平安地打消掉，在即时编译之后，这段代码就会疏忽掉所有的同步而间接执行了。
这里顺便说一个小的JVM知识点——“对象的逃逸剖析”：就是剖析对象动静作用域，当一个对象在办法中被定义后，它可能被内部办法所援用，例如作为调用参数传递到其余中央中。JVM通过逃逸剖析确定该对象不会被内部拜访。如果不会逃逸能够将该对象优先在栈上分配内存，这样该对象所占用的内存空间就能够随栈帧出栈而销毁，就加重了垃圾回收的压力。下面sb对象的就是不会逃逸出办法stringContact()，所以sb对象有可能优先调配在线程栈中，只是有可能哟，这里点到为止，须要理解能够自行学习哟～
锁粗化
JVM会探测到一连串细小的操作都应用同一个对象加锁，将同步代码块的范畴放大，放到这串操作的里面，这样只须要加一次锁即可。能够通过上面的例子来看一下：
public class SynchDemo { public static void main(String[] args) { StringBuffer sb = new StringBuffer(); for (int i = 0; i < 50; i++) { sb.append("AA"); } System.out.println(sb.toString()); }}//append()办法源码@Overridepublic synchronized StringBuffer append(String str) { toStringCache = null; super.append(str); return this;}StringBuffer的append()是一个同步办法，通过下面的代码能够看出，每次循环都要给append()办法加锁，这时零碎会通过判断将其批改为上面这种,间接将原append()办法的synchronized的锁给去掉间接加在了for循环外。
public class SynchDemo { public static void main(String[] args) { StringBuffer sb = new StringBuffer(); synchronized(sb){ for (int i = 0; i < 50; i++) { sb.append("AA"); } } System.out.println(sb.toString()); }}//append()办法源码@Overridepublic StringBuffer append(String str) { toStringCache = null; super.append(str); return this;}八、通过对象头剖析锁降级过程
能够通过对象头剖析工具察看一下锁降级时对象头的变动：运行时对象头锁状态剖析工具JOL，是OpenJDK开源工具包，引入下方maven依赖
<dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol‐core</artifactId> <version>0.10</version></dependency>察看无锁状态下的对象头【无锁状态】：
public static void main(String[] args) throws InterruptedException { Object object = new Object(); System.out.println(ClassLayout.parseInstance(object).toPrintable()); }运行后果：
java.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1) 第一行：对象头MarkWord 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 第二行：对象头MarkWord 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 第三行：klass Pointer 12 4 (loss due to the next object alignment) 第四行：对齐填充Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes total这里先具体解释一下打印后果，前面就不做详细分析了：
OFFSET ： 内存地址偏移量
SIZE ： 本条信息对应的字节大小
Instance size: 16 bytes ：本次new出的Object对象的大小
因为以后所应用的的机器是64位操作系统的机器，所以前两行代表的就是对象头MarkWord，曾经在上述运行后果中标出，刚好是8字节，每个字节8位，刚好是64位；由上文中32位对象头与64位对象头的位数比照可知，剖析对象头锁降级状况看第一行的对象头即可。
第三行指的是类型指针（上文中有说过，指向的是办法区的类元信息），曾经在上述运行后果中标出，Klass Pointer在64位机器默认是8字节，这里因为指针压缩的起因以后是4字节。
第四行指的是对齐填充，有的时候有有的时候没有，JVM外部须要保障对象大小是8个字节的整数倍，实际上计算机底层通过大量计算得出对象时8字节的整数倍能够进步对象存储的效率。
能够察看到本次new出的Object对象的大小理论只有12字节，这里对象填充为其填充了4个字节，就是为了让Object对象大小为16字节是8字节的整数倍。
JVM采纳的是小端模式，须要现将其转换成大端模式，具体转换如下图所示：
能够看出一开始对象没有加锁，通过最初三位的“001”也能察看到，前25位代表hashcode，那这里为什么前25位是0呢？其实hashcode是通过C语言相似于“懒加载”的形式获取到的，所以看到该对象的高25位并没有hashcode。
察看有锁无竞争状态下的对象头【无锁->偏差锁】：
public static void main(String[] args) throws InterruptedException { Object object = new Object(); System.out.println(ClassLayout.parseInstance(object).toPrintable()); synchronized (object){ System.out.println(ClassLayout.parseInstance(o).toPrintable()); } }运行后果（JVM默认小端模式）：
java.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1) 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 90 39 62 05 (10010000 00111001 01100010 00000101) (90323344) 4 4 (object header) 00 70 00 00 (00000000 01110000 00000000 00000000) (28672) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes total运行后果剖析：
通过运行后果能够看到，先打印进去的是一个“001”无锁的状态，然而后打印进去的“000”并不是偏差锁的状态，查下面的表能够发现“000”间接就是轻量级锁的状态了。JVM启动的时候外部实际上也是有很多个线程在执行synchronized，JVM就是为了防止无畏的锁降级过程（偏差锁->轻量级锁->重量级锁）带来的性能开销，所以JVM默认状态下会提早启动偏差锁。只有将代码后面加个延迟时间即可察看到偏差锁：
public static void main(String[] args) throws InterruptedException { TimeUnit.SECONDS.sleep(6); Object o = new Object(); System.out.println(ClassLayout.parseInstance(o).toPrintable()); synchronized (o){ System.out.println(ClassLayout.parseInstance(o).toPrintable()); }}运行后果（JVM默认小端模式）：
java.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5) 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 90 80 de (00000101 10010000 10000000 11011110) (-561999867) 4 4 (object header) b2 7f 00 00 (10110010 01111111 00000000 00000000) (32690) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes total对未开启偏差锁与开启偏差锁的运行后果剖析：
未开启偏差锁（大端模式），没加锁：00000000 00000000 00000000 00000001开启偏差锁（大端模式），没加锁 ：00000000 00000000 00000000 00000101开启偏差锁（大端模式），加锁 ：11011110 10000000 10010000 00000101开启偏差锁之后的无锁状态，会加上一个偏差锁，叫匿名偏差（可偏差状态），示意该对象锁是能够加偏差锁的，从高23位的23个0能够看出临时还没有偏差任何一个线程，代表曾经做好了偏差的筹备，就等着接下来的某个线程能拿到就间接利用CAS操作把线程id记录在高23位的地位。
察看有锁有竞争状态下的对象头【偏差锁->轻量级锁】：
public static void main(String[] args) throws InterruptedException { Thread.sleep(5000); Object object = new Object(); //main线程 System.out.println(ClassLayout.parseInstance(object).toPrintable()); //线程t1 new Thread(() -> { synchronized (object) { System.out.println(ClassLayout.parseInstance(object).toPrintable()); } },"t1").start(); Thread.sleep(2000); //main线程 System.out.println(ClassLayout.parseInstance(object).toPrintable()); //线程t2 new Thread(() -> { synchronized (object) { System.out.println(ClassLayout.parseInstance(object).toPrintable()); } },"t2").start(); }运行后果（JVM默认小端模式）：
java.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5) //main线程打印 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 90 94 2d (00000101 10010000 10010100 00101101) (764710917) //t1线程打印 4 4 (object header) c9 7f 00 00 (11001001 01111111 00000000 00000000) (32713) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 90 94 2d (00000101 10010000 10010100 00101101) (764710917) //main线程打印 4 4 (object header) c9 7f 00 00 (11001001 01111111 00000000 00000000) (32713) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 08 a9 d5 07 (00001000 10101001 11010101 00000111) (131442952) //t2线程打印 4 4 (object header) 00 70 00 00 (00000000 01110000 00000000 00000000) (28672) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes total运行后果剖析：
一开始main线程打印出的object对象头能够看出是匿名偏差；
接着线程t1打印了object对象头，能够与第一个打印进去的对象头比照不难发现t1打印的也是偏差锁，然而t1打印的对象头曾经把t1的线程id记录在了其对应的23位；
程序再次回到main线程，其还是打印进去刚刚t1的对象头数据，也就是说偏差锁一旦偏差了某个线程后，如果线程不能从新偏差的话，那么这个偏差锁还是会始终记录着之前偏差的那个线程的对象头状态；
接着线程t2又开始打印了object对象头，能够看出最初一次打印曾经升级成了轻量级锁，因为这里曾经存在两个线程t1、t2交替进入了object对象锁的同步代码块，并且锁的不强烈竞争，所以锁曾经升级成了轻量级锁。
察看无锁升级成重量级锁状态下的对象头的整个过程【无锁->重量级锁】：
public static void main(String[] args) throws InterruptedException { sleep(5000); Object object = new Object(); System.out.println(ClassLayout.parseInstance(object).toPrintable()); new Thread(()->{ synchronized (object) { System.out.println(ClassLayout.parseInstance(object).toPrintable()); //缩短锁的开释，造成锁的竞争 try { sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } } },"t0").start(); sleep(5000); new Thread(() -> { synchronized (object) { System.out.println(ClassLayout.parseInstance(object).toPrintable()); //缩短锁的开释，造成锁的竞争 try { sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } } },"t1").start(); new Thread(() -> { synchronized (object) { System.out.println(ClassLayout.parseInstance(object).toPrintable()); try { sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } },"t2").start(); }运行后果：
java.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 00 00 00 (00000101 00000000 00000000 00000000) (5) //main线程打印 4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 05 d8 8f ef (00000101 11011000 10001111 11101111) (-275785723) //t0线程打印 4 4 (object header) ce 7f 00 00 (11001110 01111111 00000000 00000000) (32718) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 00 e9 a9 09 (00000000 11101001 10101001 00001001) (162130176) //t1线程打印 4 4 (object header) ce 7f 00 00 (11001110 01111111 00000000 00000000) (32718) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes totaljava.lang.Object object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 4 (object header) 0a d8 80 f0 (00001010 11011000 10000000 11110000) (-259991542) //t2线程打印 4 4 (object header) ce 7f 00 00 (11001110 01111111 00000000 00000000) (32718) 8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) 12 4 (loss due to the next object alignment)Instance size: 16 bytesSpace losses: 0 bytes internal + 4 bytes external = 4 bytes total运行后果剖析（JVM默认小端模式）：
程序一开始就是设置了5秒钟的睡眠，目标在于让JVM优先加载实现后，让JVM默认状态下会提早启动偏差锁，能够开出一开始main线程打印的是“101”就是默认的匿名偏差锁，然而并没有设置线程id；之后t0线程就立马打印了，此时只需利用CAS操作把t0的线程id设置进对象头即可，所以这个时候也是一个偏差锁状态；之后的程序睡眠5秒钟后，程序中t1、t2线程执行代码块时，无意的将其线程睡眠几秒钟，目标在于不论那个线程率先抢到锁，都能让另外一个线程在自旋期待中，所以t1线程打印的是“00”就曾经是轻量级锁了，最初看程序执行后果，t2打印的是“10”就曾经降级为重量级锁了，显然t2线程曾经超过了自旋的最大次数，曾经转成重量级锁了。
九、总结
那平时写代码如何对synchronized优化呢？
我总结就是：
1、缩小synchronized的范畴，同步代码块中尽量短，缩小同步代码块中代码的执行工夫，缩小锁的竞争。
2、升高synchronized锁的粒度，将一个锁拆分为多个锁进步并发度。这点其实能够参考HashTable与ConcurrentHashMap的底层原理。
HashTable加锁实际上锁的是整个hash表，一个操作进行的时候，其余操作都无奈进行了。
然而ConcurrentHashMap是部分锁定，锁得并不是一整张表，ConcurrentHashMap锁得是一个segment，以后的segment被锁了，不影响其余segment的操作。
文/harmony
关注得物技术，做最潮技术人！