本文承接未完待续的 Java内存模型JMM之六深入理解synchronized(1)
3.7 锁消除
消除同步锁是JVM另外一种锁的优化，这种优化更彻底， JVM通过运行时JIT编译(可以理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，对一些在代码上要求添加同步，但是通过数据逃逸技术分析发现不可能存在共享数据竞争，这时JVM会对这些没有必要的同步锁进行消除。所以锁消除可以节省毫无意义的请求锁的时间，那么明知不存在数据竞争为何还进行了同步操作？作为程序员来说，这的确不会写出这样的代码，但是有时候程序并不是我们所想的那样，我们虽然没有显示的使用同步锁，但是我们在使用一些JDK内置的API时，如StringBuffer、Vector、HashTable等，这个时候会存在隐形的同步加锁操作。比如StringBuffer的append()方法，Vector的add()方法。
public void add(String str1, String str2) {
//StringBuffer是线程安全,由于sb只会在append方法中使用,不可能被其他线程引用
//因此sb属于不可能共享的资源,JVM会自动消除内部的锁
StringBuffer sb = new StringBuffer();
sb.append(str1)
.append(str2);
}
以上代码很常见吧，特别是在拼接一些SQL、HQL等操作的时候， 由于该处的sb对象是一个局部变量，并且不会被其他线程引用到，但是StringBuffer的append方法却是个同步方法，此时，JVM就会通过锁消除机制将其锁消除。
3.7 锁粗化
原则上，我们在编写代码的时候，总是推荐奖同步块的作用范围限制的尽量小，只在共享数据的实际作用域中才进行同步，这是为了使得需要同步的操作尽可能的少，如果存在锁竞争也能够使等待锁的线程能够尽快地拿到锁。大部分情况下，这样的原则是没有问题的，但是如果一系列的连续操作都是对同一个锁的反复加锁和解锁，甚至在循环体中进行反复的加解锁操作，这样的情况即使没有线程竞争，频繁的进行互斥同步操作也会导致不必要的性能损耗。
锁粗化就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁，如下代码示例：
public void vectorTest(){
Vector<String> vector = new Vector<String>();
for(int i = 0 ; i < 10 ; i++){
vector.add(i + "");
}
System.out.println(vector);
} 以上代码是很常见的在循环体中进行集合元素添加操作，我们知道vector的add方法是一个同步方法，每次add都需要加锁，执行完之后又需要解锁操作， 这时候JVM检测到对同一个对象（vector）连续加锁、解锁操作，就会合并一个更大范围的加锁、解锁操作，即将加锁解锁操作移到for循环之外，以一次性的加解锁操作取代多次的加解锁操作。
3.8 synchronized不能被interrupt中断
线程的中断方法说的是，只能中断正处于阻塞状态或者正准备执行一个阻塞操作的线程，这里说的阻塞其实就是指调用了Join, wait, sleep等方法导致线程进入的WAITING/TIMED_WAITING状态，因为这些方法能够感知到中断操作从而抛出中断异常。而所谓的synchronized不能被interrupt方法中断，指的是当线程执行到synchronized方法或者代码块的时候，由于对象锁被占用导致线程不得不通过调用底层的park方法进入死等状态，这时线程其实也是进入了阻塞状态，但是由于没有显示的调用能够抛出中断异常的方法，从而导致被阻塞的线程不能从阻塞状态恢复过来，使得线程一直处于锁等待的阻塞状态。如下代码示例可以作为一种说明：
public class ThreadTest implements Runnable{
public ThreadTest() {
//该线程已持有当前实例锁
new Thread() {
public void run() {
f(); // Lock acquired by this thread
}
}.start();
}
public synchronized void f() {
System.out.println("Trying to call f()");
while(true) // Never releases lock
Thread.yield();
}
public void run() {
//中断判断
while (true) {
if (Thread.interrupted()) {
System.out.println("中断线程!!");
break;
} else {
f();
}
}
}
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(new ThreadTest());
t.start();
TimeUnit.SECONDS.sleep(1);
//中断线程,无法生效
t.interrupt();
}
}
在创建ThreadTest示例时，其构造方法里面立即就执行了synchronized方法f，f方法会导致其一直持有对象锁，当线程t被创建出来也调用f方法的时候，将会一直处于锁等待状态，也是阻塞状态，虽然后来调用了interrupt中断方法，但是线程t并不能被中断，因为没有可以抛出中断异常的方法，线程t只能一直等待直到获取到对象锁。
3.9 synchronized锁及锁优化总结
| 锁 | 原理 | 优点 | 缺点 | 适用场景 |
| 偏向锁 | 如果一个线程获得了锁，那么该锁就进入偏向模式，当这个线程再次请求锁时，无需再做任何同步操作 | 省去重复获取/释放锁的开销 | 如果竞争激烈，会带来额外的锁撤销的消耗 | 大多数时候都只有一个相同的线程，并且多次访问同步块的场景，不存在竞争 |
| 轻量级锁 | 仅仅通过CAS指令和自旋操作达到锁的获取和释放 | 避免了线程从用户态切换到内核态的消耗，线程并不会被阻塞，提高了程序的响应速度 | 如果存在锁竞争，将会通过自旋消耗CPU | 不存在竞争，多线程之间交替执行，并且同步块执行较快的场景 |
| 重量级锁 | 通过操作系统底层的实现，阻塞竞争的线程和唤醒被阻塞的线程 | 比起其它情况，几乎没有优点 | 线程阻塞/唤醒需要在用户态和内核态之间切换，消耗大量成本，并且由于阻塞，使线程响应变慢 | 竞争激烈，同步代码块逻辑复杂需占用大量时间的场景 |
| 自旋/自适用自旋 | 通过执行多次无意义的指令，避免不必要的挂起和恢复线程时状态转换造成的性能消耗 | 避免了线程从用户态切换到内核态的消耗 | 白白消耗CPU | 轻量级锁和重量级锁产生竞争时，在切换到内核态之前 |
| 锁消除 | 通过数据逃逸技术分析对不存在数据共享的同步锁实施锁消除 | 使其消除了不必要的获取/释放锁的消耗 | 还好吧，完全由JVM自行完成，依赖JVM的JIT编译 | JVM的即时编译，针对JDK底层的API |
| 锁粗化 | 将多次对同一个锁对象的获取/释放操作，扩展为一次获取/释放操作 | 省去重复获取/释放锁的开销 | 完全依赖JVM自身 | 将同步块置于循环操作中的场景 |
