共计 16575 个字符，预计需要花费 42 分钟才能阅读完成。
一、本地办法栈
1.1 本地办法接口
（1）什么是本地办法
简略地讲，一个 Native Method 就是一个 Java 调用非 Java 代码的接囗。该办法的实现由非 Java 语言实现，比方 C。这个特色并非 Java 所特有，很多其它的编程语言都有这一机制，比方在 C ++ 中，你能够用 extern “C” 告知 C ++ 编译器去调用一个 C 的函数。
“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 利用之外的繁琐的细节。
与操作系统的交互
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.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.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
- 打印 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 版）
