1、堆的核心概述
1.1、堆内存
- 一个进程对应一个JVM实例
- 一个JVM实例对应一个堆空间
- 进程包含多个线程，所以线程之间共享同一个堆空间
一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
Java堆区在JVM启动的时候即被创建，其空间大小也就确定了，堆是JVM管理的最大一块内存空间。
堆内存的大小是可以调节的。
《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer，TLAB）。
《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，垃圾收集器）执行垃圾回收的重点区域。
1.2、设置堆内存大小
Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，可以通过选项"-Xmx"和"-Xms"来进行设置。
“-Xms"用于表示堆区的起始内存，等价于-XX: Initialheapsize
“-Xmx"则用于表示区的最大内存，等价于-XX: Maxheapsize
一旦堆区中的内存大小超过“-Xmx所指定的最大内存时，将会抛出Outofmemoryerror异常。
通常将-Xms和-Xmx两个参数配置相同的值，其目的是为了能够在java垃圾会后清理完堆区后，不需要重新分隔计算堆区的大小，从而提高性能。
默认情况下，初始内存大小：物理电脑内存大小/64；最大内存大小：物理电脑内存大小/4。
1.3、堆内存分区
现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：
JDK8及之后堆内存逻辑上分为三部分：新生区 + 养老区 + 元空间
- 堆空间内部结构，JDK1.8之前从
永久代替换成元空间 - 堆空间逻辑上包括
永久代/元空间，实际上控制不到
2、年轻代与老年代
2.1、Java对象分类
存储在JVM中的Java对象可以被划分为两类：
一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致
Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（oldGen）
其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）
2.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"设置新生代最大内存大小，但这个参数一般使用默认值就可以了。
新生区的对象默认生命周期超过 15 ，将进入老年代。
3、图解对象分配过程
为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。
- new的对象先放伊甸园区。此区有大小限制。
- 当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（MinorGC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区。
- 然后将伊甸园中的剩余对象移动到幸存者0区。
- 如果再次触发垃圾回收，此时将伊甸园区和幸存者0区进行垃圾回收，剩下的对象就会放到幸存者1区。
- 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
- 啥时候能去养老区呢？可以设置次数。默认是15次。可以设置新生区进入养老区的年龄限制，设置 JVM 参数：-XX:MaxTenuringThreshold=N 进行设置
- 在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理
- 若养老区执行了Major GC之后，发现依然无法进行对象的保存，就会产生OOM异常。
3.1、图解对象分配
- 我们创建的对象，一般都是存放在Eden区的，当我们的Eden区满了后，就会触发GC操作，一般被称为
YGC / Minor GC操作
- 当我们进行一次垃圾收集后，红色的对象将会被回收，而绿色的独享还被占用着，存放在S0(Survivor From)区。同时我们给每个对象设置了一个年龄计数器，经过一次回收后还存在的对象，将其年龄加 1。
- 同时Eden区继续存放对象，当Eden区再次存满的时候，又会触发一个MinorGC操作，此时GC将会把 Eden和Survivor From中的对象进行一次垃圾收集，把存活的对象放到 Survivor To区，同时让存活的对象年龄 + 1
- 我们继续不断的进行对象生成和垃圾回收，当Survivor中的对象的年龄达到15的时候，将会触发一次
Promotion 晋升的操作，也就是将年轻代中的对象晋升到老年代中
3.2、特殊情况说明
幸存区满了咋办？
特别注意，在Eden区满了的时候，才会触发MinorGC，而幸存者区满了后，不会触发MinorGC操作。
如果Survivor区满了后，将会触发一些特殊的规则，也就是可能直接晋升老年代。
对象分配的特殊情况
如果来了一个新对象，先看看 Eden 是否放的下？
- 如果 Eden 放得下，则直接放到 Eden 区
- 如果 Eden 放不下，则触发 YGC ，执行垃圾回收，看看还能不能放下
将对象放到老年区又有两种情况：
如果 Eden 执行了 YGC 还是无法放不下该对象，说明是超大对象，只能直接怼到老年代
那万一老年代都放不下，则先触发重 GC ，再看看能不能放下，放得下最好，但如果还是放不下，那只能报 OOM
如果 Eden 区满了，将对象往幸存区拷贝时，发现幸存区放不下啦，那只能便宜了某些新对象，让他们直接晋升至老年区。
3.3、总结：
针对幸存者s0，s1区的总结：复制之后有交换，谁空谁是to。
关于垃圾回收频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。
3.4、常用调优工具
- JDK命令行
- Eclipse：Memory Analyzer Tool
- Jconsole
- Visual VM（实时监控 推荐~）
- Jprofiler（推荐~）
- Java Flight Recorder（实时监控）
- GCViewer
- GCEasy
4、GC垃圾回收器
4.1、分代收集思想（面试必问）
Minor GC、Major GC、Full GC
我们都知道，JVM调优的一个环节，也就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现STW（Stop the World）的问题，而 Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上。
JVM在进行GC时，并非每次都对上面三个内存( 新生代、老年代；方法区 )区域一起回收的，大部分时候回收的都是指新生代。
针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）
部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
新生代收集（ Minor GC/Young GC ）：只是新生代( Eden、S0/S1 )的垃圾收集
老年代收集（ Major GC/Old GC ）：只是老年代的垃圾收集。
目前，只有CMS GC会有单独收集老年代的行为。
注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。
混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。
目前，只有G1 GC会有这种行为。
整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。
4.2、Young/Minor GC
年轻代 GC（Minor GC）触发机制
当年轻代空间不足时，就会触发Minor GC，这里的年轻代满指的是Eden区满，Survivor区满不会触发GC。（每次Minor GC会清理年轻代的内存）。
因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
Minor GC会引发STW，暂停其它用户的线程，等待垃圾回收线程结束，用户线程才恢复运行。
4.3、Major GC
老年代 GC（MajorGC/Full 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了
4.4、Full GC
Full GC 触发机制
触发Full GC执行的情况有如下五种：
- 调用System.gc( )时，系统建议执行Full GC，但是不必然执行
- 老年代空间不足
- 方法区空间不足
- 通过Minor GC后进入老年代的平均大小 大于 老年代的可用内存
- 由Eden区、survivor space0（From Space）区 向survivor space1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存 小于 该对象大小
说明：Full GC 是开发或调优中尽量要避免的。这样STW时间会短一些
5、堆空间分配思想
为什么要把Java堆分代？不分代就不能正常工作了吗？
经研究，不同对象的生命周期不同。70%-99%的对象是临时对象。
新生代：有Eden、两块大小相同的Survivor（又称为from/to，s0/s1）构成，to总为空。
老年代：存放新生代中经历多次GC之后仍然存活的对象。
其实不分代完全可以，分代的唯一理由就是优化GC性能。
如果没有分代，那所有的对象都在一块，就如同把一个学校的人都关在一个教室。GC的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。
而很多对象都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当GC的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
6、内存分配策略
内存分配策略或对象提升（Promotion）规则
如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。
对象在Survivor区中每熬过一次MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代。
对象晋升老年代的年龄阀值，可以通过选项**-XX:MaxTenuringThreshold**来设置。
针对不同年龄段的对象分配原则如下所示：
1、优先分配到Eden
2、大对象直接分配到老年代：尽量避免程序中出现过多的大对象
3、长期存活的对象分配到老年代
4、动态对象年龄判断：
如果Survivor区中相同年龄的所有对象大小的总和 大于 Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
空间分配担保：
-XX:HandlePromotionFailure ，也就是经过Minor GC后，所有的对象都存活，因为Survivor比较小，所以就需要将Survivor无法容纳的对象，存放到老年代中。
7、为对象分配内存：TLAB
7.1、为什么有TLAB
问题：堆空间都是共享的么？
不一定，因为还有TLAB这个概念，在堆中划分出一块区域，为每个线程所独占。
为什么有TLAB（Thread Local Allocation Buffer）？
TLAB：Thread Local Allocation Buffer，也就是为每个线程单独分配了一个缓冲区
堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的。
为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。
7.2、什么是TLAB
从内存模型而不是垃圾收集的角度，对Eden区域继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden空间内。
多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略。
据我所知所有OpenJDK衍生出来的JVM都提供了TLAB的设计。
7.3、TLAB分配过程
尽管不是所有的对象实例都能够在TLAB中成功分配内存，但JVM确实是将TLAB作为内存分配的首选。
在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间。
默认情况下，TLAB空间的内存非常小，仅占有整个Eden空间的1%，当然我们可以通过选项“-XX:TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小。
一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存。
8、堆空间参数设置
8.1、官方文档
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
8.2、常用设置
-XX:+PrintFlagsInitial：查看所有的参数的默认初始值
-XX:+PrintFlagsFinal：查看所有的参数的最终值（可能会存在修改，不再是初始值）
-Xms：初始堆空间内存（默认为物理内存的1/64）
-Xmx：最大堆空间内存（默认为物理内存的1/4）
-Xmn：设置新生代的大小（初始值及最大值）
-XX:NewRatio：配置新生代与老年代在堆结构的占比
-XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
-XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
-XX:+PrintGCDetails：输出详细的GC处理日志
-XX:+PrintGC 或 -verbose:gc ：打印gc简要信息
-XX:HandlePromotionFalilure：是否设置空间分配担保
8.3、空间分配担保
在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
如果大于，则此次Minor GC是安全的
如果小于，则虚拟机会查看**-XX:HandlePromotionFailure**设置值是否允许担保失败。
如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小
如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；
如果小于，则进行一次Full GC。
如果HandlePromotionFailure=false，则进行一次Full GC。
在JDK6 Update 24之后 (JDK 7)，HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察openJDK中的源码变化，虽然源码中还定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。
JDK6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。即 HandlePromotionFailure=true
我们都知道，JVM调优的一个环节，也就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现STW（Stop the World）的问题，而 Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上
JVM在进行GC时，并非每次都对上面三个内存( 新生代、老年代；方法区 )区域一起回收的，大部分时候回收的都是指新生代。针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）
部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：新生代收集（ Minor GC/Young GC ）：只是新生代( Eden、S0/S1 )的垃圾收集老年代收集（ Major GC/Old GC ）：只是老年代的垃圾收集。目前，只有CMS GC会有单独收集老年代的行为。注意，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集。目前，只有G1 GC会有这种行为整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。————————————————版权声明：本文为CSDN博主「JavaAlenboy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/sj15814963053/article/details/110246331