JVM篇：堆-六虎

堆的核心概念

堆针对一个 JVM 进程来说是仅有的，也便是一个进程只需一个 JVM，可是进程包括多个线程，他们是同享同一堆空间的。

一个 JVM 实例只存在一个堆内存，堆也是 Java 内存办理的核心区域。

Java 堆区在 JVM 发动的时分即被创立，其空间巨细也就确认了。是 JVM 办理的最大一块内存空间。

堆内存的巨细是能够调节的

《Java 虚拟机标准》规定，堆能够处于物理上不接连的内存空间中，但在逻辑上它应该被视为接连的。

一切的线程同享 Java 堆，在这儿还能够划分线程私有的缓冲区（Thread Local Allocation Buffer，TLAB）。

-Xms10m：最小堆内存，这儿给 10M

-Xmx10m：最大堆内存，这儿给 10M

《Java 虚拟机标准》中对 Java 堆的描绘是：一切的目标实例以及数组都应当在运转时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）

我要说的是：「简直」一切的目标实例都在这儿分配内存。从实际运用视点看的。

由于还有一些目标是在栈上分配的

数组和目标或许永久不会存储在栈上，由于栈帧中保存引证，这个引证指向目标或许数组在堆中的方位。

在办法完毕后，堆中的目标不会立刻被移除，仅仅在废物搜集的时分才会被移除。

也便是触发了 GC 的时分，才会进行收回
假如堆中目标立刻被收回，那么用户线程就会收到影响，由于有 stop the word

堆，是 GC（Garbage Collection，废物搜集器）履行废物收回的要点区域。

代码示例：

public class SimpleHeap {
  private int id; // 特点、成员变量

  public SimpleHeap(int id) {
    this.id = id;
   }

  public void show() {
    System.out.println("My ID is " + id);
   }
  public static void main(String[] args) {
    SimpleHeap sl = new SimpleHeap(1);
    SimpleHeap s2 = new SimpleHeap(2);

    int[] arr = new int[10];

    Object[] arr1 = new Object[10];
   }
}

堆内存细分

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

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

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

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

后边的说法约好（下面的意思的表达都一样）：

重生区 == 重生代 == 年青代
养老区 == 晚年区 == 老时代 == 永久区 == 永久代

堆空间内部结构，JDK1.8 之前从永久代替换成元空间

PERMANENT 是永久区，METASPACE 是元空间。

JVisualVM可视化检查堆内存

public class HeapDemo {

  public static void main(String[] args) {
    System.out.println("start...");
    try {
      Thread.sleep(100000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
    System.out.println("end...");
   }
}

运用的东西处于 JDK 目录下的 bin 目录下的 jvisualvm.exe，双击翻开即可。

翻开后，装置插件

下图便是运用：Java VisualVM 检查堆空间的巨细

设置堆内存巨细与OOM

Java 堆区用于存储 Java 目标实例，那么堆的巨细在 JVM 发动时就现已设定好了，咱们能够经过选项 -Xmx 和 -Xms 来进行设置。

-Xms 用于标明堆区的起始内存，等价于 -XX:InitialHeapSize
-Xmx 则用于标明堆区的最大内存，等价于 -XX:MaxHeapSize

一旦堆区中的内存巨细超过 -xmx 所指定的最大内存时，将会抛出 OutofMemoryError 反常。

一般会将 -Xms 和 -Xmx 两个参数装备相同的值，其意图是 为了能够在 Java 废物收回机制整理完堆区后不需求从头分隔核算堆区的巨细，从而进步功能。

默许状况下

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

开发中主张将初始堆内存和最大的堆内存设置成相同的值。

设置堆内存

首要不设置堆内存参数

/**
 * 1. 设置堆空间巨细的参数
 * -Xms 用来设置堆空间（年青代 + 老时代）的初始内存巨细
 *    -X 是 jvm 的运转参数
 *    ms 是 memory start（内存开端）
 * -Xmx 用来设置堆空间（年青代 + 老时代）的最大内存巨细
 *
 * 2. 默许堆空间的巨细
 *   初始内存巨细：物理电脑内存巨细 / 64
 *       最大内存巨细：物理电脑内存巨细 / 4
 * 3. 手动设置：-Xms600m -Xmx600m
 *   开发中主张将初始堆内存和最大的堆内存设置成相同的值。
 *
 * 4. 检查设置的参数：办法一： jps / jstat -gc 进程 id
 *          办法二：-XX:+PrintGCDetails
 */
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");

    System.out.println("体系内存巨细为：" + initialMemory * 64.0 / 1024 + "G");
    System.out.println("体系内存巨细为：" + maxMemory * 4.0 / 1024 + "G");

    try {
      Thread.sleep(1000000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
   }
}

输出结果

-Xms: 243M
-Xmx: 3607M
体系内存巨细为：15.1875G
体系内存巨细为：14.08984375G

内存巨细小于 16GB，阐明操作体系自身还占有了一些。

设置堆内存参数再看

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");


    try {
      Thread.sleep(1000000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
   }
}

输出结果：

-Xms: 575M
-Xmx: 575M

为什么会少 25M 呢？

其实不是少了 25M，是核算公式的原因，下面咱们先检查堆内存的内存分配状况。

有两种办法：

办法一

# 指令 1
jps
# 下面一些堆内存的状况
# ......

# 指令 2：检查某个具体的堆内存
jstat -gc 进程id

SOC：S0 区一共容量
S1C：S1 区一共容量
S0U：S0 区运用的量
S1U：S1 区运用的量
EC：伊甸园区一共容量
EU：伊甸园区运用的量
OC：老时代一共容量
OU：老时代运用的量

下面咱们来对上面图给出的数据进行核算：

25600 + 25600 + 153600 + 409600 = 614400K

614400 /1024 = 600M

上面是咱们理想的核算公式，而实际的核算公式如下：

25600 + 153600 + 409600 = 588800K

588800 /1024 = 575M

原因：S0 区和 S1 区两个只需一个能运用，另一个暂时用不了

办法二：-XX:+PrintGCDetails

在设置 -Xms600m -Xmx600m 的时分，后边加一个空格后再加上 +PrintGCDetails，这样当程序完毕后，自动在控制台输入程序的堆内存巨细

OutOfMemory举例

先来张图的示例代码，下面有具体的代码：

咱们简略的写一个 OOM 比方

public class OOMTest {
  public static void main(String[] args) {
    ArrayList<Picture> list = new ArrayList<>();
    while(true){
      try {
        Thread.sleep(20);
       } catch (InterruptedException e) {
        e.printStackTrace();
       }
      list.add(new Picture(new Random().nextInt(1024 * 1024))); // 不断向堆空间参加数据
     }
   }
}

class Picture{
  private byte[] pixels;

  public Picture(int length) {
    this.pixels = new byte[length];
   }
}

然后设置 VM option 发动参数

-Xms600m -Xmx600m

运转后，就呈现 OOM 了，那么咱们能够经过 VisualVM 这个东西检查具体是什么参数构成的 OOM

另一种视点：

年青代与老时代

存储在 JVM 中的 Java 目标能够被划分为两类：

一类是生命周期较短的瞬时目标，这类目标的创立和消亡都非常迅速
- 生命周期短的，及时收回即可
另外一类目标的生命周期却非常长，在某些极点的状况下还能够与 JVM 的生命周期保持一致

Java 堆区进一步细分的话，能够划分为年青代（YoungGen）和老时代（OldGen）

其间年青代又能够划分为 Eden 空间、Survivor0 空间和 Survivor1 空间（有时也叫做 from 区、to 区）

下面这参数开发中一般不会调：

Eden : From : To 份额：8 : 1 : 1
重生代 : 老时代份额：1 : 2

装备重生代与老时代在堆结构的占比。

默许 -XX:NewRatio=2，标明重生代占 1，老时代占 2，重生代占整个堆的 1/3
能够修改 -XX:NewRatio=4，标明重生代占 1，老时代占 4，重生代占整个堆的 1/5

当发现在整个项目中，生命周期长的目标偏多，那么就能够经过调整 老时代的巨细，来进行调优

在 HotSpot 中，Eden 空间和另外两个 Survivor 空间缺省所占的份额是 8 : 1 : 1，当然开发人员能够经过选项 -xx:SurvivorRatio 调整这个空间份额。比方默许值 -xx:SurvivorRatio=8。

简直一切的 Java 目标都是在 Eden 区被 new 出来的。绝大部分的 Java 目标的毁掉都在重生代进行了。（有些大的目标在 Eden 区无法存储时分，将直接进入老时代）

IBM 公司的专门研讨标明，重生代中 80% 的目标都是「朝生夕死」的。

能够运用选项 -Xmn 设置重生代最大内存巨细，这个参数一般运用默许值就能够了。

/**
 * -Xms600m -Xmx600m
 *
 * -XX:NewRatio： 设置重生代与老时代的份额，默许值是 1:2
 * -XX:SurvivorRatio：设置重生代中 Eden 区与 Survivor 区的份额。默许值是 8
 * -XX:-UseAdaptiveSizePolicy：关闭自适应的内存分配战略  （暂时用不到）
 * -Xmn:设置重生代的空间的巨细。 （一般不设置）
 *
 */
public class EdenSurvivorTest {
  public static void main(String[] args) {
    System.out.println("我仅仅来打个酱油~");
    try {
      Thread.sleep(1000000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
   }
}

图解目标分配进程

概念

为新目标分配内存是一件非常谨慎和杂乱的使命，JVM 的规划者们不只需求考虑内存怎么分配、在哪里分配等问题，并且由于内存分配算法与内存收回算法密切相关，所以还需求考虑 GC 履行完内存收回后是否会在内存空间中产生内存碎片。

new 的目标先放伊甸园区。此区有巨细限制
当伊甸园的空间填满时，程序又需求创立目标，JVM 的废物收回器将对伊甸园区进行废物收回（Minor GC），将伊甸园区中的不再被其他目标所引证的目标进行毁掉。再加载新的目标放到伊甸园区
然后将伊甸园中的剩下目标移动到幸存者 0 区
假如再次触发废物收回，此刻前次幸存下来的放到幸存者 0 区的，假如没有收回，就会放到幸存者 1 区
假如再次阅历废物收回，此刻会从头放回幸存者 0 区，再产生再去幸存者 1 区，如此重复
啥时分能去养老区呢？能够设置次数。默许是 15 次
在养老区，相对清闲。当养老区内存缺乏时，触发 Major GC，进行养老区的内存整理
若养老区履行了 Major GC 之后，发现依然无法进行目标的保存，就会产生 OOM 反常

能够设置参数 -Xx:MaxTenuringThreshold=<N> 来进行设置前往养老区的阈值（默许 15）。

图解进程

能够看视频，愈加清晰易懂：https://www.bilibili.com/video/BV1PJ411n7xZ?p=72

咱们创立的目标，一般都是存放在 Eden 区的，当 Eden 区满了后，就会触发 GC 操作，一般被称为 YGC / Minor GC 操作。

当咱们进行一次废物搜集后，赤色的（不再运用的）将会被收回，而绿色的（还运用的）还会被占用着，存放在 S0（Survivor From）区。一起咱们给每个目标设置了一个年纪计数器，一次收回后便是 1。

一起 Eden 区持续存放目标，当 Eden 区再次存满的时分，又会触发一个 YGC / Minor GC 操作，此刻 GC 将会把 Eden 和 Survivor From 中的目标进行一次搜集，把存活的目标放到 Survivor To 区，一起让年纪 + 1

咱们持续不断的进行目标生成和废物收回，当 Survivor 中的目标的年纪到达 15 的时分，将会触发一次 Promotion 提升的操作，也便是将年青代中的目标提升到老时代中。

考虑：幸存区区满了后？

特别注意，在 Eden 区满了的时分，才会触发 YGC / Minor GC，一起整理幸存者区，而 Survivor 幸存者区满了后，不会触发 YGC / Minor GC 操作。

假如 Survivor 区满了后，将会触发一些特其他规矩，也便是或许直接提升老时代。

举例：以当兵为例，正常人的提升或许是：新兵 -> 班长 -> 排长 -> 连长 ……。

可是也有或许有些人由于做了非常大的奉献，直接从新兵 -> 师长。

也有些人天然生成有优势，不必当新兵，直接在当兵那天提升司令（极少）。

折射到富二代也是如此。

To、From 怎么区分？

经过一次 YGC / Minor GC 后，谁为空则是 To，不为空的是 From。

关于废物收回：频频在重生区搜集，很少在养老区搜集，简直不在永久区/元空间搜集。

好像当上了大官，则很难被整理下台，除非特别状况（年迈、糜烂）。

目标分配的特别状况

假如来了一个新目标，先看看 Eden 区是否放的下？

假如 Eden 区放得下，则直接放到 Eden 区
假如 Eden 区放不下，则触发 YGC，履行废物收回，看看还能不能放下？
假如废物收回还放不下，阐明目标很大，直接放到晚年区

将目标放到晚年区又有两种状况：

假如 Eden 区履行了 YGC 仍是无法放不下该目标，那没得办法，只能阐明是超大目标，只能直接放到晚年区
那万一晚年区都放不下，则先触发 Full GC 整理晚年区，再看看能不能放下，放得下最好，但假如仍是放不下，那只能报 OOM

假如 Eden 区满了，触发 YGC，将存活目标从 Eden 区往 Survivor 幸存区仿制时，发现幸存区放不下了，那只能廉价了某些新目标，让他们直接提升至晚年区

代码演示目标分配进程

咱们不断的创立大目标

/**
 * 代码演示目标创立进程
 *
 */
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);
     }
   }
}

然后设置 VM option 参数

-Xms600m -Xmx600m

不同于直接找到 JDK 的 bin 目录翻开软件，这儿运用指令行翻开，愈加便利。

在 cmd 输入下面指令，翻开 VisualVM 图形化界面

jvisualvm

然后经过履行上面代码，经过 VisualGC 进行动态化检查

调查右侧的图表，Eden 区每隔一段时刻都有一个下降到底部的锋线是产生了 GC 收回，Survivor 则是来回切换，晚年区则是往上升。

终究，在老时代或重生代都满了，就呈现 OOM

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
  at com.youngkbt.java.chapter08.HeapInstanceTest.<init>(HeapInstanceTest.java:13)
  at com.youngkbt.java.chapter08.HeapInstanceTest.main(HeapInstanceTest.java:17)

常用的调优东西

JDK 指令行
Eclipse：Memory Analyzer Tool
Jconsole
Visual VM（实时监控，引荐）
Jprofiler（IDEA 插件，引荐）
Java Flight Recorder（实时监控）
GCViewer
GCEasy

总结

针对幸存者 s0，s1 区的总结：仿制之后有交流，谁空谁是 to
关于废物收回：频频在重生区搜集，很少在老时代搜集，简直不再永久代和元空间进行搜集
重生代采用仿制算法的意图：是为了削减内碎片

GC分类

Minor GC：重生代的 GC
Major GC：老时代的 GC
Full GC：整堆搜集，搜集整个 Java 堆和办法区的废物搜集

咱们都知道，JVM 的调优的一个环节，也便是废物搜集，咱们需求尽量的避免废物收回，由于在废物收回的进程中，简略呈现 STW 的问题。

STW：stop the word，暂停其它用户的线程，等废物收回完毕，用户线程才康复运转。

而 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 混淆运用，需求具体分辨是老时代收回（Major GC）仍是整堆收回（Full GC）
混合搜集（Mixed GC）：搜集整个重生代以及部分老时代的废物搜集
- 现在，只需 G1 GC 会有这种行为

整堆搜集（Full GC）：搜集整个 Java 堆和办法区的废物搜集。

Minor GC

当年青代空间缺乏时，就会触发 Minor GC，这儿的年青代满指的是 Eden 代满，Survivor 满不会引发 GC。（每次 Minor GC 会整理年青代的内存。）

由于 Java 目标大多都具有 朝生夕灭 的特性，所以 Minor GC 非常频频，一般收回速度也比较快。这一界说既清晰又易于了解。

Minor GC 会引发 STW，暂停其它用户的线程，等废物收回完毕，用户线程才康复运转。

Major GC

指产生在老时代的 GC，目标从老时代消失时，咱们说「Major Gc」或「Full GC」产生了。

呈现了 Major GC，经常会伴随至少一次的 Minor GC（但非肯定的，在 Parallel Scavenge 搜集器的搜集战略里就有直接进行 Major GC 的战略挑选进程）。

也便是在老时代空间缺乏时，会先测验触发 Minor GC。假如之后空间还缺乏，则触发 Major GC

Major GC 的速度一般会比 Minor GC 慢 10 倍以上，STW 的时刻更长，假如 Major GC 后，内存还缺乏，就报 OOM 了。

Full GC

本内容仅仅简略介绍了解，废物收回站的内容有具体的解说。

触发 Full GC 履行的状况有如下五种：

调用 System.gc() 时，体系主张履行 Full GC，可是不必然履行
老时代空间缺乏
办法区空间缺乏
经过 Minor GC 后进入老时代的均匀巨细大于老时代的可用内存
由 Eden 区、Survivor Space0（From Space）区向 Ssurvivor Space1（To Space）区仿制时，目标巨细大于 To Space 可用内存，则把该目标转存到老时代，且老时代的可用内存小于该目标巨细（和老时代空间缺乏类似）

阐明：Full GC 是开发或调优中尽量要避免的。这样暂时时刻会短一些。

GC 举例

咱们编写一个 OOM 的反常，由于咱们在不断的创立字符串，是存放在元空间的

/**
 * 测验 MinorGC 、 MajorGC、FullGC
 * -Xms9m -Xmx9m -XX:+PrintGCDetails
 */
public class GCTest {
  public static void main(String[] args) {
    int i = 0;
    try {
      List<String> list = new ArrayList<>();
      String a = "young kbt";
      while(true) {
        list.add(a);
        a = a + a;
        i++;
       }
     }catch (Exception e) {
      e.getStackTrace();
     }
   }
}

设置 VM option 发动参数

-Xms10m -Xmx10m -XX:+PrintGCDetails

打印出的日志

[GC (Allocation Failure) [PSYoungGen: 2038K->500K(2560K)] 2038K->797K(9728K), 0.3532002 secs] [Times: user=0.01 sys=0.00, real=0.36 secs]
[GC (Allocation Failure) [PSYoungGen: 2108K->480K(2560K)] 2405K->1565K(9728K), 0.0014069 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 2288K->0K(2560K)] [ParOldGen: 6845K->5281K(7168K)] 9133K->5281K(9728K), [Metaspace: 3482K->3482K(1056768K)], 0.0058675 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] 5281K->5281K(9728K), 0.0002857 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(2560K)] [ParOldGen: 5281K->5263K(7168K)] 5281K->5263K(9728K), [Metaspace: 3482K->3482K(1056768K)], 0.0058564 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen   total 2560K, used 60K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000) eden space 2048K, 2% used [0x00000000ffd00000,0x00000000ffd0f138,0x00000000fff00000) from space 512K, 0% used [0x00000000fff00000,0x00000000fff00000,0x00000000fff80000) to  space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000) ParOldGen    total 7168K, used 5263K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000) object space 7168K, 73% used [0x00000000ff600000,0x00000000ffb23cf0,0x00000000ffd00000) Metaspace    used 3514K, capacity 4498K, committed 4864K, reserved 1056768K class space  used 388K, capacity 390K, 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.youngkbt.java.chapter08.GCTest.main(GCTest.java:20)

[PSYoungGen: 2038K->500K(2560K)]：年青代总空间为 2560K，当时占用 2038K，经过废物收回后剩下 500K
2038K->797K(9728K)：堆内存总空间为 9728K，当时占用 2038K，经过废物收回后剩下 797K

触发 OOM 的时分，一定是进行了一次 Full GC，由于只需在老时代空间缺乏时分，才会爆出 OOM 反常。

堆空间分代思想

为什么要把 Java 堆分代？不分代就不能正常作业了吗？经研讨，不同目标的生命周期不同。70% – 99% 的目标是临时目标。

重生代：有 Eden、两块巨细相同的 survivor（又称为 from/to，s0/s1）构成，to 总为空。

老时代：存放重生代中阅历屡次 GC 仍然存活的目标。

其实不分代彻底能够，分代的仅有理由便是 优化 GC 功能。

假如没有分代，那一切的目标都在一块，就好像把一个学校的人都关在一个教室。GC 的时分要找到哪些目标没用，这样就会对堆的一切区域进行扫描。（功能低）
而许多目标都是朝生夕死的，假如分代的话，把新创立的目标放到某一当地，当 GC 的时分先把这块存储「朝生夕死」目标的区域进行收回，这样就会腾出很大的空间出来。（多收回重生代，少收回老时代，功能会进步许多）

比方：

拿疫情举例：

一个当地分为本地居民区、从疫情高危地回来的居民区，从外国回来的居民区
单纯从检测视点看，咱们是分为三个区好仍是一致放在一个区进行检测好？
当然是分为三个区好，本地区隔半个月检查一次，高危地回来的一天检查一次，外国回来的两天检查一次，不然检测整个当地，耗时耗力

GC 的废物收回也是同理。

内存分配战略

假如目标在 Eden 区出生并经过第一次 Minor GC 后仍然存活，并且能被 Survivor 包容的话，将被移动到 Survivor 空间中，并将目标年纪设为 1。目标在 Survivor 区中每熬过一次 Minor GC，年纪就增加 1 岁，当它的年纪增加到一定程度（默许为 15 岁，其实每个 JVM、每个 GC 都有所不同）时，就会被提升到老时代。

目标提升老时代的年纪阀值，能够经过选项 -xx:MaxTenuringThreshold 来设置。

针对不同年纪段的目标分配原则如下所示：

优先分配到 Eden：开发中比较长的字符串或许数组，会直接存在老时代，可是由于新创立的目标都是朝生夕死的，所以这个大目标或许也很快被收回，可是由于老时代触发 Major GC 的次数比 Minor GC 要更少，因而或许收回起来就会比较慢。

大目标直接分配到老时代（大到 Eden 区无法容下）：尽量避免程序中呈现过多的大目标。

长期存活的目标分配到老时代。

动态目标年纪判别：假如 Survivor 区中相同年纪的一切目标巨细的总和大于 Survivor 空间的一半，年纪大于或等于该年纪的目标能够直接进入老时代，无须比及 MaxTenuringThreshold 中要求的年纪。

空间分配担保：-XX:HandlePromotionFailure。

代码示例：

public class YoungOldAreaTest {
  public static void main(String[] args) {
    byte[] buffer = new byte[1024 * 1024 * 20]; // 20M
   }
}

设置 VM option 参数：

-Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails

此刻重生代巨细为 20M，其间 Eden 区为 16M，Survivor1 和 Survivor1 为 2M，构成 8:1:1，老时代为 40M，构成 2:1。

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 空间中分配内存。

笔记

哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只需本地缓冲区用完了，分配新的缓存区时才需求同步锁定 —— 《深化了解 JVM》第三版里。

和这儿讲的有点不同。我猜测说的意思是某一次分配，假如 TLAB 用完了，那么 这一次 先在 Eden 区直接分配。空闲下来后再加锁分配新的 TLAB（TLAB 内存较大，分配时刻应该较长）。

TLAB分配进程

目标首要是经过 TLAB 开辟空间，假如不能放入，那么需求经过 Eden 来进行分配

问题

一个 100KB 的 TLAB 区域，假如现已运用了 80KB，当需求分配一个 30KB 的目标时，TLAB 是怎么分配的呢？

此刻，虚拟机有两种挑选：

第一，废弃当时的 TLAB（会浪费 20KB 的空间）
第二，将这个 30KB 的目标直接分配到堆上，保存当时 TLAB（当有小于 20KB 的目标请求 TLAB 分配时能够直接运用该 TLAB 区域）

JVM 挑选的战略是：在虚拟机内部保护一个叫 refill_waste 的值，当请求目标大于 refill_waste 时，会挑选在堆中分配，反之，则会废弃当时 TLAB，新建 TLAB 来分配新目标。

默许状况下，TLAB 和 refill_waste 都是会在运转时不断调整的，使体系的运转状况到达最优。

堆空间的参数设置

常用参数设置

更多的参数设置在官方文档：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html。

测验堆空间常用的 JVM 参数：

-XX:+PrintFlagsInitial: 检查一切的参数的默许初始值
-XX:+PrintFlagsFinal：检查一切的参数的终究值（或许会存在修改，不再是初始值）

具体检查某个参数的指令：
- jps：检查当时运转中的进程
- jinfo -flag SurvivorRatio 进程 id：经过 jps 获取的进程 id 来检查具体的进程信息
-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:HandlePromotionFailure：是否设置空间分配担保

空间分配担保

在产生 Minor GC 之前，虚拟机会检查老时代最大可用的接连空间是否大于重生代一切目标的总空间。

假如大于，则此次 Minor GC 是安全的
假如小于，则虚拟机会检查
```
-XX:HandlePromotionFailure
```
设置值是否允担保失利
- 假如
```
HandlePromotionFailure=true
```
  ，那么会持续检查老时代最大可用接连空间是否大于每次提升到老时代的目标的均匀巨细
  - 假如大于，则测验进行一次 Minor GC，但这次 Minor GC 依然是有风险的
  - 假如小于，则改为进行一次 Full GC
- 假如 HandlePromotionFailure=false，则不检查，直接进行一次 Full GC

在 JDK6 Update24（JDK7）之后，HandlePromotionFailure 参数不会再影响到虚拟机的空间分配担保战略（相当于固定为 true），调查 OpenJDK 中的源码变化，尽管源码中还界说了 HandlePromotionFailure 参数，可是在代码中现已不会再运用它。JDK6 Update 24 之后的规矩变为只需老时代的接连空间大于重生代目标总巨细或许每次提升的均匀巨细就会进行 Minor GC，不然将进行 Full GC。

相当于 JDK7 后 HandlePromotionFailure 参数为 true，且无法更改。

堆是分配目标的仅有挑选么？

在《深化了解 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;
}

下面代码中的 StringBuffer sb 产生了逃逸，不能在栈上分配

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();
}

完好的逃逸剖析代码举例

/**
 * 逃逸剖析
 * 怎么快速的判别是否产生了逃逸剖析，就看 new 的目标是否在办法外被调用。
 */
public class EscapeAnalysis {

  public EscapeAnalysis obj;

  /**
   * 办法回来 EscapeAnalysis 目标，产生逃逸
   */
  public EscapeAnalysis getInstance() {
    return obj == null ? new EscapeAnalysis():obj;
   }

  /**
   * 为成员特点赋值，产生逃逸
   */
  public void setObj() {
    this.obj = new EscapeAnalysis();
   }
  //考虑：假如当时的 obj 引证声明为 static 的？仍然会产生逃逸。
  
  /**
   * 目标的作用于仅在当时办法中有效，没有产生逃逸
   */
  public void useEscapeAnalysis() {
    EscapeAnalysis e = new EscapeAnalysis();
   }

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

参数设置

在 JDK 1.7 版别之后，HotSpot 中默许就现已敞开了逃逸剖析。

假如运用的是较早的版别，开发人员则能够经过：

选项 -xx:+DoEscapeAnalysis 显式敞开逃逸剖析
经过选项 -xx:+PrintEscapeAnalysis 检查逃逸剖析的挑选结果

定论

开发中能运用局部变量的，就不要运用在办法外界说。

能界说局部变量，就不要界说全局变量。

代码优化

运用逃逸剖析，编译器能够对代码做如下优化：

栈上分配：将堆分配转化为栈分配。假如一个目标在子程序中被分配，要使指向该目标的指针永久不会产生逃逸，目标或许是栈上分配的候选，而不是堆上分配
同步省略：假如一个目标被发现只需一个线程被拜访到，那么对于这个目标的操作能够不考虑同步
别离目标或标量替换：有的目标或许不需求作为一个接连的内存结构存在也能够被拜访到，那么目标的部分（或全部）能够不存储在内存，而是存储在 CPU 寄存器中

栈上分配

JIT 编译器在编译期间依据逃逸剖析的结果，发现假如一个目标并没有逃逸出办法的话，就或许被优化成栈上分配。分配完成后，持续在调用栈内履行，最后线程完毕，栈空间被收回，局部变量目标也被收回。这样就无须进行废物收回了。

常见的栈上分配的场景

在逃逸剖析中，现已阐明了。分别是给成员变量赋值、办法回来值、实例引证传递。

举例

咱们经过举例来阐明敞开逃逸剖析和未敞开逃逸剖析时分的状况

/**
 * 栈上分配测验
 * -Xmx128m -Xms128m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
 */
public class StackAllocation {
  public static void main(String[] args) {
    long start = System.currentTimeMillis();

    for (int i = 0; i < 10000000; i++) {
      alloc();
     }
    // 检查履行时刻
    long end = System.currentTimeMillis();
    System.out.println("花费的时刻为： " + (end - start) + " ms");
    // 为了便利检查堆内存中目标个数，线程 sleep
    try {
      Thread.sleep(1000000);
     } catch (InterruptedException e1) {
      e1.printStackTrace();
     }
   }

  private static void alloc() {
    User user = new User(); // 未产生逃逸
   }

  static class User {

   }
}

设置 VM option 参数，标明未敞开逃逸剖析

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

运转结果，一起还触发了 GC 操作

花费的时刻为：664 ms

然后检查内存的状况，发现有大量的 User 存储在堆中

咱们在敞开逃逸剖析

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

然后检查运转时刻，咱们能够发现花费的时刻快速削减，一起不会产生 GC 操作

花费的时刻为：5 ms

在看内存状况，咱们发现只需很少的 User 目标，阐明 User 未产生逃逸，由于它存储在栈中，跟着栈的毁掉而消失

同步省略

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

在动态编译同步块的时分，JIT 编译器能够凭借逃逸剖析来 判别同步块所运用的锁目标是否只能够被一个线程拜访而没有被发布到其他线程。假如没有，那么 JIT 编译器在编译这个同步块的时分就会取消对这部分代码的同步。这样就能大大进步并发性和功能。这个取消同步的进程就叫同步省略，也叫 锁消除。

也便是只需一个线程的状况下，同步形式能够去掉，由于不涉及其他线程抢夺资源状况。

例如下面的代码

public void f() {
  Object hellis = new Object();
  synchronized(hellis) { // 锁了个孤寂，由于每个线程获取的 hellis 都是新 new 出来，不是同一个 
    System.out.println(hellis);
   }
}

代码中对 hellis 这个目标加锁，可是 hellis 目标的生命周期只在 f() 办法中，并不会被其他线程所拜访到，俗称锁了个孤寂，由于每个线程获取的 hellis 都是新 new 出来，不是同一个 hellis。

所以在 JIT 编译阶段就会被优化掉，自动优化成：

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

咱们将其转换成字节码

别离目标和标量替换

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

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

如 User 类有 name 和 age，两者都是标量，所以能够分解，放到栈中，不需求放到堆中生成 User 类。

在 JIT 阶段，假如经过逃逸剖析，发现一个目标不会被外界拜访的话，那么经过 JIT 优化，就会把这个目标拆解成若干个其间包括的若干个成员变量来代替。这个进程便是标量替换。

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 这个聚合量经过逃逸剖析后，发现他并没有逃逸，就被替换成两个标量了。那么标量替换有什么优点呢？便是能够大大削减堆内存的占用。由于一旦不需求创立目标了，那么就不再需求分配堆内存了。

标量替换为栈上分配供给了很好的根底。

代码优化之标量替换

代码示例

/**
 * 标量替换测验
 *  -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
 * @author shkstart  shkstart@126.com
 * @create 2020  12:01
 */
public class ScalarReplace {
  public static class User {
    public int id;
    public String name;
   }

  public static void alloc() {
    User u = new User();//未产生逃逸
    u.id = 5;
    u.name = "www.youngkbt.com";
   }

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

未敞开标量替换参数

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

运转代码后的控制台输出：

[GC (Allocation Failure) 25600K->880K(98304K), 0.0012658 secs]
[GC (Allocation Failure) 26480K->832K(98304K), 0.0012124 secs]
[GC (Allocation Failure) 26432K->784K(98304K), 0.0009719 secs]
[GC (Allocation Failure) 26384K->832K(98304K), 0.0009071 secs]
[GC (Allocation Failure) 26432K->768K(98304K), 0.0010643 secs]
[GC (Allocation Failure) 26368K->824K(101376K), 0.0012354 secs]
[GC (Allocation Failure) 32568K->712K(100864K), 0.0011291 secs]
[GC (Allocation Failure) 32456K->712K(100864K), 0.0006368 secs]
花费的时刻为： 99 ms

敞开标量替换参数

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

运转代码后的控制台输出：时刻削减许多，且无 GC

花费的时刻为： 6 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 中并未这么做（刚刚演示的作用，是由于 HotSpot 完成了标量替换，然后变成根本数据类型的数据，存入栈中，没有产生内存分配），这一点在逃逸剖析相关的文档里现已阐明，所以能够明确在 HotSpot 虚拟机上，一切的目标实例都是创立在堆上。

现在许多书籍仍是依据 JDK7 从前的版别，JDK 现已产生了很大变化，intern 字符串的缓存和静态变量从前都被分配在永久代上，而永久代现已被元数据区取代。可是，intern 字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点相同符合前面一点的定论：目标实例都是分配在堆上。

小结

年青代是目标的诞生、生长、消亡的区域，一个目标在这儿产生、应用，最后被废物收回器搜集、完毕生命。

老时代放置长生命周期的目标，一般都是从 Survivor 区域挑选仿制过来的 Java 目标。

当然，也有特别状况，咱们知道一般的目标或许会被分配在 TLAB 上；

假如目标较大，无法分配在 TLAB 上，则 JVM 会企图直接分配在 Eden 其他方位上；

假如目标太大，彻底无法在重生代找到足够长的接连空闲空间，JVM 就会直接分配到老时代。

当 GC 只产生在年青代中，收回年青代目标的行为被称为 Minor GC。

当 GC 产生在老时代时则被称为 Major GC 或许 Full GC。

一般的，Minor GC 的产生频率要比 Major GC 高许多，即老时代中废物收回产生的频率将大大低于年青代。

JVM篇： 堆