synchronized内置锁是一种对象锁(锁的是对象而非引用)，作用粒度是对
象，可以用来实现对临界资源的同步互斥访问，是可重入的。

加锁的方式：
同步实例方法，锁是当前实例对象
同步类方法，锁是当前类对象
同步代码块，锁是括号里面的对象
synchronized底层原理
synchronized是基于JVM内置锁实现，通过内部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步，监视器锁的实现依赖底层操作系统的Mutex lock（互斥锁）实现，它是一个重量级锁性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（LockCoarsening）、锁消除（LockElimination）、轻量级锁（LightweightLocking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销，，内置锁的并发性能已经基本与Lock持平。
synchronized关键字被编译成字节码后会被翻译成monitorenter 和
monitorexit 两条指令分别在同步块逻辑代码的起始位置与结束位置。

每个同步对象都有一个自己的Monitor(监视器锁)，加锁过程如下图所示：

那么有个问题来了，我们知道synchronized加锁加在对象上，对象是如何记录锁状态的呢？
答案是锁状态是被记录在每个对象的对象头（Mark Word）中，下面我们一
起认识一下对象的内存布局
对象的内存布局
HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

• 对象头：比如 hash码，对象所属的年代，对象锁，锁状态标志，偏向锁（线程）ID，偏向时间，数组长度（数组对象）等
• 实例数据：即创建对象时，对象中成员变量，方法等
• 对齐填充：对象的大小必须是8字节的整数倍
  

面试问题：实例对象内存中存储在哪？
如果实例对象存储在堆区时：实例对象内存存在堆区，实例的引用存在栈上，实例的元数据class存在方法区或者元空间
Object实例对象一定是存在堆区的吗？
不一定，如果实例对象没有线程逃逸行为。

对象头
HotSpot虚拟机的对象头包括两部分信息，第一部分是“Mark Word”，用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，这部分数据的长度在32位和64位的虚拟机（暂 不考虑开启压缩指针的场景）中分别为32个和64个Bits，官方称它为“Mark Word”。对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据
无关的额 外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机 中对象未被锁定的状态下，MarkWord的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志 位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示。

但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。对象头信息是与对象自身定义的数据无关的额外存储成本，但是考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化，变化状态如下（32位虚拟机）：
以32位JVM中存储内容为例

JDK1.6版本之后对synchronized的实现进行了各种优化，如自旋锁、偏向锁和轻量级锁并默认开启偏向锁
开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
关闭偏向锁：-XX:-UseBiasedLocking


偏向锁
偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过
研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多
次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引
入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模
式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需
再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从
而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效
果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激
烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相
同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏
向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。下面我们接
着了解轻量级锁。
轻量级锁
倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种
称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量
级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同
步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应
的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就
会导致轻量级锁膨胀为重量级锁。
自旋锁
轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进
行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都
不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实
现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对
比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程
可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为
自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环
后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作
系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。
最后没办法也就只能升级为重量级锁了。
锁消除
消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编
译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编
译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种
方式消除没有必要的锁，可以节省毫无意义的请求锁时间，如下StringBuffer的
append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，
并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情
景，JVM会自动将其锁消除。

逃逸分析
使用逃逸分析，编译器可以对代码做如下优化：
一、同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
二、将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
三、分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。
是不是所有的对象和数组都会在堆内存分配空间？
不一定
在Java代码运行时，通过JVM参数可指定是否开启逃逸分析， ­
XX:+DoEscapeAnalysis ： 表示开启逃逸分析 ­XX:­DoEscapeAnalysis ： 表示关
闭逃逸分析 从jdk 1.7开始已经默认开始逃逸分析，如需关闭，需要指定­XX:­
DoEscapeAnalysis

/**

• 进行两种测试
• 关闭逃逸分析，同时调大堆空间，避免堆内GC的发生，如果有GC信息将会被打印
  出来
• VM运行参数：­Xmx4G ­Xms4G ­XX:­DoEscapeAnalysis ­
  XX:+PrintGCDetails ­XX:+HeapDumpOnOutOfMemoryError
• 开启逃逸分析
• VM运行参数：­Xmx4G ­Xms4G ­XX:+DoEscapeAnalysis ­
  XX:+PrintGCDetails ­XX:+HeapDumpOnOutOfMemoryError
• 执行main方法后
• jps 查看进程
• jmap ­histo 进程ID

*/