对象并不必定都是在堆上分配内存的

在《深刻理解 Java 虚拟机》中有这样一段话：
“随着 JIT 编译器的发展和逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会致使一些微妙的变化，全部的对象分配到堆上也渐渐不那么绝对了”。

逃逸分析

在编译期间，JIT 会对代码作不少优化，其中有一部分优化的目的就是减小内存堆分配的压力，其中一项重要的技术叫作逃逸分析。

• 方法逃逸
  逃逸分析基本行为就是分析对象动态做用域：当一个对象在方法中被定义后，它可能会被外部方法调用，例如做为调用参数传递到其余方法中，称为方法逃逸。

• 线程逃逸
  甚至还有可能被外部线程访问到，譬如复制给类变量或者在其余线程中访问的实例变量。成为线程逃逸。

• 目的
  经过逃逸分析，HotSpot 编译器可以分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上。

• 开启、关闭与查看
  在 JDK 6 Update 23 版本以后，HotSpot 中默认就开启了逃逸分析。
  开启： -XX: +DoEscapeAnalysis (只能在 server 模式下开启：-server)
  关闭： -XX: -DoEscapeAnalysis
  查看分析结果：-XX: +PrintEscapeAnalysis

优化手段

若是能证实一个对象不会逃逸到方法或线程以外，也就是别的方法或线程没法经过任何途径访问到这个对象，则可能为这个变量进行一些高效优化，以下所示：

1. 栈上分配(Stack Alloction)

• JVM中，在Java堆上分配建立对象的内存空间。Java堆中的对象对于各个线程都是共享和可见的，只要持有这个对象的引用，就能够访问堆中存储的对象数据。

• JVM中垃圾收系统能够回收堆中再也不使用的对象，但回收动做不管是筛选可回收对象，仍是回收和整理内存都须要耗费时间。

• 若是肯定一个对象不会逃逸出方法以外，那让这个对象在栈上分配内存将会是一个不错的主意，对象所占用的内存空间就能够随栈帧出栈而销毁。在通常应用中，不会逃逸的局部变量所占的比例很大，若是能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了，垃圾收集系统的压力将会小不少。

  TLAB 上分配

  • Thread Local Allocation Buffer，线程本地分配缓存。
  • 为了加速对象分配。因为对象通常在堆上，而堆是共享的，须要同步。
  • 占用 eden 区空间，在 TLAB 启用状况下，虚拟机会为每个线程分配一块 TLAB 空间。默认很小（2048）。
  • 开启/ 查看： -XX: +UserTLAB / -XX: +PrintTLAB
  • -XX:TLABSize 指定大小
  • -XX:-ResizeTLAB 大小会一直调整，能够禁止调整，一次性设置值。
  • 对象分配流程图

  

  1. 编译器经过逃逸分析，肯定对象是在栈上分配仍是在堆上分配。若是是在堆上分配，则进入选项 
  2.若是 tlab_top + size <= tlab_end，则在在 TLAB 上直接分配对象并增长 tlab_top 的值，若是现有的 TLAB 不足以存放当前对象则 
  3.从新申请一个 TLAB，并再次尝试存放当前对象。若是放不下，则 4
  4.在 Eden 区加锁（这个区是多线程共享的），若是 eden_top + size <= eden_end 则将对象存放在 Eden 区，增长 eden_top 的值，若是 Eden 区不足以存放，则 5
  5.执行一次 Young GC（minor collection）。
  6. 通过 Young GC 以后，若是 Eden 区仍然不足以存放当前对象，则直接分配到老年代。
  复制代码

2. 同步消除(Synchronization Elimination)

• 线程同步

  

  图11-2描述了两个线程读写相同变量的假设例子。
  在这个例子中，线程 A 读取变量而后给这个变量赋予一个新的值，但写操做须要两个存储器周期。
  当线程 B 在这两个存储器写周期中间读取这个相同的变量时，它就会获得不一致的值。
  
  为了解决这个问题，线程不得不使用锁，在同一时间只容许一个线程访问该变量。
  
  图 11-3 描述了这种同步。
  若是线程 B 但愿读取变量，它首先要获取锁；
  一样地，当线程 A 更新变量时，也须要获取这把一样的锁。
  于是线程 B 在线程 A 释放锁之前不能读取变量。
  复制代码

• 线程同步自己是一个相对耗时的过程，若是逃逸分析可以肯定一个变量不会逃逸出线程，没法被其余线程访问，那这个变量的读写确定就不会有竞争，对这个变量实施的同步措施也就能够消除掉。
• 开启：-XX: +EliminateAllocations
• 查看标量的替换状况：-XX: +PrintEliminateAllocations

3.标量替换(Scalar Replacement)

• 标量(Scalar)
  是一个数据已经没法再分解成更小的数据来表示了，JVM中的原始数据类型(int、long等数值类型以及reference类型等)都不能进一步分解，他们就能够成为标量。
• 聚合量(Aggregation)
  相对的，若是一个数据能够继续分解，那它就称为聚合量(Aggregation),Java中的对象就是最典型的聚合量。
• 标量替换
  若是把一个Java对象拆解，根据程序访问的状况，将其使用到的成员变量恢复原始类型来访问就叫作标量替换。
• 条件
  若是逃逸分析证实一个对象不会被外部访问，而且这个对象能够被拆解的话，那程序真正执行的时候将可能不在建立这个对象，而改成直接建立它的若干个被这个方法使用到的成员变量来代替。
• 优势
  将对象拆分后，除了可让对象的成员变量在栈上(栈上存储的数据，有很大的几率会被JVM分配至物理机的告诉寄存器中存储)分配合读写以外，还能够为后续进一步优化手段建立条件。
• 开启： -XX: +EliminateLocks
• 关闭： -XX: -EliminateLocks

并不成熟

关于逃逸分析的论文在 1999 年就已经发表了，但直到 JDK 1.6 才有实现，并且这项技术到现在也并非十分红熟的。

在很长的一段时间里，即便是Server Compiler，也默认不开启逃逸分析，甚至在某些版本(如 JDK 1.6 Update 18)中还曾经短暂地彻底禁止了这项优化。

其根本缘由就是没法保证逃逸分析的性能消耗必定能高于他的消耗。虽然通过逃逸分析能够作标量替换、栈上分配、和锁消除。可是逃逸分析自身也是须要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。

一个极端的例子，就是通过逃逸分析以后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

虽然这项技术并不十分红熟，可是他也是即时编译器优化技术中一个十分重要的手段，从性能分析中来看，使用逃逸分析的优化仍是颇有必要的。

参考来源：
周志明 《深刻理解Java虚拟机》
Java 中的逃逸分析和 TLAB 以及 Java 对象分配
关于栈上分配和 TLAB 的理解