JVM堆内存（heap）

墨蓝 2022-09-11 07:19 176阅读 0赞

# 堆的核心概述 #

>  *  一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
>  *  Java堆区在JVM启动的时候即被创建，其空间大小也就确定了。是JVM管理的最大1块内存空间。堆内存的大小是可以调节的。**-Xms**、**-Xmx**表示**初始堆空间大小**和**最大堆空间大小**。
>  *  《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
>  *  **所有的线程共享Java堆**，在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer, TLAB) 。
>  *  《Java虚拟机规范》中对Java堆的描述是:**几乎所有的****对象实例****以及****数组****都应当在运行****时分配在堆****上**。“几乎”所有的对象实例都在这里分配内存，———从实际使用角度看的。
>  *  数组和对象可能永远不会存储在栈上，因为栈帧中保存**引用**，这个引用指向对象或者数组在堆中的位置。
>  *  在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。
>  *  堆，是GC ( Garbage Collection，垃圾收集器)执行垃圾回收的重点区域。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70]

#  堆空间划分 #

现代垃圾收集器大部分都基于分代收集理论设计,堆空间细分为:（约定:新生区=新生代=年轻代，养老区=老年区=老年代，永久区=永久代  
，这几个名字不做区分，就行一个类中属性可以叫字段可以叫属性一样）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 1]

#  堆空间大小设置 #

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，可以通过选项"-Xmx"和" -Xms"来进行设置。  
➢**“-Xms"** 用于表示堆区的起始内存（新生代和老年代），等价于-XX: InitialHeapSize  
➢**“-Xmx"** 则用于表示堆区的最大内存（新生代和老年代），等价于-XX :MaxHeapSize  
**一旦堆区中的内存大小超过“-Xmx"所指定的最大内存时**，将会抛出**OutOfMemoryError**异常。  
通常会将-Xms 和- -Xmx两个参 数配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小，从而提高性能。  
默认情况下，初始内存大小:物理电脑内存大小/ 64，最大内存大小：物理申脑内存大小/4

# 新生代和老年代 #

*  存储在JVM中的Java对象可以被划分为两类:

> 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
> 
> 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致。

*  Java堆区进一步细分的话， 可以划分为**新生代**(YoungGen)和**老年代**(OldGen)
 *  其中年轻代又可以划分为**Eden空间**、**Survivor0**空间和**Survivor1**空间 (有时也叫做from区、to区)。
 *  配置新生代与老年代在堆结构的占比。

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 2]

在HotSpot中，Eden空间和另外两个Survivor空间缺省所占的**比例是8:1:1**,当然开发人员可以通过选项“**-XX: SurvivorRatio**"调整这个空间比例。比如-XX : SurvivorRatio=8  
**几乎****所有的Java对象都是在Eden区被new出来的,**绝大部分的Java对象的销毁都在新生代进行了。（IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。）可以使用选项"-Xmn"设置新生代最大内存大小，这个参数一般使用默认值就可以了。

# 对象分配过程 #

## 对象分配一般过程 ##

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

1.  **new**出来的对象先放**Eden区****,**此区有大小限制。当Eden区空间填满时，程序又需要创建对象，触发JVM的垃圾回收器将对Eden区进行垃圾回收(Minor GC或者Young GC)（survivor区满的时候不会触发，但是并不是说不会进行垃圾回收，只是说当Eden区满触发GC时会将eden和survivor区一起进行垃圾回收，survivor区是被动的进行而已），将Eden区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到Eden区。
2.  然后将Eden区中的剩余对象移动到S0区。
3.  如果再次触发垃圾回收，此时不仅会对Eden区进行判断，还会对上次幸存下来的放到S0区的对象进行判断，如果没有被回收，就会放到S1区。如果再次经历垃圾回收，此时会重新放回S0区，接着再去S1区……（每个对象分配有一个**年龄计数器**，存放区换（复制）一次值就加一），**S0和S1有个别名是from和to区，这里说的是在GC过后（上一次复制之后），这两个区中那个为空那个就是to区另一个就是from区，表示下次GC时Eden区的对象应该往哪里放。（复制之后有交换，谁空谁是to）**（Eden区的对象经过GC后总是将对象放入to区的）
4.  啥时候能去老年代呢?可以设置次数（最大进入老年代的阈值）。**默认是15次**。**可以设置参数: -XX;MaxTenuringThreshold=进行设置。当年龄计数器大于等于这个值时，如果这个对象还没被销毁就会存放到老年代中了。**
5.  在老年代，相对悠闲。当老年代内存不足时，再次触发GC: Major GC，进行老年代的内存清理
6.  若老年代执行了Major GC之后发现依然无法进行对象的保存，就会所谓朝生夕死：产生**OOM异常**：java. lang. OutOfMemoryError: Java heap space **关于垃圾回收:****频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集**。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 3]

## 对象分配特殊过程 ##

> **注意：**每次Minor GC或者Young GC后eden区应该是空的，因为是垃圾对象就被回收了，不是垃圾对象就被放入to区了。  
> 如果此时再往eden区放一个超大对象发现放不下，就会直接放到老年代，如果老年代也放不下，可能原因老年代空间不足或者就是老年代空间直接小于这个超大对象，这是会出现**majorGC**或**fullGC**，如果majorGC或fullGC后还存不下该对象，且此jvm实例不会自动调整内存空间（jvm实际上是有自动调整内存空间机制的），就会出现OOM。

同理Minor GC或者Young GC（eden区和survivor都进行了垃圾回收）后，eden区的对象在放入to区时，如果放不下时，就会把把对象放入老年代区，也有可能survivor1和survivor0在被动的进行GC时发现对象的年龄计数器大于最大进入老年区阈值时也会直接晋升老年区。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 4]

代码演示：

//配置为：-Xms600m -Xmx600m
    public class HeapInstanceTest {
        byte[] buffer=new byte[new Random().nextInt(1024*200)];
    
        public static void main(String[] args){
            List<HeapInstanceTest> list=new ArrayList<>();
            while (true){
                list.add(new HeapInstanceTest());
                try {
                    Thread.sleep(10);
                }catch (InterruptedException e){
                    e.printStackTrace();
                }
            }
        }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 5]

# GC分类 #

Java中Stop-The-World机制简称STW，是在执行垃圾收集算法时，Java应用程序的其他所有线程都被挂起（除了垃圾收集帮助器之外）。Java中一种**全局暂停现象**，全局停顿，所有Java代码停止，native代码可以执行，但不能与JVM交互；**这些现象多半是由于gc引起**。GC时的Stop the World(STW)是大家最大的敌人。

JVM在进行GC时，并非每次都对新生代、老年代、方法区（1.7之前叫永久带，1.8后叫元空间）一起回收的，大部分时候回收的都是指新生代（80%对象是朝生夕死）。.  
针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大种类型:一种是**部分收集(Partial GC)**，一种是**整堆收集(Full GC)**

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

> 新生代收集(Minor GC / Young GC) :只是新生代的垃圾收集  
> 老年代收集(Major GC / Old GC) :只是老年代的垃圾收集。目前，只有CMS GC会有单独收集老年代的行为。**注意**，很多时候Major GC会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收。这里如果别人提到了majorGC就可以问问他：你说的majorGC指的就是老年代的GC还是整堆的GC了 ？  
> 混合收集(Mixed GC): 收集整个新生代以及部分老年代的垃圾收集。目前，只有G1 GC会有这种行为

*  整堆收集(Full GC):**收集整个java堆和方法区**的垃圾收集。

## MinorGC ##

**新生代GC(Minor GC)触发机制:**

*  当新生代空间不足时，就会触发Minor GC,这里的新生代满指的是Eden代满，Survivor满不会引发GC。(每次 Minor GC会清理新生代（Eden和surviv or）的内存。)
 *  因为Java对象**大多都具备朝生夕灭的特性**，所以Minor GC非常频繁，一般回收速度也比较快。这一定义既清晰又易于理解。
 *  Minor GC会引发STW， 暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。Minor GC频率虽然很高，但是其执行速度很快，而且新生代空间较小，所有对用户线程影响其实不是多大。

## MajorGC ##

**老年代GC (Major GC/Fu1l GC)触发机制:**

*  指发生在老年代的GC，对象从老年代消失时，我们说“Major GC”或“Fu1l GC”发生了。
 *  出现了Major GC，**经常会伴随至少一次的Minor GC** (但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足，则触发Major GC
 *  Major GC的速度一般会比Minor GC慢10倍以 上，STW的时间更长。老年代空间比年轻代大一些。
 *  如果Major GC后，内存还不足，就报OOM了。

## FullGC ##

Fu11 GC触发机制:  
触发Full GC执行的情况有如下五种:

> (1) 调用System.gc()时，系统建议执行Full GC，但是不必然执行  
> (2) 老年代空间不足（老年代空间不足，在不GC就OOM，这其实可能是Major GC会和Full GC混淆使用情况）  
> (3) 方法区空间不足  
> (4) 通过Minor GC后进入老年代的平均大小大于老年代的可用内存  
> (5) 由Eden区、survivor space0 (From Space) 区向survivor space1 (To Space)区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小，其实也就是老年代空间不足的情况而已。

说明:**full gc是开发或调优中尽量要避免的。这样暂停时间会短一些**。（方法区的回收包括不用的类回收和类加载器回收等，使stw时间增长）

# 为什么需要把Java堆分代?不分代就不能正常工作了吗? #

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

# TLAB #

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

多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能够提升内存分配的吞吐量，因此我们可以将这种内存分配方式称之为快速分配策略。据了解貌似所有openJDK衍生出来的JVM都提供了TLAB的设计。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 6]

尽管不是所有的对象实例都能够在TLABR成功分配内存，但\*\*JVM确实是将TLAB作为内存分配的首选。\*\*在程序中，开发人员可以通过选项“-XX:UseTLAB"设置是否开启TLAB空间，默认是开启。  
默认情况下，TLAB空间的内存非常小，仅占有整个Eden空间的1%，当然我们可以通过选项“-XX: TLABWasteTargetPercent”设置TLAB空间所占用Eden空间的百分比大小。  
一旦对象在TLAB空间分配内存失败时，JVM就会尝试着通过使用加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存。

**为什么有TLAB ( Thread Local Allocation Buffer ) ?**  
●堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据  
●由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的  
●为避免多个线程操作同一地址，需要使用加锁等机制，但是进而影响分配速度。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 7]

问：堆都是共享的吗 ？不是，TLAB是线程私有的。

# 堆空间的参数设置 #

官网说明:[https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html][https_docs.oracle.com_javase_8_docs_technotes_tools_unix_java.html]

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70]: /images/20220828/3e712818232d43c48f2b1d0f173931f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 1]: /images/20220828/60b32dfcc7364445bace515e8fee79ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 2]: /images/20220828/023d900ad9e34d86a8a7bbac735b4a3b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 3]: /images/20220828/9a3d06aa71cd40929e358630551486c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 4]: /images/20220828/c2328d2610b0494884c03e20101aaec0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 5]: /images/20220828/44e609aba2474730959888942e3c62af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 6]: /images/20220828/8afe0a33f67f4791ba39ede31eab28c8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ltMTUyMjk5OTQzMTh5bQ_size_16_color_FFFFFF_t_70 7]: /images/20220828/a7afa481a6e540bf944e0181dd23aff9.png
[https_docs.oracle.com_javase_8_docs_technotes_tools_unix_java.html]: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html