1 锁优化

JVM 在加锁的过程中，会采用自旋、自适应、锁消除、锁粗化等优化手段来提升代码执行效率。

1.1 自旋锁和自适应自旋

现在大多的处理器都是多核处理器 ，如果在多核心处理器，有让两个或者以上的线程并行执行，我们可以让一个等待线程不放弃处理器的执行时间。设置一个等待超时时间，看线程是否能够很快的释放锁，在等等待的这段时间可以执行一个空循环，让当前线程继续占用 CPU 的时间片。这就是所谓的「自旋锁」。

JVM 中可以通过 +XX:UseSpinning来开启自旋锁，在 JDK1.6 过后默认为我们开启。由于自旋锁的使用会让锁的竞争者占用更多的处理器时间， JVM 规定了一个自旋次数的一个参数。我们可以通过 -XX:PreBlockSping来进行更改（默认10次）。

偏向锁、轻量级锁的状态转化及对象 Mark Word 的关系转换入下图所示：

1.2 锁消除

锁消除是指虚拟机即时编译器在运行时检测到某段需要同步的代码不可能存在共享数据竞争而实施的一种对锁进行消除的优化策略。锁消除的主要判断依据于逃逸分析。如果判断一段代码，在堆上所有的数据都不会逃逸出去被别的线程访问到，那就把它当作栈上的数据对待，认为它们是私有的，同步加锁就无需进行。

下面是三个字符串 x, y, z 相加的例子，无论是从源代码上还是逻辑上都没有进行同步：

public String concatStr(String x, String y, String z) {
    return  x + y + z;
}

String 是一个不可变的类，对字符的链接总是生成新的 String 对象来进行的，因此 Javac 编译器会对 String 链接进行自动优化，在 JDK5 之前字符串链接会转换为 StringBuffer；在 JDK5 之后会转换为 StringBuilder 对象连续的 append()操作，我们看看 javac 过后，反编译的结果:

public String concatStr(String x, String y, String z) {
    StringBuilder sb = new StringBuilder();
    sb.append(x);
    sb.append(y);
    sb.append(z);
    return  sb.toString();
}

我们再来看看 javap 反编译的结果：

这里大家可能会担心 StringBuilder 不是线程安全的的操作会存在线程安全的问题吗？这里的答案是不会，x + y + z 操作的优化「经过逃逸分析」过后，他的动态作用域被限制在了 concatStr方法内，就是说当前实际执行的 StringBuilder 的操作在 concatStr 方法内部，「其他的外部线程无法访问」到，所以这里「虽然有锁，但是可以被安全的消除掉。所以当我们进行编译过后，这段代码就会忽略掉所有的同步措施直接执行。」

1.3 锁粗化

原则上，我们在写代码的时候，总是推荐将同步块的作用范围限制得尽可能的小--只在共享数据的实际操作作用域中才进行同步，这样也是为了使得需要同步的操作尽可能的变少，即使存在锁的竞争，等待的锁的线程也能很快的获取到锁。大多数情况下，上面的原则都是正确的，但是如果「一系列的连续操作都是对同一个对象反复加锁和解锁，甚至加锁操作时出现在循环体之中」的，那即使没有线程的竞争，频繁的进行相互操作也会导致不必需要的性能损耗。

StringBuffer buffer = new StringBuffer();
/**  锁粗化 */ 
public void append(){
    buffer.append("aaa").append(" bbb").append(" ccc"); 
}

上面的代码每次调用 buffer.append 方法都需要加锁和解锁，如果 JVM 家册到有一串连续的对同一个对象加锁和解锁的操作，就会将其合并成一次范围更大的加锁解锁操作，即在第一个 append 方法执行的时候进行加锁，最后一个 append 方法结束后进行解锁。

2 逃逸分析

逃逸分析（Escape Analysis），是一种可能减少有效 Java 程序中同步负载和内存堆分配压力的跨全局函数数据流分析算法。通过逃逸分析， Java Hotspot 编译器能够分析出一个新的对象引用范围从而决定是否要将这个对象分配到堆上，「逃逸分析的基本行为就是分析对象的动态作用域。」

2.1 方法逃逸

当一个对象在方法里面被定义后，它可能被外部方法所引用，例如调用参数传递到其他方法中，这种称为方法逃逸。

例如：

    public static StringBuffer craeteStringBuffer(String s1, String s2) {

            StringBuffer sb = new StringBuffer();

            sb.append(s1);

            sb.append(s2);

            return sb;

        }

StringBuffer sb是一个方法内部变量，上述代码中直接将sb返回，这样这个StringBuffer有可能被其他方法所改变，这样它的作用域就不只是在方法内部，虽然它是一个局部变量，称其逃逸到了方法外部。

甚至还有可能被外部线程访问到，譬如赋值给类变量或可以在其他线程中访问的实例变量，称为线程逃逸。

上述代码如果想要StringBuffer sb不逃出方法，可以这样写：

    public static String createStringBuffer(String s1, String s2) {

            StringBuffer sb = new StringBuffer();

            sb.append(s1);

            sb.append(s2);

            return sb.toString();

        }

不直接返回 StringBuffer，那么StringBuffer将不会逃逸出方法。

如果能证明一个对象不会逃逸到方法或线程外，则可能为这个变量进行一些高效的优化。

2.2 线程逃逸

当一个对象可能被外部线程访问到，比如：赋值给其他线程中访问的实例变量，这种称为线程逃逸。

2.3 通过逃逸分析，编译器对代码的优化

如果能够证明一个对象不会逃逸到到方法外或线程外（其他线程方法或者线程无法通过任何方法访问该变量），或者逃逸程度比较低（只逃逸出方法而不逃逸出线程）则可以对这个对象采用不同程度的优化：

1. 栈上分配（Stack Allocations）完全不会逃逸的局部变量和不会逃逸出线程的对象，采用栈上分配，对象就会跟随方法的结束自动销毁。以减少垃圾回收器的压力。

2. 标量替换（Scalar Replacement）有个对象可能不需要作为一个连续的存储结果存储也能被访问到，那么对象的部分（或者全部）可以不存储在内存，而是存储在 CPU 寄存器中。

3. 同步消除（Synchronization Elimination）如果一个对象发现只能在一个线程访问到，那么这个对象的操作可以考虑不同步。

总结：

虽然概念上的JVM总是在Java堆上为对象分配空间，但并不是说完全依照概念的描述去实现；只要最后实现处理的“可见效果”与概念中描述的一直就没问题了。所以说，“you can cheat as long as you don’t get caught”。Java对象在实际的JVM实现中可能在GC堆上分配空间，也可能在栈上分配空间，也可能完全就消失了。这种行为从Java源码中看不出来，也无法显式指定，只是聪明的JVM自动做的优化而已。

但是逃逸分析会有时间消耗，所以性能未必提升多少，并且由于逃逸分析比较耗时，目前的实现都是采用不那么准确但是时间压力相对较小的算法来完成逃逸分析，这就可能导致效果不稳定，要慎用。

由于HotSpot虚拟机目前的实现方法导致栈上分配实现起来比较复杂，因为在HotSpot中暂时还没有做这项优化。