synchronized原理

static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
    synchronized (lock) {
        counter++;
    }
}

对应的字节码为

Code:
stack=2, locals=3, args_size=1
0: getstatic #2 // <- lock引用 （synchronized开始）
3: dup
4: astore_1 // lock引用 -> slot 1
5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
6: getstatic #3 // <- i
9: iconst_1 // 准备常数 1
10: iadd // +1
11: putstatic #3 // -> i
14: aload_1 // <- lock引用
15: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
16: goto 24
19: astore_2 // e -> slot 2
20: aload_1 // <- lock引用
21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
22: aload_2 // <- slot 2 (e)
23: athrow // throw e
24: return
Exception table:
from to target type
6 16 19 any
19 22 19 any
LineNumberTable:
line 8: 0
line 9: 6
line 10: 14
line 11: 24

可以发现即使出现异常synchronize也会自动释放锁

注意monitorenter和monitorexit指令

方法级别的 synchronized 不会在字节码指令中有所体现

☆Java对象内存布局

在java虚拟机中，java对象在内存中存储的布局可以分为3块区域：对象头、实例数据和对齐填充。

下面的图片更细致

1.对象头

由于Java面向对象的思想，在JVM中需要大量存储对象，存储时为了实现一些额外的功能，需要在对象中添加一些标记字段用于增强对象功能，这些标记字段组成了对象头。

对象头是实现synchronized的锁对象的基础。

对象头分为Mark word和Klass Word和array length（array length数组长度只有数组对象才有）

Mark word

用于存储对象自身的运行时数据即monitor对象。

monitor对象存储如下信息:比如加的哪种锁，没有锁的时候存放hashcode，age等信息。

如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。

Klass Word

Klass Word相等于指针，指向的是类的元数据信息

array length

存放数组长度,只有数组的对象才有,如果是数组的对象还包括数组的长度，这部分内存按4字节对齐。

2.对象体:实例变量

存放类的属性数据信息，包括父类的属性信息。

3.填充数据

由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐，这点了解即可。

☆Monitor概念

Monitor 被翻译为监视器或管程每个 Java 对象的对象头都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针。

Java虚拟机给每个对象和class字节码都设置了一个监听器Monitor，用于检测并发代码的重入，同时在Object类中还提供了notify和wait方法来对线程进行控制。

JVM中的同步是基于进入与退出监视器对象(管程对象)(Monitor) 来实现的，每个对象实例都会有一个Monitor对象，Monitor对象会和Java对象一同创建并销毁。 Monitor对象是由C++来实现的。

为什么存在用户态与内核态之间的切换？

那些处于EntryList与WaitSet中的线程均处于阻塞状态，阻塞操作是由操作系统来完成的，在linux下是通过pthread_mutex_lock函数实现的。线程被阻塞后便会进入到内核调度状态，当他们获取到了锁后又会回到用户态，这会导致系统在用户态与内核态之间来回切换，严重影响锁的性能。

www.cnblogs.com/webor2006/p…

刚开始 Monitor 中 Owner 为 null

当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2，Monitor中只能有一个 Owner

在 Thread-2 上锁的过程中，如果 Thread-3，Thread-4，Thread-5 也来执行 synchronized(obj)，Thread-3，Thread-4，Thread-5就会进入EntryList被BLOCKED阻塞

Thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争时是非公平的

图中 WaitSet 中的 Thread-0，Thread-1 是之前获得过锁，但条件不满足进入 WAITING 状态的线程，需要被唤醒才能参与竞争锁.

注意：
synchronized 必须是进入同一个对象的 monitor 才有上述的效果
不加 synchronized 的对象不会关联监视器，不遵从以上规则

☆Mark word

以 32 位虚拟机为例

可以看到markword包含了age ,hashcode，state等信息

bias_lock：对象是否启动偏向锁标记，只占1个二进制位。为1时表示对象启动偏向锁，为0时表示对象没有偏向锁。
age：4位的Java对象年龄。在GC中，如果对象在Survivor区复制一次，年龄增加1。当对象达到设定的阈值时，将会晋升到老年代。默认情况下，并行GC的年龄阈值为15，并发GC的年龄阈值为6。由于age只有4位，所以最大值为15，这就是-XX:MaxTenuringThreshold选项最大值为15的原因。
identity_hashcode：即图中的hashcode,25位的对象标识Hash码，采用延迟加载技术。调用方法System.identityHashCode()计算，并会将结果写到该对象头中。当对象被锁定时，该值会移动到管程Monitor中。
thread：持有偏向锁的线程ID。
epoch：偏向时间戳。
ptr_to_lock_record：指向栈中锁记录的指针。
ptr_to_heavyweight_monitor：指向monitor对象（也称为管程或监视器锁）的起始地址，每个对象都存在着一个monitor与之关联，对象与其monitor之间的关系有存在多种实现方式，如monitor对象可以与对象一起创建销毁或当前线程试图获取对象锁时自动生成，但当一个monitor被某个线程持有后，它便处于锁定状态
lock：2位的锁状态标记位，由于希望用尽可能少的二进制位表示尽可能多的信息，所以设置了lock标记。该标记的值不同，整个mark word表示的含义不同。
State

Normal表示无锁

- hashcode：对象的hashcode值，占25位
- age：分代年龄，当到达15之后就被分配到老年代，占4位
- biased_lock:是否是偏向锁：占1位
- lock标志为01：表示没有与任何锁关联，也就是无锁：占2位
01既可以代表是无锁,也可以代表是偏向锁，通过后三位可以分辨是无锁还是偏向锁。
001:无锁
101：偏向锁

Biased表示偏向锁

- thread：线程id,偏向锁记录的是线程id
- epoch:
- age:分代年龄
- biased_lock:是否是偏向锁
- lock标志为01：表示没有与任何锁关联，也就是无锁
01既可以代表是无锁,也可以代表是偏向锁，通过后三位可以分辨是无锁还是偏向锁。
001:无锁
101:偏向锁

Lightweight Locked表示轻量级锁

- ptr_to_lock_record:30:表示指向轻量级锁
- lock标志位00：表示代表是轻量级锁
- 轻量锁记录的是锁记录地址

Heavyweight Locked表示重量级锁

- ptr_to_heavyweight_monitor:30:表示指向重量级锁
- lock标志位10：表示代表的是重量级锁
- 重量锁记录的是monitor

Marked for GC表示被垃圾回收

lock标志位11：代表被垃圾回收了

☆偏向锁、轻量锁、重量锁升级

我是一个线程，生活在JVM中，这一段日子过得有些无聊，整个世界似乎只有这一个人，天天忙着执行代码，想休息一下都很难。

我听说人类写的代码中有些特殊的地方，叫做临界区，比如synchronized修饰的方法或者代码块，他们非常神奇，在同一时刻JVM老大只允许一个线程进入执行。

实际上，老大设置了一把锁，抢到了这把锁就可以执行，否则只能阻塞，等待别人释放锁。

老大说，阻塞就是不用干活了，老老实实地等着就行。

竟然还有这等美事！赶紧让我阻塞一次吧。

可是老大又说：“每次设置锁我都得和操作系统打交道，请他在内核中维护一个什么Mutex（互斥量）的东西，他还得把你们这些线程阻塞，切换，这可是一笔巨大的费用啊，所以这些锁还是少用为妙。”

我运气也不好，我不知道执行了多少代码，调用了多少函数，竟然一次也没遇到临界区!

我想也许这个程序员编程时不小心，没有考虑多线程并发的情况；也有可能是这些程序大部分都是无状态的，多少个线程执行都没有问题。

于是我只好一直执行下去，不知道过了多少天，我激动地发现，一个synchronized修饰的代码块终于出现了：

Account account = new Account();

synchronized(account){

//...临界区的代码...

}

单线程:cas 线程id:偏向锁

我满心期望别的线程已经进入了代码块，那我就可以阻塞、休息。

即使没有其他线程进入临界区，老大为我申请锁，也得和操作系统协商什么互斥量，从用户态进入核心态，再从核心态返回用户态，总要花些功夫吧。

可是老大根本没有去找操作系统，只是看了看这个account对象的所谓“对象头”，其中有个叫做Mark Word的东西，似乎是个什么数据结构，里边有几个标识位，还有其他数据。

老大随手使用CAS操作把我的线程ID记录到了这个Mark Word当中，修改了标识位，然后告诉我说：可以了，你现在拥有这把锁了，进去执行代码吧。

我惊奇地说：“老大你不和操作系统协商设置Mutex了？”

老大说：“不用了，你看现在就你一个线程进入了这个代码块，我只要记录下你的线程ID，就表示你拥有这把锁了，不用操作系统介入。”

我获得了锁，开始执行被synchronized包裹的代码块。

等到我第二次执行到这个synchronized的时候，老大只是看了一眼锁对象account的Mark Word就说：“你的线程ID还在，还持有着这个对象的锁，进入临界区执行吧。”

我连喘口气的机会都没有，只好继续执行。

老大说，这叫偏向锁，在没有别的线程竞争的时候，一直偏向我，可以让我一直执行下去。

我是多么期盼来一个新的线程来和我竞争啊！

竞争不激烈:cas 锁记录:轻量级锁

很快，机会就来了。

另外一个线程0x3704也要进入这个代码块执行，但是锁对象account 保存的是我的线程ID，他是没法进入临界区的。

我心想，我们两个至少得有一个进入阻塞状态，休息一会儿了。

但是老大还是不去操作系统协商，只是说：我把这个偏向锁升级一下，变成一个轻量级的锁吧。

老大把锁对象account恢复成无锁状态，在我们俩的栈帧中各自分配了一个空间，叫做Lock Record，把锁对象account的Mark Word在我们俩这里各自复制了一份放在Lock Record，叫做Displaced Mark Word，这名字真奇怪。

然后把我的Lock Record的地址使用CAS放到了Mark Word当中，并且把锁标志位改为00，这其实就意味着我也已经获得了这个轻量级的锁了，可以继续进入临界区执行。

0x3704没有获得锁，但还是不阻塞，老大让他自旋几次，等待一会儿。

等到我退出临界区，释放锁的时候，需要把这个Displaced markd word 使用CAS复制回去。接下来他就可以加锁了。

我们两个交替着进入临界区，执行这段代码，相安无事，很少出现真正的竞争。

即使是出现了竞争，想获得锁的线程只要自旋几次，等待一会儿，锁就可能释放了。

很明显，如果没有竞争或者轻度的竞争，轻量级锁仅仅使用CAS操作和Lock record就避免了重量级互斥锁的开销，对JVM老大来说，确实是个好主意。

竞争激烈:自旋获取不到锁:重量级锁

轻量级锁运行得挺好，我还是没有机会休息，终于有这么一天，0x3704 正在持有锁，在临界区辛苦地执行代码。我自旋了好多次，0x3704还是没释放锁。

这时候JVM老大说：自旋次数太多了，太浪费CPU了，接下来升级为重量级锁！

这个重量级锁需要操作系统的帮忙，依赖操作系统底层的Mutex Lock。

只见老大创建了一个monitor 对象，把这个对象的地址更新到了Mark word当中。

锁升级了！

由于0x3704还在持有锁运行，而我终于进入了梦寐以求的状态：阻塞！终于可以休息一下了！

仔细一想，老大煞费心机地设置了偏向锁和轻量级锁，就是为了避免阻塞，避免操作系统的介入，这两种锁无非就是针对这两种情况：偏向锁和轻量级锁。

总结

偏向锁：通常只有一个线程在临界区执行

轻量级锁：可以有多个线程交替进入临界区，在竞争不激烈的时候，稍微自旋等待一下就能获得锁。

至于重量级锁，也是我最为期待的锁，那就是出现了激烈的竞争，只好让我们去阻塞休息了。

0.无锁

无锁指没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。

无锁的特点是修改操作会在循环内进行，线程会不断的尝试修改共享资源。如果没有冲突就修改成功并

退出，否则就会继续循环尝试。

如果有多个线程修改同一个值，必定会有一个线程能修改成功，而其他修改失败的线程会不断重试直到修改成功。

1.偏向锁

引入偏向锁的主要目的是：为了在无多线程竞争的情况下尽量减少不必须要的轻量级锁执行路径。

其实在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一个线程多次获取，所以引入偏向锁就可以减少很多不必要的性能开销和上下文切换。

偏向锁是指当一段同步代码一直被同一个线程所访问时，即不存在多个线程的竞争时，那么该线程在后续访问时便会自动获得锁，从而降低获取锁带来的消耗，即提高性能。

当一个线程访问同步代码块并获取锁时，会在 Mark Word 里存储锁偏向的线程 ID。在线程进入和退出同步块时不再通过 CAS 操作来加锁和解锁，而是检测 Mark Word 里是否存储着指向当前线程的偏向锁。

轻量级锁的获取及释放依赖多次 CAS 原子指令，而偏向锁只需要在置换 ThreadID 的时候依赖一次 CAS 原子指令即可。

偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。

关于偏向锁的撤销，需要等待全局安全点，即在某个时间点上没有字节码正在执行时，它会先暂停拥有偏向锁的线程，然后判断锁对象是否处于被锁定状态。如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁，恢复到无锁（标志位为01）或轻量级锁（标志位为00）的状态。

hashCode

我们知道在Java中，一切对象都继承自java.lang.Object类。这个类中有一个可继承的方法叫hashCode()。它在Object类中的方法签名是这样的：

public native int hashCode();

可以看到，如果一个对象不覆盖这个方法，那它会继承Object类的实现，是一个native的方法。

这个时候，它会根据对象的内存地址返回哈希值。

所以我们运行下面这段代码会输出false:

public class HashCodeDemo {
    public static void main(String[] args) {
        Object objectA = new Object();
        Object objectB = new Object();
        System.out.println(objectA.hashCode() == objectB.hashCode());
    }
}

有些对象需要根据对象的字段的内容来计算hash值，比如字符串String。

因为String复写了hashCode()方法，所以以下代码会输出true：

public class HashCodeDemo {
    public static void main(String[] args) {
        String s1 ="hello";
        String s2 ="hello";
        System.out.println(s1.hashCode() == s2.hashCode());
    }
}

identityHashCode

那如果一个对象覆盖了hashCode方法，我们仍然想获得它的内存地址计算的Hash值，应该怎么办呢?

java.lang.System类提供了一个静态方法：

public static native int identityHashCode(Object o);

偏向锁和HashCode的关系

通常情况下，我们把”使用内存地址计算出来的HashCode“叫做“identity hash code”。

所以未覆盖Object类的hashCode()方法生成的hashCode的就是“identity hash code”。

一个类被加载的时候，hashCode是被存放在对象头里面的Mark Word里面的。

在32位的JVM中，它会占25位;在64位的JVM中，它会占31位。

需要注意的是：这里说的hashCode仅仅指的是identity hash code。

如果不是identity hash code，那它不会存储在对象头里。也就是只有identity hash code会存储在对象头里。

每个Java对象都有对象头。如果是非数组类型，则用2个字宽来存储对象头，如果是数组，则会用3个字宽来存储对象头。在32位虚拟机中，一个字宽是32位;在64位虚拟机中，一个字宽是64位。对象头如下

再来看看Mark Word的结构(无锁状态)：

注意，这是“无锁状态”下。

当一个对象已经计算过identity hash code，它就无法进入偏向锁状态;当一个对象当前正处于偏向锁状态，并且需要计算其identity hash code的话，则它的偏向锁会被撤销，并且锁会膨胀为重量级锁;

那什么时候对象会计算identity hash code呢?

当然是当你调用未覆盖的Object.hashCode()方法或者System.identityHashCode(Object o)时候了。

偏向锁在 JDK 6 及之后版本的 JVM 里是默认启用的。可以通过 JVM 参数关闭偏向锁：-XX:-UseBiasedLocking=false，

关闭之后程序默认会进入轻量级锁状态。

2.轻量级锁

Java并发之彻底搞懂偏向锁升级为轻量级锁 - 甜菜波波 - 博客园 (cnblogs.com)

线程1当前拥有偏向锁对象,线程2是需要竞争到偏向锁。
假如线程2来竞争锁对象,流程如下
判断当前对象头是否是偏向锁;
判断拥有偏向锁的线程1是否还存在？
--线程1不存在
直接设置偏向锁标识为0(线程1执行完毕后,不会主动去释放偏向锁);
使用cas替换偏向锁线程ID为线程2,锁不升级，仍为偏向锁;
--线程1还存在
暂停线程1,设置锁标志位为00(变为轻量级锁),偏向锁为0;
从线程1的空闲monitor record中读取一条,放至线程1的当前monitor record中;
更新mark word，将mark word指向线程1中monitor record的指针;
继续执行线程1的代码;
锁升级为轻量级锁;   
线程2自旋来获取锁对象;

引入轻量级锁的主要目的是：在多线程竞争不激烈的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。需要注意的是轻量级锁并不是取代重量级锁，而是在大多数情况下同步块并不会出现严重的竞争情况，所以引入轻量级锁可以减少重量级锁对线程的阻塞带来的开销。

所以偏向锁是认为环境中不存在竞争情况，而轻量级锁则是认为环境中不存在竞争或者竞争不激烈，所以轻量级锁一般都只会有少数几个线程竞争锁对象，其他线程只需要稍微等待（自旋）下就可以获取锁，但是自旋次数有限制，如果自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁膨胀为重量级锁，重量级锁使除了拥有锁的线程以外的线程都阻塞，防止CPU空转。

3.自旋优化

重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞（进入Blocked entryList）。

多线程中，对共享资源进行访问，为了防止并发引起的相关问题，通常都是引入锁的机制来处理并发问题。获取到资源的线程A对这个资源加锁，其他线程比如B要访问这个资源首先要获得锁，而此时A持有这个资源的锁，只有等待线程A逻辑执行完，释放锁，这个时候B才能获取到资源的锁进而获取到该资源。

这个过程中，A一直持有着资源的锁，那么没有获取到锁的其他线程怎么办？

通常就会有两种方式：

1.一种是没有获得锁的进程就直接进入阻塞（BLOCKING），这种就是互斥锁

2.另外一种就是没有获得锁的进程，不进入阻塞，而是一直循环获取锁，看是否能够等到A释放了资源的锁。

wiki中的定义如下：自旋锁是计算机科学用于多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。

自旋锁（spin lock）是一种非阻塞锁，也就是说，如果某线程需要获取锁，但该锁已经被其他线程占用时，该线程不会被挂起，而是在不断的消耗CPU的时间，不停的试图获取锁。

互斥量（mutex）是阻塞锁，当某线程无法获取锁时，该线程会被直接挂起，该线程不再消耗CPU时间，当其他线程释放锁后，操作系统会激活那个被挂起的线程，让其投入运行。

而《linux内核设计与实现》经常提到两种态，一种是内核态，一种是用户态。

对于自旋锁来说，自旋锁使线程处于用户态，而互斥锁需要重新分配，进入到内核态。

用户态比较轻，内核态比较重。

自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。因此操作系统的实现在很多地方往往用自旋锁。Windows操作系统提供的轻型读写锁（SRW Lock）内部就用了自旋锁。显然，单核CPU不适于使用自旋锁，这里的单核CPU指的是单核单线程的CPU，因为，在同一时间只有一个线程是处在运行状态，假设运行线程A发现无法获取锁，只能等待解锁，但因为A自身不挂起，所以那个持有锁的线程B没有办法进入运行状态，只能等到操作系统分给A的时间片用完，才能有机会被调度。

这种情况下使用自旋锁的代价很高。 （单核CPU不适合自旋锁，这个也只是针对单核单线程的情况，现在的技术基本单核都是支持多线程的）

如果锁长时间被占用，则浪费处理器资源，因此自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了（默认10次）。

自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。 Java 7 之后不能控制是否开启自旋功能。

为什么要使用自旋锁

互斥锁有一个缺点，他的执行流程是这样的托管代码 - 用户态代码 - 内核态代码、上下文切换开销与损耗，假如获取到资源锁的线程A立马处理完逻辑释放掉资源锁，如果是采取互斥的方式，那么线程B从没有获取锁到获取锁这个过程中，就要用户态和内核态调度、上下文切换的开销和损耗。

所以就有了自旋锁的模式，让线程B就在用户态循环等着，减少消耗。

互斥锁申请锁时，从用户态进入内核态，申请到后从内核态返回用户态（两次切换）；没有申请到时阻塞睡眠在内核态。使用完资源后释放锁，从用户态进入内核态，唤醒阻塞等待锁的进程，返回用户态（又两次切换）；被唤醒进程在内核态申请到锁，返回用户态（可能其他申请锁的进程又要阻塞）。

所以，使用一次锁，包括申请，持有到释放，当前进程要进行四次用户态与内核态的切换。同时，其他竞争锁的进程在这个过程中也要进行一次切换。

进程上下文切换的直接消耗包括CPU寄存器保存和加载，需要调度时有内核调度代码的执行。

自旋锁比较适用于锁使用者保持锁时间比较短的情况，这种情况下自旋锁的效率要远高于互斥锁。

自旋锁的缺点

过多占用CPU的资源，如果锁持有者线程A一直长时间的持有锁处理自己的逻辑，那么这个线程B就会一直循环等待过度占用cpu资源

4.重量级锁原理

Monitor 被翻译为监视器或管程，每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后(注意是重量级锁)，该对象头的Mark Word中就被设置指向 Monitor 对象的指针。

Monitor 结构如下

重量级锁是指当有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态。

重量级锁通过对象内部的监视器（monitor）实现，而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现，操作系统实现线程之间的切换需要从用户态切换到内核态，切换成本非常高。

简言之，就是所有的控制权都交给了操作系统，由操作系统来负责线程间的调度和线程的状态变更。而这样会出现频繁地对线程运行状态的切换，线程的挂起和唤醒，从而消耗大量的系统资源，导致性能低下。

5.锁优先级

如果有偏向锁，先使用偏向锁(只有一个线程)。

如果有其它线程(有竞争关系)，那么会撤销偏向锁，升级为轻量锁。

如果有其它线程来竞争多次自旋获取不到锁，进入锁膨胀升级为重量锁。

6.锁优化-锁消除

@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations=3)
@Measurement(iterations=5)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {
    static int x = 0;
    @Benchmark
    public void a() throws Exception {
        x++;
    }
    @Benchmark
    public void b() throws Exception {
        Object o = new Object();
        synchronized (o) {
            x++;
    }
}

由于JIT的存在即即时编译器，会对代码进行优化，由于不可能被其他线程共享，因此加锁毫无意义,即时编译器就会将锁优化掉。

锁消除是发生在编译器级别的一种锁优化方式。有时候我们写的代码完全不需要加锁，却执行了加锁操作。前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸分析

比如，StringBuffer类的append操作：

@Override
public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

从源码中可以看出，append方法用了synchronized关键词，它是线程安全的。

如果我们只在线程内部把StringBuffer当作局部变量使用,那么她是线程安全的：

public class Demo {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        int size = 10000;
        for (int i = 0; i < size; i++) {
            createStringBuffer("Hyes", "为分享技术而生");
        }
        long timeCost = System.currentTimeMillis() - start;
        System.out.println("createStringBuffer:" + timeCost + " ms");
    }
    public static String createStringBuffer(String str1, String str2) {
        StringBuffer sBuf = new StringBuffer();
        sBuf.append(str1);// append方法是同步操作
        sBuf.append(str2);
        return sBuf.toString();
    }
}

代码中createStringBuffer方法中的局部对象sBuf，就只在该方法内的作用域有效，不同线程同时调用createStringBuffer()方法时，都会创建不同的sBuf对象，因此此时的append操作若是使用同步操作，就是白白浪费的系统资源。

这时我们可以通过编译器将其优化，将锁消除，前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸分析:

-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks

其中+DoEscapeAnalysis表示开启逃逸分析，+EliminateLocks表示锁消除。

逃逸分析：比如上面的代码，它要看sBuf是否可能逃出它的作用域？

如果将sBuf作为方法的返回值进行返回，那么它在方法外部可能被当作一个全局对象使用，就有可能发生线程安全问题，这时就可以说sBuf这个对象发生逃逸了，因而不应将append操作的锁消除。

但如果没有发生逃逸,比如我们上面的代码没有发生锁逃逸，锁消除就可以带来一定的性能提升。

锁削除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。

锁削除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。

也许读者会有疑问，变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是程序员自己应该是很清楚的，怎么会在明知道不存在数据争用的情况下要求同步呢？

答案是有许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过了大部分读者的想象。

我们来看看下面代码清单13-6中的例子，这段非常简单的代码仅仅是输出三个字符串相加的结果，无论是源码字面上还是程序语义上都没有同步。

//代码清单 13-6 字符串连接操作  
public String concatString(String s1, String s2, String s3) {  
    return s1 + s2 + s3;  
}

我们也知道，由于String是一个不可变的类，对字符串的连接操作总是通过生成新的String对象来进行的，因此Javac编译器会对String连接做自动优化。

在JDK 1.5之前，会转化为StringBuffer对象的连续append()操作，在JDK 1.5及以后的版本中，会转化为StringBuilder对象的连续append()操作。

即代码清单13-6中的代码可能会变成代码清单13-7的样子。

//代码清单 13-7 Javac转化后的字符串连接操作  
public String concatString(String s1, String s2, String s3) {  
    StringBuffer sb = new StringBuffer();  
    sb.append(s1);  
    sb.append(s2);  
    sb.append(s3);  
    //String是不可变类
    //直接返回也是没有问题的
    return sb.toString();  
}

实事求是地说，既然谈到锁削除与逃逸分析，那虚拟机就不可能是JDK 1.5之前的版本，所以实际上会转化为非线程安全的StringBuilder来完成字符串拼接，并不会加锁.但是这也不影响笔者用这个例子证明Java对象中同步的普遍性。

　　现在大家还认为这段代码没有涉及同步吗？

每个StringBuffer.append()方法中都有一个同步块，锁就是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()方法内部。也就是sb的所有引用永远不会“逃逸”到concatString()方法之外，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地削除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。

7.锁优化-锁粗化

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是大某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的讲求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。锁粗化就是告诉我们任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。

一种极端的情况如下：

public void doSomethingMethod(){    
    synchronized(lock){        
        //do some thing    
    }    
    //这是还有一些代码，做其它不需要同步的工作，但能很快执行完毕    
    synchronized(lock){        
        //do other thing    
    }
}

上面的代码是有两块需要同步操作的，但在这两块需要同步操作的代码之间，需要做一些其它的工作，而这些工作只会花费很少的时间，那么我们就可以把这些工作代码放入锁内，将两个同步代码块合并成一个，以降低多次锁请求、同步、释放带来的系统性能消耗，合并后的代码如下:

public void doSomethingMethod(){    
    //进行锁粗化：整合成一次锁请求、同步、释放    
    synchronized(lock){        
        //do some thing        
        //做其它不需要同步但能很快执行完的工作        
        //do other thing    
    }
}

注意：这样做是有前提的，就是中间不需要同步的代码能够很快速地完成，如果不需要同步的代码需要花很长时间，就会导致同步块的执行需要花费很长的时间，这样做也就不合理了。

另一种需要锁粗化的极端的情况是：

for(int i=0;i<size;i++){    
    synchronized(lock){    
    }
}

上面代码每次循环都会进行锁的请求、同步与释放，看起来貌似没什么问题，且在jdk内部会对这类代码锁的请求做一些优化，但是还不如把加锁代码写在循环体的外面，这样一次锁的请求就可以达到我们的要求，除非有特殊的需要：循环需要花很长时间，但其它线程等不起，要给它们执行的机会。

锁粗化后的代码如下：

synchronized(lock){    
    for(int i=0;i<size;i++){    
    }
}

5.java并发编程之synchronized原理