【JVM学习】——本地方法栈、堆

时间 2020-10-11

标签 java 算法编程数组缓存安全 bash 数据结构多线程并发栏目 Java 繁體版

原文原文链接

1、本地方法栈

1.1 本地方法接口

（1）什么是本地方法

简单地讲，一个Native Method就是一个Java调用非Java代码的接囗。该方法的实现由非Java语言实现，好比C。这个特征并不是Java所特有，不少其它的编程语言都有这一机制，好比在C++中，你能够用extern "C" 告知C++编译器去调用一个C的函数。java

"A native method is a Java method whose implementation is provided by non-java code."算法

在定义一个native method时，并不提供实现体（有些像定义一个Java interface），由于其实现体是由非java语言在外面实现的。编程

例如java.lang.Object中的public final native Class<?> getClass()方法；又如java.lang.Thread中的private native void start0()方法... ...数组

本地接口的做用是融合不一样的编程语言为Java所用，它的初衷是融合C/C++程序。缓存

Tips：标识符native能够与其它java标识符连用，abstract除外。

（2）为何使用本地方法

与Java环境的交互安全

有时Java应用须要与Java外面的环境交互，这是本地方法存在的主要缘由。你能够想一想Java须要与一些底层系统，如操做系统或某些硬件交换信息时的状况。本地方法正是这样一种交流机制：它为咱们提供了一个很是简洁的接口，并且咱们无需去了解Java应用以外的繁琐的细节。bash

与操做系统的交互数据结构

JVM支持着Java语言自己和运行时库，它是Java程序赖以生存的平台，它由一个解释器（解释字节码）和一些链接到本地代码的库组成。然而无论怎样，它毕竟不是一个完整的系统，它常常依赖于一底层系统的支持。这些底层系统经常是强大的操做系统。经过使用本地方法，咱们得以用Java实现了jre的与底层系统的交互，甚至JVM的一些部分就是用C写的。还有，若是咱们要使用一些Java语言自己没有提供封装的操做系统的特性时，咱们也须要使用本地方法。多线程

Sun's Java并发

Sun的解释器是用C实现的，这使得它能像一些普通的C同样与外部交互。jre大部分是用Java实现的，它也经过一些本地方法与外界交互。例如：类java.lang.Thread的setpriority()方法是用Java实现的，可是它实现调用的是该类里的本地方法setpriority()。这个本地方法是用C实现的，并被植入JVM内部，在Windows 95的平台上，这个本地方法最终将调用Win32 setpriority() ApI。这是一个本地方法的具体实现由JVM直接提供，更多的状况是本地方法由外部的动态连接库（external dynamic link library）提供，而后被JVw调用。

现状

目前这类方法使用的愈来愈少了，除非是与硬件有关的应用，好比经过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。由于如今的异构领域间的通讯很发达，好比可使用Socket通讯，也可使用Web Service等等，很少作介绍。

1.2 本地方法栈

Java虚拟机栈于管理Java方法的调用，而本地方法栈（Native Method Stack）用于管理本地方法的调用。

本地方法栈，也是线程私有的。

容许被实现成固定或者是可动态扩展的内存大小。（在内存溢出方面是相同的）

若是线程请求分配的栈容量超过本地方法栈容许的最大容量，Java虚拟机将会抛出一个stackoverflowError 异常。
若是本地方法栈能够动态扩展，而且在尝试扩展的时候没法申请到足够的内存，或者在建立新的线程时没有足够的内存去建立对应的本地方法栈，那么Java虚拟机将会抛出一个outofMemoryError异常。

本地方法是使用C语言实现的。

它的具体作法是Native Method Stack中登记native方法，在Execution Engine 执行时加载本地方法库。

当某个线程调用一个本地方法时，它就进入了一个全新的而且再也不受虚拟机限制的世界。它和虚拟机拥有一样的权限。

本地方法能够经过本地方法接口来访问虚拟机内部的运行时数据区。
它甚至能够直接使用本地处理器中的寄存器
直接从本地内存的堆中分配任意数量的内存。

并非全部的JVM都支持本地方法。由于Java虚拟机规范并无明确要求本地方法栈的使用语言、具体实现方式、数据结构等。若是JVM产品不打算支持native方法，也能够无需实现本地方法栈。

在Hotspot JVM中，直接将本地方法栈和虚拟机栈合二为一。

2、堆核心概述

2.1 堆内存细分

一个进程只有一个JVM，一个JVM实例只存在一个堆内存。可是进程可包含多个线程，他们是共享同一堆空间的。

Java堆区（Heap）在JVM启动的时候即被建立时就肯定了空间大小，是JVM管理的最大一块内存空间。《Java虚拟机规范》规定，堆能够处于物理上不连续的内存空间中，但在逻辑上被视为连续的。全部的对象实例以及数组都应当在运行时分配在堆上。更准确说法是——“几乎”全部的对象实例都在这里分配内存。

由于还有一些对象是在栈上分配的。数组和对象可能永远不会存储在栈上，由于栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。

Java 7及以前堆内存逻辑上分为三部分：新生区+养老区+永久区

新生区	养老区	永久区
Young Generation Space	Tenure generation space	Permanent Space
Young/New（又被划分为Eden区和Survivor区）	Old/Tenure	Perm

Java 8及以后堆内存逻辑上分为三部分：新生区+养老区+元空间

新生区	养老区	元空间
Young Generation Space	Tenure generation space	Meta Space
Young/New（又被划分为Eden区和Survivor区）	Old/Tenure	Meta

其中，新生区=新生代=年轻代；养老区=老年区=老年代；永久区=永久代。

2.2 设置堆内存大小

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，你们能够经过选项"-Xmx"和"-Xms"来进行设置。例如：

-Xms10m：最小堆内存 -Xmx10m：最大堆内存

“-Xms"用于表示堆区的起始内存，等价于-XX:InitialHeapSize
“-Xmx"则用于表示堆区的最大内存，等价于-XX:MaxHeapSize

一旦堆区中的内存大小超过“-Xmx"所指定的最大内存时，将会抛出OutofMemoryError异常（俗称OOM异常）。

一般会将-Xms和-Xmx两个参数配置相同的值，其目的是为了可以在Java垃圾回收机制清理完堆区后不须要从新分隔计算堆区的大小，从而提升性能。

默认状况：

初始内存大小：物理电脑内存大小 / 64
最大内存大小：物理电脑内存大小 / 4

/**
 * -Xms 用来设置堆空间（年轻代+老年代）的初始内存大小
 *  -X：是jvm运行参数
 *  ms：memory start
 * -Xmx：用来设置堆空间（年轻代+老年代）的最大内存大小
 */
public class HeapSpaceInitial {
    public static void main(String[] args) {
        // 返回Java虚拟机中的堆内存总量
        long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
        // 返回Java虚拟机试图使用的最大堆内存
        long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
        System.out.println("-Xms:" + initialMemory + "M");
        System.out.println("-Xmx:" + maxMemory + "M");
    }
}

输出结果：

-Xms:243M
-Xmx:3591M
系统内存大小：15.1875G
系统内存大小：14.02734375G

查看堆内存的内存分配

方法一：CMD敲入命令jps——>jstat -gc 进程id

方法二：配置VM option时加上-XX:+PrintGCDetails

2.4 年轻代与老年代

从生命周期角度可将存储在JVM中的Java对象能够被划分为两类：

一类是生命周期较短的瞬时对象，这类对象的建立和消亡都很是迅速（生命周期短的，及时回收便可）
另一类对象的生命周期却很是长，在某些极端的状况下还可以与JVM的生命周期保持一致

根据存储对象的不一样，Java堆区便划分为年轻代（YoungGen）和老年代（OldGen）。其中年轻代又能够划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫作from区、to区）。

配置新生代与老年代堆结构的占比：

默认-XX:NewRatio=2，表示新生代占占整个堆的1/3，老年代占2/3。
能够修改-XX:NewRatio=4，表示新生代占整个堆的1/5，老年代占4/5。

Tips：生命周期长的对象偏多，就能够经过调整老年代的大小，来进行调优。

在新生代中，Eden空间和另外两个survivor空间所占的比例默认是8：1：1。

-XX:-UseAdaptiveSizePolicy：关闭自适应的内存分配策略。能够经过选项-XX:SurvivorRatio调整这个空间比例。（实际比例不是8：1：1，如要肯定是8：1：1须要指定-XX:SurvivorRatio=8）

几乎全部的Java对象都是在Eden区被new出来的。绝大部分的Java对象的销毁都在新生代进行了。（有些大的对象在Eden区没法存储时候，将直接进入老年代）

可使用选项"-Xmn"设置新生代最大内存大小。

2.5 堆对象分配过程

（1）概念

为新对象分配内存是一件很是严谨和复杂的任务，JVM的设计者们不只须要考虑内存如何分配、在哪里分配等问题，而且因为内存分配算法与内存回收算法密切相关，因此还须要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。

new的对象先放Eden区。
当Eden区的空间填满时，程序还需建立对象，JVM的垃圾回收器将对Eden区进行垃圾回收（MinorGC，又称YGC），将Eden区中的再也不被其余对象所引用的对象进行销毁，再加载新的对象放到Eden区。
而后将Eden区中的幸存的对象移动到From区（Survivor From区）。
若是再次触发垃圾回收，此时Eden区和From区幸存下来的对象就会放到To区（Survivor To区）。
- 此过程后From区对象都放到To区，故From区变To区，原To区变From区。
若是再次经历垃圾回收，此时Eden区对象会从新放回From区，接着再去To区。
啥时候能去养老区呢？当Survivor中的对象的年龄达到15的时候，将会触发一次 Promotion晋升的操做，对象晋升至养老区。能够设置次数：-Xx:MaxTenuringThreshold= N，默认是15次。
当养老区内存不足时，再次触发垃圾回收（Major GC），进行养老区的内存清理。
若养老区执行了Major GC以后，发现依然没法进行对象的保存，就会产生OOM异常。

特别注意，在Eden区满了的时候，才会触发MinorGC；而幸存者区满了后，不会触发MinorGC操做。若是Survivor区满了后，将会触发一些特殊的规则，也就是可能直接晋升老年代。

（2）对象分配的特殊状况

代码演示对象分配过程

public class HeapInstanceTest {
    byte[] buffer = new byte[new Random().nextInt(1024 * 200)];

    public static void main(String[] args) throws InterruptedException {
        ArrayList<HeapInstanceTest> list = new ArrayList<>();
        while (true) {
            list.add(new HeapInstanceTest());
            Thread.sleep(10);
        }
    }
}

而后设置JVM参数

-Xms600m -Xmx600m

执行上面代码，经过VisualGC进行动态化查看。最终，老年代和新生代都满了，出现OOM错误：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at com.kai.jvm.HeapInstanceTest.<init>(HeapInstanceTest.java:12)
    at com.kai.jvm.HeapInstanceTest.main(HeapInstanceTest.java:17)

（3）经常使用的调优工具

JDK命令行
Eclipse：Memory Analyzer Tool
Jconsole
Visual VM（实时监控推荐）
Jprofiler（推荐）
Java Flight Recorder（实时监控）
GCViewer
GCEasy

总结

针对幸存者S0，S1区：复制以后有交换，谁空谁是To区。
关于垃圾回收：频繁在新生区收集，不多在老年代收集，几乎再也不永久代和元空间进行收集。
新生代采用复制算法的目的：是为了减小内碎片。

2.6 Minor GC，Major GC、Full GC

Minor GC：新生代的GC
Major GC：老年代的GC
Full GC：整堆收集，收集整个Java堆和方法区的垃圾收集

Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上

JVM在进行GC时，并不是每次都对上面三个内存区域（新生代，老生代；方法区）一块儿回收的，大部分时候回收的都是指新生代。针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（Full GC）。

部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：

新生代收集（Minor GC/Young GC）：只是新生代的垃圾收集
老年代收集（Major GC/Old GC）：只是老年代的圾收集。
- 目前，只有CMS GC会有单独收集老年代的行为。
- 注意，不少时候Major GC会和Full GC混淆使用，须要具体分辨是老年代回收仍是整堆回收。
混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。
- 目前，只有G1 GC会有这种行为

整堆收集：收集整个java堆和方法区的垃圾收集。

（1）Minor GC

当年轻代空间不足时，就会触发Minor GC，这里的年轻代指的是Eden满，Survivor满不会引起GC。（每次Minor GC会清理年轻代的内存。）

由于Java对象大多都具有 朝生夕灭 的特性，因此Minor GC很是频繁，通常回收速度也比较快。这必定义既清晰又易于理解。

Minor GC会引起STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行

STW：stop the word

（2）Major GC

指发生在老年代的GC，对象从老年代消失时，咱们说 “Major GC” 或 “Full GC” 发生了。

出现了MajorGc，常常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）

也就是在老年代空间不足时，会先尝试触发Minor GC。若是以后空间还不足，则触发Major GC。

Major GC的速度通常会比Minor GC慢10倍以上，STW的时间更长，若是Major GC后，内存还不足，就报OOM了。

（3）Full GC

触发Fu11 GC执行的状况有以下五种：

调用System.gc()时，系统建议执行Fu11 GC，可是没必要然执行。
老年代空间不足
方法区空间不足
经过Minor GC后进入老年代的平均大小大于老年代的可用内存
由Eden区、survivor space0（From Space）区向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。

说明：Full GC 是开发或调优中尽可能要避免的。这样暂时时间会短一些。

GC 举例

不断的建立字符串是存放在堆区元空间中：

public class GCTest {
    public static void main(String[] args) {
        int i = 0;
        try {
            List<String> list = new ArrayList<>();
            String a = "Hello World!";
            while(true) {
                list.add(a);
                a = a + a;
                i++;
            }
        }catch (Exception e) {
            e.getStackTrace();
        }
    }
}

设置JVM启动参数：

-Xms10m -Xmx10m -XX:+PrintGCDetails

打印出日志：

[GC (Allocation Failure) [PSYoungGen: 1996K->480K(2560K)] 1996K->872K(9728K), 0.0010677 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2460K->472K(2560K)] 2852K->2304K(9728K), 0.0007179 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 2061K->440K(2560K)] 3893K->3040K(9728K), 0.0007400 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [PSYoungGen: 1322K->472K(2560K)] 6994K->6152K(9728K), 0.0014277 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 472K->0K(2560K)] [ParOldGen: 5680K->3698K(7168K)] 6152K->3698K(9728K), [Metaspace: 3209K->3209K(1056768K)], 0.0039549 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1609K->0K(2560K)] [ParOldGen: 6770K->6750K(7168K)] 8380K->6750K(9728K), [Metaspace: 3262K->3262K(1056768K)], 0.0048638 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 6750K->6750K(9728K), 0.0003074 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 6750K->6732K(7168K)] 6750K->6732K(9728K), [Metaspace: 3262K->3262K(1056768K)], 0.0050359 secs] [Times: user=0.11 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 2560K, used 114K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
  eden space 2048K, 5% used [0x00000000ffd00000,0x00000000ffd1cac8,0x00000000fff00000)
  from space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000)
  to   space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
 ParOldGen       total 7168K, used 6732K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
  object space 7168K, 93% used [0x00000000ff600000,0x00000000ffc93090,0x00000000ffd00000)
 Metaspace       used 3321K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 362K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOfRange(Arrays.java:3664)
    at java.lang.String.<init>(String.java:207)
    at java.lang.StringBuilder.toString(StringBuilder.java:407)
    at com.kai.jvm.GCTest.main(GCTest.java:19)

触发OOM的时候，必定是进行了一次Full GC，由于只有在老年代空间不足时候，才会爆出OOM异常。

3、堆空间分代

3.1 堆空间分代思想

为何要把Java堆分代？不分代就不能正常工做了吗？经研究，不一样对象的生命周期不一样。70%-99%的对象是临时对象。

新生代：有Eden、两块大小相同的survivor（又称为from/to，s0/s1）构成，to总为空。
老年代：存放新生代中经历屡次GC仍然存活的对象。

其实不分代彻底能够，分代的惟一理由就是优化GC性能。若是没有分代，那全部的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的全部区域进行扫描。而不少对象都是朝生夕死的，若是分代的话，把新建立的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

3.2 内存分配策略

若是对象在Eden出生并通过第一次Minor GC后仍然存活，而且能被Survivor容纳的话，将被移动到survivor空间中，并将对象年龄设为1。对象在survivor区中每熬过一次MinorGC，年龄就增长1岁，当它的年龄增长到必定程度（默认为15岁，其实每一个JVM、每一个GC都有所不一样）时，就会被晋升到老年代

对象晋升老年代的年龄阀值，能够经过选项-XX:MaxTenuringThreshold来设置

针对不一样年龄段的对象分配原则以下所示：

优先分配到Eden
- 开发中比较长的字符串或者数组，会直接存在老年代，可是由于新建立的对象都是朝生夕死的，因此这个大对象可能也很快被回收，可是由于老年代触发Major GC的次数比 Minor GC要更少，所以可能回收起来就会比较慢
大对象直接分配到老年代
- 尽可能避免程序中出现过多的大对象
长期存活的对象分配到老年代
动态对象年龄判断
- 若是survivor区中相同年龄的全部对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象能够直接进入老年代，无须等到MaxTenuringThreshold 中要求的年龄。

空间分配担保：-XX:HandlePromotionFailure

也就是通过Minor GC后，全部的对象都存活，由于Survivor比较小，因此就须要将Survivor没法容纳的对象，存放到老年代中。

3.3 对象分配内存：TLAB

问题：堆空间都是共享的么？

不必定，由于还有TLAB这个概念，在堆中划分出一块区域，为每一个线程所独占。

为何有TLAB？

TLAB：Thread Local Allocation Buffer，也就是为每一个线程单独分配了一个缓冲区。

堆区是线程共享区域，任何线程均可以访问到堆区中的共享数据。因为对象实例的建立在JVM中很是频繁，所以在并发环境下从堆区中划份内存空间是线程不安全的。为避免多个线程操做同一地址，须要使用加锁等机制，进而影响分配速度。

什么是TLAB

从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每一个线程分配了一个私有缓存区域，它包含在Eden空间内。

多线程同时分配内存时，使用TLAB能够避免一系列的非线程安全问题，同时还可以提高内存分配的吞吐量，所以咱们能够将这种内存分配方式称为快速分配策略。

全部OpenJDK衍生出来的JVM都提供了TLAB的设计。

尽管不是全部的对象实例都可以在TLAB中成功分配内存，但JVM确实是将TLAB做为内存分配的首选。

在程序中，开发人员能够经过选项-XX:UseTLAB设置是否开启TLAB空间。默认状况下，TLAB空间的内存很是小，仅占有整个Eden空间的1%，固然咱们能够经过选项-XX:TLABWasteTargetPercent设置TLAB空间所占用Eden空间的百分比大小。

一旦对象在TLAB空间分配内存失败时，JVM就会尝试着经过使用加锁机制确保数据操做的原子性，从而直接在Eden空间中分配内存。

TLAB分配过程

对象首先是经过TLAB开辟空间，若是不能放入，那么须要经过Eden来进行分配。

3.4 堆空间的参数设置

-XX:+PrintFlagsInitial：查看全部的参数的默认初始值
-XX:+PrintFlagsFinal：查看全部的参数的最终值（可能会存在修改，再也不是初始值）
-Xms：初始堆空间内存（默认为物理内存的1/64）
-Xmx：最大堆空间内存（默认为物理内存的1/4）
-Xmn：设置新生代的大小。（初始值及最大值）
-XX:NewRatio：配置新生代与老年代在堆结构的占比
-XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
-XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
-XX:+PrintGCDetails：输出详细的GC处理日志
- 打印GC简要信息：①-XX:+PrintGC ② - verbose:gc
-XX:HandlePromotionFalilure：是否设置空间分配担保

在发生Minor GC以前，虚拟机会检查老年代最大可用的连续空间是否大于新生代全部对象的总空间。

若是大于，则这次Minor GC是安全的。
若是小于，则虚拟机会查看-XX:HandlePromotionFailure设置值是否允担保失败。
- 若是HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
- 若是大于，则尝试进行一次Minor GC，但此次Minor GC依然是有风险的；
- 若是小于，则改成进行一次Full GC。
- 若是HandlePromotionFailure=false，则改成进行一次Full GC。

在JDK6 Update24以后，HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察openJDK中的源码变化，虽然源码中还定义了HandlePromotionFailure参数，可是在代码中已经不会再使用它。JDK6 Update 24以后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，不然将进行FullGC。

3.5 逃逸分析

（1）概述

在《深刻理解Java虚拟机》中关于Java堆内存有这样一段描述：

随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会致使一些微妙的变化，全部的对象都分配到堆上也渐渐变得不那么“绝对”了。

在Java虚拟机中，对象是在Java堆中分配内存的，这是一个广泛的常识。可是，有一种特殊状况，那就是若是通过逃逸分析（Escape Analysis）后发现，一个对象并无逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最多见的堆外存储技术。

此外，前面提到的基于openJDk深度定制的TaoBaovm，其中创新的GCIH（GC invisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，而且GC不能管理GCIH内部的Java对象，以此达到下降GC的回收频率和提高GC的回收效率的目的。

如何将堆上的对象分配到栈，须要使用逃逸分析手段。

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

当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如做为调用参数传递到其余地方中。

逃逸分析举例

没有发生逃逸的对象，则能够分配到栈上，随着方法执行的结束，栈空间就被移除。

public void my_method() {
    V v = new V();
    // use v
    // ....
    v = null;
}

针对下面的代码

public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}

若是想要StringBuffer sb不发生逃逸，能够这样写

public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}

完整的逃逸分析代码举例

public class EscapeAnalysis {

    public EscapeAnalysis obj;

    /**
     * 方法返回EscapeAnalysis对象，发生逃逸
     * @return
     */
    public EscapeAnalysis getInstance() {
        return obj == null ? new EscapeAnalysis():obj;
    }

    /**
     * 为成员属性赋值，发生逃逸
     */
    public void setObj() {
        this.obj = new EscapeAnalysis();
    }

    /**
     * 对象的做用于仅在当前方法中有效，没有发生逃逸
     */
    public void useEscapeAnalysis() {
        EscapeAnalysis e = new EscapeAnalysis();
    }

    /**
     * 引用成员变量的值，发生逃逸
     */
    public void useEscapeAnalysis2() {
        EscapeAnalysis e = getInstance();
        // getInstance().XXX  发生逃逸
    }
}

在JDK 1.7 版本以后，HotSpot中默认就已经开启了逃逸分析

若是使用的是较早的版本，则能够经过：

选项-XX:+DoEscapeAnalysis显式开启逃逸分析
经过选项-xx:+PrintEscapeAnalysis查看逃逸分析的筛选结果

结论：开发中能使用局部变量的，就不要使用在方法外定义。

使用逃逸分析，编译器能够对代码作以下优化：

栈上分配：将堆分配转化为栈分配。若是一个对象在子程序中被分配，要使指向该对象的指针永远不会发生逃逸，对象多是栈上分配的候选，而不是堆上分配
同步省略：若是一个对象被发现只有一个线程被访问到，那么对于这个对象的操做能够不考虑同步。
分离对象或标量替换：有的对象可能不须要做为一个连续的内存结构存在也能够被访问到，那么对象的部分（或所有）能够不存储在内存，而是存储在CPU寄存器中。

（2）栈上分配

JIT编译器在编译期间根据逃逸分析的结果，发现若是一个对象并无逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。

常见的栈上分配的场景：给成员变量赋值、方法返回值、实例引用传递。

举例

咱们经过举例来讲明开启逃逸分析和未开启逃逸分析时候的状况

public class StackAllocation {
    public static void main(String[] args) throws InterruptedException {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 100000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为：" + (end - start) + " ms");

        // 为了方便查看堆内存中对象个数，线程sleep
        Thread.sleep(10000000);
    }

    private static void alloc() {
        User user = new User();
    }
}
class User {
    private String name;
    private String age;
    private String gender;
    private String phone;
}

设置JVM参数，未开启逃逸分析：

-Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails

运行结果，同时还触发了GC操做：

花费的时间为：366 ms

而后查看内存的状况，发现有大量的User存储在堆中。

咱们再开启逃逸分析：

-Xmx1G -Xms1G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails

而后查看运行时间，咱们可以发现花费的时间快速减小，同时不会发生GC操做。

花费的时间为：5 ms

而后再看内存状况，咱们发现只有不多的User对象，说明User发生了逃逸，由于他们存储在栈中，随着栈的销毁而消失。

（3）同步省略

线程同步的代价是至关高的，同步的后果是下降并发性和性能。

在动态编译同步块的时候，JIT编译器能够借助逃逸分析来判断同步块所使用的锁对象是否只可以被一个线程访问而没有被发布到其余线程。若是没有，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提升并发性和性能。这个取消同步的过程就叫同步省略，也叫锁消除。

例以下面的代码：

public void f() {
    Object hollis = new Object();
    synchronized(hollis) {
        System.out.println(hollis);
    }
}

代码中对hollis这个对象加锁，可是hollis对象的生命周期只在f()方法中，并不会被其余线程所访问到，因此在JIT编译阶段就会被优化优化成：

public void f() {
    Object hollis = new Object();
    System.out.println(hollis);
}

咱们将其转换成字节码：

（4）分离对象和标量替换

标量（scalar）是指一个没法再分解成更小的数据的数据。Java中的原始数据类型就是标量。

相对的，那些还能够分解的数据叫作聚合量（Aggregate），Java中的对象就是聚合量，由于他能够分解成其余聚合量和标量。

在JIT阶段，若是通过逃逸分析，发现一个对象不会被外界访问的话，那么通过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

参数-XX:+EliminateAllocations开启标量替换（默认打开），容许对象打散分配在栈上。

public static void main(String args[]) {
    alloc();
}
class Point {
    private int x;
    private int y;
}
private static void alloc() {
    Point point = new Point(1,2);
    System.out.println("point.x" + point.x + ";point.y" + point.y);
}

以上代码，通过标量替换后，就会变成

private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x = " + x + "; point.y=" + y);
}

能够看到，Point这个聚合量通过逃逸分析后，发现他并无逃逸，就被替换成两个聚合量了。那么标量替换有什么好处呢？就是能够大大减小堆内存的占用。由于一旦不须要建立对象了，那么就再也不须要分配堆内存了。
标量替换为栈上分配提供了很好的基础。

代码优化之标量替换

public class ScalarReplaceTest {
    public static class User {
        private int age;
        private String name;
    }

    private static void alloc() {
        User user = new User(); //未发生逃逸
        user.age = 20;
        user.name = "张三";
    }

    public static void main(String args[]) {
        long start = System.currentTimeMillis();

        for (int i = 0; i < 100000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花费时间：" + (end - start) + "ms");
    }
}

上述代码在主函数中进行了1亿次alloc。调用进行对象建立，因为User对象实例须要占据约16字节的空间，所以累计分配空间达到将近1.5GB。若是堆空间小于这个值，就必然会发生GC。使用以下参数运行上述代码：

-server -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations

这里设置参数以下：

参数-server：启动Server模式，由于在server模式下，才能够启用逃逸分析。
参数-XX:+DoEscapeAnalysis：启用逃逸分析
参数-Xmx10m：指定了堆空间最大为10MB
参数-XX:+PrintGC：将打印GC日志。
参数-xx：+EliminateAllocations：开启了标量替换（默认打开），容许将对象打散分配在栈上，好比对象拥有id和name两个字段，那么这两个字段将会被视为两个独立的局部变量进行分配

逃逸分析的不足

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

其根本缘由就是没法保证逃逸分析的性能消耗必定能高于他的消耗。虽然通过逃逸分析能够作标量替换、栈上分配、和锁消除。可是逃逸分析自身也是须要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
一个极端的例子，就是通过逃逸分析以后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

虽然这项技术并不十分红熟，可是它也是即时编译器优化技术中一个十分重要的手段。注意到有一些观点，认为经过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，可是取决于JVM设计者的选择。Oracle Hotspot JVM中并未这么作，这一点在逃逸分析相关的文档里已经说明，因此能够明确全部的对象实例都是建立在堆上。

目前不少书籍仍是基于JDK7之前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。可是，intern字符串缓存和静态变量并非被转移到元数据区，而是直接在堆上分配，因此这一点一样符合前面的结论：对象实例都是分配在堆上。

参考

深刻理解Java虚拟机：JVM高级特性与最佳实践（第3版）