堆在JVM启动时被创立，大小也随之确定，是JVM最大、最重要的一块内存空间。堆在物理上不间断，而在逻辑上间断。尽管堆是每个线程共享，但也能够划分线程公有的缓冲区。

简直所有的对象实例和数组都调配在堆中，少部分调配在栈中。对象和数组可能永远不会存储在栈上，栈帧中仅保留援用，而这援用指向堆中的地位。在栈帧完结后，堆中的对象不会马上被移除，仅在垃圾回收时才被移除。

虚拟机的办法区和堆空间，是每个线程共用的，其余数据区为每个线程公有，公有数据区颗粒度较细，难有优化的空间。而共用的数据区，内存调配时能失去较多的内存，所以该数据区是GC时的重点。

新生代和老年代

在Java7以前，堆空间在逻辑上划分为：新生区+老年区+永恒代；在Java8及之后分为：新生区+老年区+元空间

永恒代和元空间，是办法区的具体实现，办法区又叫non-heap，所以永恒代和元空间实际上不归属于堆，只是逻辑划分而已。

存储在JVM的Java对象能够被划分成两类，一类是生面周期比拟短的刹时对象，这些类的创立和沦亡都十分迅速；另一类对象的生命周期却十分长，在某些极其状况下，还可能与JVM的生命周期放弃始终，如Runtime类

为什么要进行内存分带？大量数据表明，不同对象的生命周期不同，70%~90%的对象时长期对象，对对象进行分代能够更有目标的进行GC，优化GC性能。
《2020最新Java根底精讲视频教程和学习路线！》

新生代

新生代能够划分为Eden、Survivor0和Survivor1，Survivor0和Survivor1有时也叫作from、to。

  • Eden：对象(简直所有)最开始创立的地位。
  • Survivor0和Survivor1：Eden区没有被GC革除的对象会被放到S0和S1中，S0和S1大小统一，只有一个空间用来存储对象，另一个区用来全量GC。

绝大部分的Java对象都是在新生代销毁，IBM钻研表明，新生代80%的对象都是朝生夕死。

老年代

堆空间除了新生代就是老年代啦。。

对象在堆中的调配过程

1、对象最开始先被调配到Eden区，Eden区满了之后会进行Young GC，存活下来的对象会被挪动到Survivor区。每个对象都有一个年龄计数器，在Eden区为0，被挪动到S区则变为1。S区满不会触发YGC。

2、存活在S区的对象，在通过第二次GC之后能存活下来的，年龄计数器会持续+1。当年龄计数器达到15后，对应的对象会被挪动(promotion)至老年区。该值能够通过-XX:MaxTenuringThreshold=15进行设置。

3、当对象占用的空间太大，YGC前任然超过了Eden区的空间时，会间接将该对象调配到老年代。老年代放不下则进行Full GC，GC前任然放不下则OOM。存活在Eden区的对象在YGC后，S区放不下，则会间接调配到老年代。

与堆内存设置相干的参数

  • -Xms，示意堆的起始内存（新生代和老年代）

全称为-XX:InitialHeapSize

X是JVM的运行参数，ms是memory start。默认单位为字节，有k、m、g

  • -Xmx，示意堆的最大内存

全称为-XX:MaxHeapSize

默认的堆空间大小：

-Xms = 计算机内存大小 /64

-Xmx = 计算机内存大小 /4

一旦超过了-Xmx所制订的最大内存时，将会抛出OutOfMemoryError。通常会将两个参数设置成雷同的值，让垃圾回收完后，不须要从新分隔计算堆区的大小，进而进步性能。

能够通过以下程序查看JVM的堆大小：

// -Xms 堆的起始值，s0,s1区只算其中的一个long initalMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024// -Xmx 堆的最大值long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024复制代码

敞开自适应的内存调配策略

-XX:-UseAdaptiveSizePolicy：-为敞开，+为开启，默认开启

配置新生代和老年代在对构造的占比

  • 默认-XX:NewRatio=2，示意新生代占1，老年代占2，新生代占整个堆的1/3；能够批改为-XX:NewRatio=4，示意新生代占1，老年代占4，新生代占整个堆的1/5
  • 在HotSpot中，Eden和S0、S1的默认比例为8:1:1，能够通过-XX:SurvivorRatio=8调整比例

配置新生代的最大内存大小

  • -Xmn，个别默认即可，有设置就以这个参数为准。

与堆相干的GC

JVM在GC时，并不是整体进行垃圾收集，而是频繁收集新生代，较少收集老年代，简直不在永恒代/元空间收集。

  • Minor GC，只对新生代进行垃圾收集，当Eden区内存不足时会触发，Survivor区满不会GC。
  • Major GC ，只对老年代进行垃圾收集

    目前只有CMS GC会有独自收集老年代的行为

    很多时候Major GC会和Full GC混同应用，须要具体分辨是老年代回收还是整堆回收

    Major GC常常会随同Minor GC，也就是在老年代空间有余时，会尝试先触发Minor GC，之后空间还有余，则触发Major GC。Major GC的速度比Minor GC慢十倍以上，STW工夫也更长。

    尽量避免

  • Mixed GC，收集新生代和局部老年代的垃圾，只呈现于G1 GC
  • Full GC，收集整个Java堆和办法区的垃圾

    引起Full GC的几种状况： 调用System.gc()时，零碎倡议执行Full GC，然而不必然执行；老年代空间有余；办法区空间有余；Minor GC后进入老年代的均匀大小大于老年代的可用内存；老年代放不下从Eden区过去的大对象；

    尽量避免

堆内存调配策略

  • 优先调配到Eden区
  • 大对象间接调配到老年代，防止程序中呈现过多的大对象
  • 长期存活的对象调配到老年代
  • 动静对象年龄判断，如果Survivor区中雷同年龄的所有对象大小总和大于S区空间的一半，年龄大于等于的对象能够间接进入老年代，无需等到MaxTenuringThreshold要求的年龄
  • 空间调配担保，-XX:HandlePromotionFailure

堆内存的线程公有空间：TLAB

TLAB：ThreadLocal Allocation Buffer

堆区时线程共享的区域，任何线程都能够拜访到堆区中共享数据。因为对象实例创立在JVM中十分频繁，因而在并发环境下，从堆区划分内存空间是线程不平安的。为了防止多个线程操作同一地址，须要加锁等机制，加锁影响调配速度。因而有必要为每个线程独自调配一块区域存放数据，该区域存在于Eden区中，这种策略也叫疾速调配策略。

只管不是所有的对象实例都可能在TLAB中胜利分配内存，但JVM的确将TLAB作为内存调配的首选。能够通过-XX:UseTLAB设置是否开启，默认开启。默认状况下，TLAB空间十分小，只占Eden区的1%，能够通过-XX:TLABWasteTargetPercent进行设置占用的百分比。

一旦对象在TLAB调配失败时，JVM会尝试加锁确保数据操作的原子性，从而间接在Eden区调配。