Java底层堆内存、GC等知识点阐述

本文主要是介绍Java底层堆内存、GC等知识点阐述，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

堆(年轻代与老年代知识点)

年轻代(新生区) 堆

新生代主要用于存放新创建的对象，这些对象由于频繁创建和销毁，因此会频繁触发Minor GC（小型垃圾回收）来清理不再使用的对象，以保持新生代的健康和高效运行。

堆≠伊甸园

在Java虚拟机(JVM)中，内存被划分为不同的区域，其中堆是JVM管理的最大一块内存空间，用于存放对象实例和数组。堆内存的大小是可以调节的，并且所有的线程共享Java堆。然而，伊甸园（Eden space）是堆内存中的一个特定区域，位于新生代中，是对象出生的地方，所有新的对象都是在伊甸园区被创建的。新生代还包括幸存区（Survivor space），分为两个幸存区，用于存放从伊甸园中幸存下来的对象。这些区域共同构成了堆内存的一部分，但伊甸园只是堆内存中的一个子区域，专门用于对象的初始创建‌。
简而言之，堆是Java内存管理的核心区域，而伊甸园是堆内存中的一个具体区域，专门用于新生对象的创建。如下图所示1-1

（图1-1）

堆(含有三个区域：伊甸园和两个幸存者)

当伊甸园区满了以后会使用GC回收不在引用对象销毁，而剩余对象在两个幸存者之间倒腾(折腾)。

为什么是两个幸存者，一个幸存者存在不就可以嘛？

原因分析

主要原因是内存碎片，内存碎片分为内部和外部碎片，下面以外部碎片举例
1.现在创建了4个对象 ，分别是stu(学生)、clas(年级)、grades(成绩)、sub(科目)

2.现在垃圾收集器，从内存中删除了grades(成绩)，内存就变成了如下结构

3.假如现在需要创建一个更大的新的“tea(老师)”对象，但是在图中可以看出，tea没有足够大的连续空间可以放了，那么由此造成空间浪费，成为内存碎片

4.FULL GC
当产生内存碎片时，会调用 full gc 来整理内存，就可以将tea放入了

分析总结

full gc 最终会导致JVM暂停较长时间，非常影响效率。因此为了解决存在碎片带来的麻烦，再划分一个幸存者区，将gc回收之后的Survivor0区(from)倒腾到Survivor1区(幸存者区1或称为To区)，就可以避免这种问题，是一种空间换时间的思路。

老年代 堆

Java中的老年代（Old Generation）是Java虚拟机(JVM)内存管理中的一个重要部分，它和新生代一起共同管理着Java对象的内存分配和回收。

对象在新生代中存活了一定的时间（通常是通过复制算法来判断对象的“年龄”），并且没有被回收，那么这些对象就会被“晋升”到老年代。老年代中的对象相对稳定，因此Major GC（大型垃圾回收）不会像Minor GC那样频繁执行。老年代的对象比较稳定，所以在进行Major GC前一般都先进行了一次Minor GC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发Major GC进行垃圾回收。当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）内存溢出异常。

老年代的垃圾回收（Major GC）采用标记-清除算法，首先扫描所有老年代中的对象，标记出存活的对象，然后回收没有标记的对象。这种方式的耗时比较长，因为需要扫描并回收大量对象，可能会导致内存碎片化。为了减少内存损耗，可能需要进行合并或标记出空闲空间以便下次直接分配。

总的来说，老年代是Java内存管理中的一个关键部分，它存储了那些在新生代中存活下来并且不再频繁变动的对象，这些对象由于相对稳定，因此其垃圾回收的频率要比新生代低得多‌

GC种类

1.Minor GC‌：主要发生在新生代（Young Generation），包括Eden区和Survivor区。当Eden区满了或者Survivor区无法容纳从Eden区复制过来的对象时，会触发Minor GC。Minor GC主要负责清理年轻代中的内存，包括Eden区和Survivor区的清理‌12。
‌2.Major GC‌：当老年代（Old Generation）内存不足时，会触发Major GC，主要负责清理老年代区的内存‌12。
‌3.Full GC‌：Full GC是清理整个堆空间的垃圾回收，包括年轻代和老年代。Full GC通常是由于Minor GC和Major GC频繁触发，或者系统资源紧张等原因导致的‌

垃圾回收

什么是垃圾回收

在Java中，对象是在堆内存上分配的，当这些对象不再被任何部分的应用所引用时，这些对象就被认为是垃圾。垃圾回收器的任务就是找到这些不再被需要的对象，并释放它们占据的内存空间，以供新对象使用。

为什么需要垃圾回收

无法控制内存是许多程序可能遇到的问题。例如，内存泄漏，这通常发生在程序不再需要的数据没有被及时清理的情况下，长此以往可能导致内存耗尽，最终程序崩溃。通过自动垃圾回收，Java试图避免这种情况。

回收器

垃圾回收器可以根据具体的业务场景选择最合适的进行搭配使用。例如，新生代收集器可以与老年代收集器搭配使用，如Serial与Serial Old搭配，或ParNew与CMS搭配，以满足不同的性能和资源需求‌

新生代垃圾回收器

‌新生代的垃圾回收器包括Serial收集器、ParNew收集器、Parallel Scavenge收集器。

Serial收集器：单线程进行垃圾回收操作，适用于单核服务器或Client模式（桌面应用）。

# 添加该参数来显式的使用Serial垃圾收集器。
-XX:+UseSerialGC

ParNew收集器：Serial收集器的多线程版本，适用于多核CPU环境，多线程进行新生代的垃圾回收。

# 指定使用CMS后，会默认使用ParNew作为新生代收集器。
-XX:+UseConcMarkSweepGC
# 强制指定使用ParNew。   
-XX:+UseParNewGC
# 指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同。
-XX:ParallelGCThreads

Parallel Scavenge收集器：适用于追求吞吐量高的场景，当Eden区内存不足时，发生Minor GC，采用标记复制法进行垃圾回收。

# Parallel Scavenge收集器提供了两个参数来用于精确控制吞吐量，
#一是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis参数，
#二是控制吞吐量大小的 -XX：GCTimeRatio参数；#参数允许的值是一个大于0的毫秒数，收集器将尽可能的保证内存垃圾回收花费的时间不超过设定的值（但是，并不是越小越好，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，如果设置的值太小，将会导致频繁GC，这样虽然GC停顿时间下来了，但是吞吐量也下来了）。
-XX：MaxGCPauseMillis# 参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，默认值是99，就是允许最大1%（即1/（1+99））的垃圾收集时间。
-XX：GCTimeRatio#参数是一个开关，如果这个参数打开之后，虚拟机会根据当前系统运行情况收集监控信息，动态调整新生代的比例、老年大大小等细节参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略。
-XX：UseAdaptiveSizePolicy

老年代垃圾回收器

老年代的垃圾回收器包括Serial Old收集器、CMS收集器、Parallel Old收集器。

Serial Old收集器：用于老年代的垃圾回收，采用单线程方式进行回收操作。
CMS收集器：以最短回收停顿时间为目标的垃圾回收器，采用并发标记和清除的方式进行老年代的垃圾回收。

1.初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。
2.并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。
3.重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要“Stop The World”。
4.并发清除（CMS concurrent sweep）由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作

## 新生代 ParNew + 老年代 CMS + 老年代 Serial Old
# 某些版本的参数是这样的： -XX:+UseConcurrentMarkSweepGC
-XX:+UseConcMarkSweepGC# 响应时间优先，停顿时间，是一个建议时间，GC会尝试用各种手段达到这个时间，比如减小年轻代，默认 18446744073709551615  
-XX:MaxGCPauseMillis
# 吞吐量优先，设置JVM吞吐量要达到的目标值， GC时间占用程序运行时间的百分比的差值，默认是 99
# 也就应用程序线程应该运行至少99%的总执行时间，GC占 1%
-XX:GCTimeRatio=99# 并行收集器（ParNew , STW,  YGC）的线程数，默认CPU所支持的线程数，如果CPU所支持的线程数大于8，则 默认 8 + (logical_processor -8)*(5/8)
-XX:+ParallelGCThreads
#  CMS垃圾回收线程数量
-XX:ParallelCMSThreads# 解决 CMS `Memory Fragmentation` 碎片化， 开启FGC时进行压缩，以及多少次FGC之后进行压缩
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=3
# 解决 CMS `Concurrent mode failure` ，`Promotion Failed`晋升失败  
# 使用多少比例的老年代后开始CMS收集，默认是68%(近似值)，如果频繁发生SerialOld卡顿，应该调小，（频繁CMS回收）
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70# 开启 CMS 元空间的垃圾回收
-XX:+CMSClassUnloadingEnabled
# -XX:CMSInitiatingPermOccupancyFraction  （JDK8已经移除）

Parallel Old收集器：并行老年代垃圾回收器，使用多线程并行进行老年代的垃圾回收。

JDK1.8默认的垃圾回收器，以下为jdk1.8说明

默认：Parallel GC(Throughput GC)
Parallel是一种多线程的垃圾回收器，他主要的目标就是最大化吞吐量（吞吐量是值应用程序实际执行代码的时间相对于总时间（包括垃圾回收时间））的比例。Parallel GC在老年代和新生代垃圾回收会使用多线程执行。

新生代：使用的是复制算法。

老年代：采用的是MSC回收算法

MSC （Mark-Sweep-Compact）
Marking 标记：
在标记就单，垃圾回收器回遍历堆中的所有对象，识别出来哪些对象是可达的。并且将这些活跃的对象标记为活跃的伙计。这个过程通常是通过（GC Roots，通常是静态变量、栈中的引用等）开始进行的。

Sweeping 清除：
在清除阶段，垃圾回收器回扫描堆中的没有被标记的对象，将这些对象从内存中释放，一边以后可以分配给新的对象。这一步只会简单清楚不可达的对象，不会对内存进行整理。因此可能导致内存碎片化的问题。

Compacting 压缩：
压缩阶段可以解决内存碎片化的问题。在清除阶段之后，堆中可能出现碎片，这些碎片会导致内存分配不连续和低效。

工作流程
标记阶段：首先，标记所有存活的对象。

清除阶段：接着，清除所有未标记的对象，将它们的内存回收。

压缩阶段：最后，压缩存活的对象，将它们集中到堆的一端，释放出连续的可用内存。

优点
可以有效地回收内存并减少内存碎片，然后后续的内存分配更加高效。

适合老年代，因为老年代中对象存活率较高。内存碎片可能更为严重。

缺点
MSC可能会导致比较长时间的Stop-the-world（STW）停顿。因为压缩过程中，整个堆中的所有对象都可能需要移动。

开销比较大：压缩阶段需要复制和移动大量的对象，这增加了垃圾回收的开销。

springboot GC垃圾回收器使用示例

方式一、在application.properties或application.yml文件中设置JVM参数

# 设置JVM参数
spring.jmx.enabled=false# 示例使用并行垃圾收集器
spring.application.jvm-args=-XX:+UseParallelGC

方式二、在启动Spring Boot应用时通过命令行指定

java -XX:+UseParallelGC -jar your-spring-boot-app.jar

使用串行垃圾收集器：-XX:+UseSerialGC使用并行垃圾收集器：-XX:+UseParallelGC使用并行垃圾收集器（G1）：-XX:+UseG1GC设置新生代的并行线程数：-XX:ParallelGCThreads=<number>设置最大垃圾收集暂停时间（仅G1）：-XX:MaxGCPauseMillis=<milliseconds>设置G1的区域数量：-XX:G1HeapRegionSize=<size>

这篇关于Java底层堆内存、GC等知识点阐述的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---