微信小程序模板网站,精美网站设计,四川建筑职业技术学院就业网,上海网站建设制作公你好#xff0c;我是 shengjk1#xff0c;多年大厂经验#xff0c;努力构建 通俗易懂的、好玩的编程语言教程。 欢迎关注#xff01;你会有如下收益#xff1a;
了解大厂经验拥有和大厂相匹配的技术等
希望看什么#xff0c;评论或者私信告诉我#xff01; 文章目录 一…你好我是 shengjk1多年大厂经验努力构建 通俗易懂的、好玩的编程语言教程。 欢迎关注你会有如下收益
了解大厂经验拥有和大厂相匹配的技术等
希望看什么评论或者私信告诉我 文章目录 一、前言二、JVM 分代2.1 JVM 中对象生命周期分布2.2 JVM 分代图2.3 特殊情况G1收集器内存分代Parallel Collector 分代 三、GC测试3.1 查看 JVM 模型配置3.2 代码测试3.3 GC 日志解释 四、总结 一、前言
写过 java 的小伙伴肯定都知道 JVM 分为年轻代、永久代但为什么这么分有没有什么理论基础呢
二、JVM 分代
2.1 JVM 中对象生命周期分布
经过对大量实际应用程序的观察和分析得出如下图 x 轴表示对象在生命周期内分配的字节数。 y 轴上表示相应生命周期内的对象占用的总字节数。左边的尖峰代表分配后不久可以回收的对象。蓝色区域表示对象生命周期的典型分布。所以可以得出如下结论
大多数对象的生命周期很短暂在许多应用程序中绝大多数对象的生命周期都非常短暂即它们很快就会变成垃圾被回收掉少数对象的生命周期较长虽然大部分对象很快就会被回收但也有一小部分对象的生命周期比较长它们可能会存活很长时间
为了优化上述的两点在内存管理方面JVM按代进行管理利用内存池保存不同年龄的对象。每当某一代充满时会触发垃圾收集操作。
大多数对象被分配到年轻代其中绝大多数对象最终在这一代消亡。当年轻代达到容量时会触发垃圾收集只针对年轻代进行垃圾回收而其他代中的垃圾暂不处理。在每次次要收集时一部分幸存对象会被移至永久代。永久代最终也会填满需要对整个堆进行回收持续的时间通常年轻代长因为牵扯的对象数量更多。
2.2 JVM 分代图
JVM默认的分代图需要注意的是排除Parallel Collector and G1回收算法 在初始化时虚拟地保留最大地址空间但除非需要否则不会分配给物理内存。为对象内存保留的完整地址空间可以分为年轻代和终身代。年轻代由 eden 和两个 survivor 空间组成。大多数对象最初是在 eden 中分配的。一个survivor 空间在任何时候都是空的并且作为 eden 中任何存活对象的目的地另一个 survivor 空间是下一次复制收集期间的目的地。对象以这种方式在幸存者空间之间复制直到它们足够老而可以被保留复制到终身代。
2.3 特殊情况
G1收集器内存分代
不再明显的分代概念与传统的分代收集器不同G1收集器没有严格的年轻代和老年代的划分。它将整个堆分为多个大小相等的区域Region并根据垃圾收集的活动动态地划分为年轻代和老年代区域。独特的回收方法在G1中每个区域都可以用作年轻代或老年代因此没有严格意义上的固定分代。它会选择多个区域进行垃圾收集并使用一种叫做“垃圾优先”Garbage First算法来进行整体的堆回收。
Parallel Collector 分代
在Parallel Collector中与其他经典的垃圾收集器如Serial收集器和CMS收集器不同它在新生代的设计中没有显式地使用Eden区和Survivor区的划分。而是将新生代划分为一部分专门用于存放对象的区域这使得Parallel Collector更注重整个新生代的高效垃圾回收
三、GC测试
3.1 查看 JVM 模型配置
java -XX:PrintCommandLineFlags -version我这台机器的默认配置如下
-XX:InitialHeapSize264819584 -XX:MaxHeapSize4237113344 -XX:PrintCommandLineFlags -XX:UseCompressedClassPointers -XX:UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:UseParallelGC
openjdk version 1.8.0_332
OpenJDK Runtime Environment (Temurin)(build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.332-b09, mixed mode)解释如下
- -XX:InitialHeapSize264819584设置 JVM 初始堆内存大小为大约 **252MB**。这是 JVM 启动时分配的最小堆内存量。
- -XX:MaxHeapSize4237113344设置 JVM 最大堆内存大小为大约 **4040MB**即约 **3.94GB**。这是 JVM 堆内存能够增长到的最大限度。在运行过程中如果堆内存需求增加JVM 堆大小可以动态增长直至此上限。
- -XX:PrintCommandLineFlags指示 JVM 在启动时打印出所有的命令行标志参数这有助于调试和记录当前虚拟机的配置状态。
- -XX:UseCompressedClassPointers启用类指针的压缩。在 64 位 JVM 上这可以减少类元数据占用的内存空间从而降低内存消耗并可能提升性能。
- -XX:UseCompressedOops启用“普通对象指针Ordinary Object Pointers”的压缩。此设置减少了64位系统上对象引用的大小从而减少了内存使用并且没有显著影响到性能。这是提升大内存Java应用性能的一项常用技术。
- -XX:-UseLargePagesIndividualAllocation禁止为每个大页面Large Page进行单独的分配。大页面技术通常用于提高大型应用的性能通过减少页面表条目的数量来减少CPU缓存的压力但需要操作系统的支持。这个参数指定了不使用单独分配大页的方式这可能是因为配置了通用的大页支持或者没有需求使用该特性。
- -XX:UseParallelGC启用 Parallel 垃圾收集器。Parallel 收集器是一个并行的新生代垃圾收集器使用多线程来提高垃圾收集效率主要目标是增加应用程序的吞吐量。3.2 代码测试
public static void main(String[] args) {while (true){try {TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}ArrayListObject objects new ArrayList(1024);for (int i 0; i 1024 * 10; i) {objects.add(new Object[]{});}}
}不断的创建 List为了更快的观察到 GC 日志我们设置
-Xmx80m -verbose:gc -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:./gc.log解释如下
- -Xmx20m设置了 Java 堆的最大内存为 **20MB**。这个参数限制了 Java 程序运行时最大可用的堆内存大小超过这个大小后 JVM 将会抛出 OutOfMemoryError 错误。
- -verbose:gc启用了垃圾回收输出信息。当垃圾回收器执行垃圾回收时会输出简要的垃圾收集情况包括开始和结束的时间点。
- -XX:PrintGCDetails详细输出垃圾收集的信息。这个参数会打印出关于每次垃圾收集的详细信息包括各个区域的使用情况、垃圾回收时间、被收集对象等信息。
- -XX:PrintGCDateStamps打印垃圾回收发生的日期时间戳。此参数会在详细的垃圾收集日志中包含日期时间信息有助于更好地跟踪和分析垃圾回收的情况。
- -Xloggc:./gc.log将垃圾收集日志输出到指定的文件中这里指定为当前目录下的 gc.log 文件。通过这个参数JVM 会将详细的垃圾收集日志记录到指定文件中可以用于后续分析和调试。运行上述代码可以看到 GC 日志如下
OpenJDK 64-Bit Server VM (25.332-b09) for windows-amd64 JRE (1.8.0_332-b09), built on Apr 23 2022 01:25:28 by jenkins with MS VC 12.0 (VS2013)
Memory: 4k page, physical 16551224k(667012k free), swap 52371688k(14504324k free)
CommandLine flags: -XX:InitialHeapSize20971520 -XX:MaxHeapSize20971520 -XX:PrintGC -XX:PrintGCDateStamps -XX:PrintGCDetails -XX:PrintGCTimeStamps -XX:UseCompressedClassPointers -XX:UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:UseParallelGC
2024-05-21T20:05:55.6590800: 8.192: [GC (Allocation Failure) [PSYoungGen: 5632K-510K(6144K)] 5632K-1384K(19968K), 0.0024955 secs] [Times: user0.00 sys0.00, real0.00 secs]
2024-05-21T20:06:15.8070800: 28.340: [GC (Allocation Failure) [PSYoungGen: 6142K-488K(6144K)] 7016K-1369K(19968K), 0.0008134 secs] [Times: user0.00 sys0.00, real0.00 secs]
2024-05-21T20:06:34.9360800: 47.468: [GC (Allocation Failure) [PSYoungGen: 6120K-502K(6144K)] 7001K-1440K(19968K), 0.0009532 secs] [Times: user0.00 sys0.00, real0.00 secs]
2024-05-21T20:06:55.1740800: 67.706: [GC (Allocation Failure) [PSYoungGen: 6134K-504K(6144K)] 7072K-1449K(19968K), 0.0008710 secs] [Times: user0.00 sys0.00, real0.00 secs]
2024-05-21T20:07:14.3560800: 86.888: [GC (Allocation Failure) [PSYoungGen: 6136K-492K(6144K)] 7081K-1486K(19968K), 0.0007995 secs] [Times: user0.00 sys0.00, real0.00 secs]
2024-05-21T20:07:33.5360800: 106.068: [GC (Allocation Failure) [PSYoungGen: 6078K-486K(4096K)] 7072K-1496K(17920K), 0.0010000 secs] [Times: user0.00 sys0.00, real0.00 secs]
2024-05-21T20:07:46.6210800: 119.153: [GC (Allocation Failure) [PSYoungGen: 4070K-160K(5120K)] 5080K-1501K(18944K), 0.0004745 secs] [Times: user0.00 sys0.00, real0.00 secs] 3.3 GC 日志解释
我们一块一块的解释 OpenJDK 64-Bit Server VM (25.332-b09) for windows-amd64 JRE (1.8.0_332-b09), built on Apr 23 2022 01:25:28 by jenkins with MS VC 12.0 (VS2013)这段 GC 日志提供了关于 JVM 的版本信息和构建详情下面是对这部分日志的解释- **OpenJDK 64-Bit Server VM (25.332-b09) for windows-amd64 JRE (1.8.0_332-b09)** 这部分说明了 JVM 的具体信息。其中- OpenJDK 64-Bit Server VM 表示这是一个64位的服务器端虚拟机。- 25.332-b09 是 JVM 的版本号提供了关于编译版号的详细信息。- windows-amd64 表示 JVM 运行在 Windows 系统的 64 位架构上。- JRE (1.8.0_332-b09) 提供了 Java 运行时环境版本信息。- **Built on Apr 23 2022 01:25:28 by jenkins with MS VC 12.0 (VS2013)** 这部分提供了 JVM 构建的时间和工具信息。- Built on Apr 23 2022 01:25:28 表示 JVM 是在 2022年4月23日凌晨01:25:28 构建的。- by jenkins 表示使用 Jenkins 自动化工具构建。- with MS VC 12.0 (VS2013) 表明使用 Microsoft Visual C 12.0 (VS2013) 编译器来构建 JVM。Memory: 4k page, physical 16551224k(667012k free), swap 52371688k(14504324k free)这段 GC 日志中提供了关于系统内存情况的信息下面是对这段日志的解释- **Memory: 4k page**指定系统内存页的大小为 4KB。这表示系统在管理内存时使用 4KB 作为一页的基本单位。这是操作系统中很常见的内存页大小。
- **physical 16551224k(667012k free)** 表示系统的物理内存情况。在括号内的部分是具体数值16551224k 表示系统的物理内存总共为 16,551,224 KB约 16.5 GB其中 667,012 KB约 667 MB是可用的空闲内存。系统内存中可能包括用于程序运行和缓存的内存等。
- **swap 52371688k(14504324k free)** 给出了系统的交换空间swap space情况。在括号内的部分表示具体数值52371688k 表示总共的交换空间为 52,371,688 KB约 52.4 GB其中有 14,504,324 KB约 14.5 GB是可用的空闲交换空间。交换空间是硬盘上用来扩展物理内存的一部分当物理内存不足时操作系统会将部分数据从内存中交换到硬盘的交换分区swap partition中。2024-05-21T20:07:46.6210800: 119.153: [GC (Allocation Failure) [PSYoungGen: 4070K-160K(5120K)] 5080K-1501K(18944K), 0.0004745 secs] [Times: user0.00 sys0.00, real0.00 secs]这段 GC 日志提供了一次垃圾回收事件的详细信息下面是对这条日志的解释- **时间戳信息**2024年5月21日UTC0800时区具体时间为20:07:46.621。这个时间戳提供了垃圾回收事件发生的时间。- **持续时间信息**从上次垃圾回收到本次垃圾回收经过了约119.153秒。- **GC事件**这次垃圾回收事件是由“Allocation Failure”引起的即由于在年轻代进行对象分配时失败触发了垃圾回收。- **PSYoungGen信息**涉及的内存区域为 PSYoungGenParallel Scavenge算法的年轻代。具体变化如下- 在垃圾回收前年轻代中的内存从4070KB减少到160KB。- 年轻代的总容量为5120KB表示年轻代的总大小。- **整个堆内存信息**整个堆的内存变化如下- 在垃圾回收前整个堆内存从5080KB减少到1501KB。- 整个堆的总容量为18944KB表示整个堆的总大小。- **耗时信息**垃圾回收过程耗时为0.0004745秒。- user0.00 表示用户态时间为0秒。- sys0.00 表示系统态时间为0秒。- real0.00 表示实际时间为0秒。综合解释这条 GC 日志记录了一次由“Allocation Failure”引发的垃圾回收事件描述了年轻代和整个堆内存的变化情况以及垃圾回收过程的耗时信息四、总结
JVM的分代机制是为了优化内存管理将内存分为年轻代和老年代利用内存池保存不同年龄的对象。
大多数对象被分配到年轻代其中绝大多数对象最终在这一代消亡。当年轻代达到容量时会触发垃圾收集只针对年轻代进行垃圾回收而其他代中的垃圾暂不处理。在每次次要收集时一部分幸存对象会被移至永久代。永久代最终也会填满需要对整个堆进行回收持续的时间通常年轻代长因为牵扯的对象数量更多。
