JVM 判断对象已死,实践验证GC回收
持续坚持原创输出,点击蓝字关注我吧
作者:小傅哥
博客:https://bugstack.cn
❝沉淀、分享、成长,让自己和他人都能有所收获!😜
❞
目录
一、前言
二、面试题
三、先动手验证垃圾回收
四、JVM 垃圾回收知识框架
1. 判断对象已死
2. 垃圾回收算法
3. 垃圾回收器
五、总结
六、系列推荐
一、前言
提升自身价值有多重要?
经过了风风雨雨,看过了男男女女。时间经过的岁月就没有永恒不变的!
在这趟车上有人下、有人上,外在别人给你点评的标签、留下的烙印,都只是这趟车上的故事。只有个人成长了、积累了、沉淀了,才有机会当自己的司机。
可能某个年龄段的你还看不懂,但如果某天你不那么忙了,要思考思考自己的路、自己的脚步。看看这些是不是你想要的,如果都是你想要的,为什么你看起来不开心?
好!加油,走向你想成为的自己!
二、面试题
谢飞机,小记!
,中午吃饱了开始发呆,怎么就学不来这些知识呢,它也不进脑子!
「谢飞机」:喂,面试官大哥,我想问个问题。
「面试官」:什么?
「谢飞机」:就是这知识它不进脑子呀!
「面试官」:这....
「谢飞机」:就是看了忘,忘了看的!
「面试官」:是不是没有实践?只是看了就觉得会了,收藏了就表示懂了?哪哪都不深入!?
「谢飞机」:好像是!那有什么办法?
「面试官」:也没有太好的办法,学习本身就是一件枯燥的事情。减少碎片化的时间浪费,多用在系统化的学习上会更好一些。哪怕你写写博客记录下,验证下也是好的。
三、先动手验证垃圾回收
说是垃圾回收,我不引用了它就回收了?什么时候回收的?咋回收的?
没有看到实际的例子,往往就很难让理科生接受这类知识。我自己也一样,最好是让我看得见。代码是对数学逻辑的具体实现,没有实现过程只看答案是没有意义的。
「测试代码」
public class ReferenceCountingGC {
public Object instance = null;
private static final int _1MB = 1024 * 1024;
/**
* 这个成员属性的唯一意义就是占点内存, 以便能在GC日志中看清楚是否有回收过
*/
private byte[] bigSize = new byte[2 * _1MB];
public static void main(String[] args) {
testGC();
}
public static void testGC() {
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
// 假设在这行发生GC, objA和objB是否能被回收?
System.gc();
}
}
例子来自于《深入理解Java虚拟机》中引用计数算法章节。
例子要说明的结果是,相互引用下却已经置为null的两个对象,是否会被GC回收。如果只是按照引用计数器算法来看,那么这两个对象的计数标识不会为0,也就不能被回收。但到底有没有被回收呢?
这里我们先采用 jvm 工具指令,jstat来监控。因为监控的过程需要我手敲代码,比较耗时,所以我们在调用testGC()前,睡眠会 Thread.sleep(55000);
。启动代码后执行如下指令。
E:\itstack\git\github.com\interview>jps -l
10656
88464
38372 org.itstack.interview.ReferenceCountingGC
26552 sun.tools.jps.Jps
110056 org.jetbrains.jps.cmdline.Launcher
E:\itstack\git\github.com\interview>jstat -gc 38372 2000
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 0.0 65536.0 6561.4 175104.0 0.0 4480.0 770.9 384.0 75.9 0 0.000 0 0.000 0.000
10752.0 10752.0 0.0 1288.0 65536.0 0.0 175104.0 8.0 4864.0 3982.6 512.0 440.5 1 0.003 1 0.000 0.003
10752.0 10752.0 0.0 0.0 65536.0 437.3 175104.0 1125.5 4864.0 3982.6 512.0 440.5 1 0.003 1 0.012 0.015
10752.0 10752.0 0.0 0.0 65536.0 437.3 175104.0 1125.5 4864.0 3982.6 512.0 440.5 1 0.003 1 0.012 0.015
-
S0C、S1C,第一个和第二个幸存区大小 -
S0U、S1U,第一个和第二个幸存区使用大小 -
EC、EU,伊甸园的大小和使用 -
OC、OU,老年代的大小和使用 -
MC、MU,方法区的大小和使用 -
CCSC、CCSU,压缩类空间大小和使用 -
YGC、YGCT,年轻代垃圾回收次数和耗时 -
FGC、FGCT,老年代垃圾回收次数和耗时 -
GCT,垃圾回收总耗时
「注意」:观察后面三行,S1U = 1288.0
、GCT = 0.003
,说明已经在执行垃圾回收。
接下来,我们再换种方式测试。在启动的程序中,加入GC打印参数,观察GC变化结果。
-XX:+PrintGCDetails 打印每次gc的回收情况 程序运行结束后打印堆空间内存信息(包含内存溢出的情况)
-XX:+PrintHeapAtGC 打印每次gc前后的内存情况
-XX:+PrintGCTimeStamps 打印每次gc的间隔的时间戳 full gc为每次对新生代老年代以及整个空间做统一的回收 系统中应该尽量避免
-XX:+TraceClassLoading 打印类加载情况
-XX:+PrintClassHistogram 打印每个类的实例的内存占用情况
-Xloggc:/Users/xiaofuge/Desktop/logs/log.log 配合上面的使用将上面的日志打印到指定文件
-XX:HeapDumpOnOutOfMemoryError 发生内存溢出将堆信息转存起来 以便分析
这回就可以把睡眠去掉了,并添加参数 -XX:+PrintGCDetails
,如下:
「测试结果」
[GC (System.gc()) [PSYoungGen: 9346K->936K(76288K)] 9346K->944K(251392K), 0.0008518 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 936K->0K(76288K)] [ParOldGen: 8K->764K(175104K)] 944K->764K(251392K), [Metaspace: 3405K->3405K(1056768K)], 0.0040034 secs] [Times: user=0.08 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 76288K, used 1966K [0x000000076b500000, 0x0000000770a00000, 0x00000007c0000000)
eden space 65536K, 3% used [0x000000076b500000,0x000000076b6eb9e0,0x000000076f500000)
from space 10752K, 0% used [0x000000076f500000,0x000000076f500000,0x000000076ff80000)
to space 10752K, 0% used [0x000000076ff80000,0x000000076ff80000,0x0000000770a00000)
ParOldGen total 175104K, used 764K [0x00000006c1e00000, 0x00000006cc900000, 0x000000076b500000)
object space 175104K, 0% used [0x00000006c1e00000,0x00000006c1ebf100,0x00000006cc900000)
Metaspace used 3449K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 376K, capacity 388K, committed 512K, reserved 1048576K
-
从运行结果可以看出内存回收日志,Full GC 进行了回收。 -
也可以看出JVM并不是依赖引用计数器的方式,判断对象是否存活。 否则他们就不会被回收啦
「有了这个例子,我们再接着看看JVM垃圾回收的知识框架!」
四、JVM 垃圾回收知识框架
垃圾收集(Garbage Collection,简称GC),最早于1960年诞生于麻省理工学院的Lisp是第一门开始使用内存动态分配和垃圾收集技术的语言。
垃圾收集器主要做的三件事:哪些内存需要回收
、什么时候回收
、怎么回收。
而从垃圾收集器的诞生到现在有半个世纪的发展,现在的内存动态分配和内存回收技术已经非常成熟,一切看起来都进入了“自动化”。但在某些时候还是需要我们去监测在高并发的场景下,是否有内存溢出、泄漏、GC时间过程等问题。所以在了解和知晓垃圾收集的相关知识对于高级程序员的成长就非常重要。
垃圾收集器的核心知识项主要包括:判断对象是否存活、垃圾收集算法、各类垃圾收集器以及垃圾回收过程。如下图;
原图下载链接:http://book.bugstack.cn/#s/6jJp2icA
1. 判断对象已死
1.1 引用计数器
-
为每一个对象添加一个引用计数器,统计指向该对象的引用次数。 -
当一个对象有相应的引用更新操作时,则对目标对象的引用计数器进行增减。 -
一旦当某个对象的引用计数器为0时,则表示此对象已经死亡,可以被垃圾回收。
从实现来看,引用计数器法(Reference Counting)虽然占用了一些额外的内存空间来进行计数,但是它的实现方案简单,判断效率高,是一个不错的算法。
也有一些比较出名的引用案例,比如:微软COM(Component Object Model) 技术、使用ActionScript 3的FlashPlayer、 Python语言等。
「但是」,在主流的Java虚拟机中并没有选用引用技术算法来管理内存,主要是因为这个简单的计数方式在处理一些相互依赖、循环引用等就会非常复杂。可能会存在不再使用但又不能回收的内存,造成内存泄漏
1.2 可达性分析法
Java、C#等主流语言的内存管理子系统,都是通过可达性分析(Reachability Analysis)算法来判定对象是否存活的。
它的算法思路是通过定义一系列称为 GC Roots 根对象作为起始节点集,从这些节点出发,穷举该集合引用到的全部对象填充到该集合中(live set)。这个过程教过标记,只标记那些存活的对象 好,那么现在未被标记的对象就是可以被回收的对象了。
GC Roots 包括;
-
全局性引用,对方法区的静态对象、常量对象的引用 -
执行上下文,对 Java方法栈帧中的局部对象引用、对 JNI handles 对象引用 -
已启动且未停止的 Java 线程
「两大问题」
-
误报:已死亡对象被标记为存活,垃圾收集不到。多占用一会内存,影响较小。 -
漏报:引用的对象(正在使用的)没有被标记为存活,被垃圾回收了。那么直接导致的就是JVM奔溃。(STW可以确保可达性分析法的准确性,避免漏报)
2. 垃圾回收算法
2.1 标记-清除算法(mark-sweep)
-
标记无引用的死亡对象所占据的空闲内存,并记录到空闲列表中(free list)。 -
当需要创建新对象时,内存管理模块会从 free list 中寻找空闲内存,分配给新建的对象。 -
这种清理方式其实非常简单高效,但是也有一个问题内存碎片化太严重了。 -
「Java 虚拟机的堆中对象」,必须是连续分布的,所以极端的情况下可能即使总剩余内存充足,但寻找连续内存分配效率低,或者严重到无法分配内存。 重启汤姆猫! -
在CMS中有此类算法的使用,GC暂停时间短,但存在算法缺陷。
2.2 标记-复制算法(mark-copy)
-
从图上看这回做完垃圾清理后连续的内存空间就大了。 -
这种方式是把内存区域分成两份,分别用两个指针 from 和 to 维护,并且只使用 from 指针指向的内存区域分配内存。 -
当发生垃圾回收时,则把存活对象复制到 to 指针指向的内存区域,并交换 from 与 to 指针。 -
它的好处很明显,就是解决内存碎片化问题。但也带来了其他问题,堆空间浪费了一半。
2.3 标记-压缩算法(mark-compact)
-
1974年,Edward Lueders 提出了标记-压缩算法,标记的过程和标记清除算法一样,但在后续对象清理步骤中,先把存活对象都向内存空间一端移动,然后在清理掉其他内存空间。 -
这种算法能够解决内存碎片化问题,但压缩算法的性能开销也不小。
3. 垃圾回收器
3.1 新生代
-
Serial -
算法:标记-复制算法 -
说明:简单高效的单核机器,Client模式下默认新生代收集器; -
Parallel ParNew -
算法:标记-复制算法 -
说明:GC线程并行版本,在单CPU场景效果不突出。常用于Client模式下的JVM -
Parallel Scavenge -
算法:标记-复制算法 -
说明:目标在于达到可控吞吐量(吞吐量=用户代码运行时间/(用户代码运行时间+垃圾回收时间));
3.2 老年代
-
Serial Old -
算法:标记-压缩算法 -
说明:性能一般,单线程版本。1.5之前与Parallel Scavenge配合使用;作为CMS的后备预案。 -
Parallel Old -
算法:标记-压缩算法 -
说明:GC多线程并行,为了替代Serial Old与Parallel Scavenge配合使用。 -
CMS -
算法:标记-清除算法 -
说明:对CPU资源敏感、停顿时间长。标记-清除算法,会产生内存碎片,可以通过参数开启碎片的合并整理。 基本已被G1取代
3.3 G1
-
算法:标记-压缩算法 -
说明:适用于多核大内存机器、GC多线程并行执行,低停顿、高回收效率。
五、总结
-
JVM 的关于自动内存管理的知识众多,包括本文还没提到的 HotSpot 实现算法细节的相关知识,包括:安全节点、安全区域、卡表、写屏障等。每一项内容都值得深入学习。 -
如果不仅仅是为了面试背题,最好的方式是实践验证学习。否则这类知识就像3分以下的过电影一样,很难记住它的内容。 -
整个的内容也是小傅哥学习整理的一个过程,后续还会不断的继续深挖和分享。感兴趣的小伙伴可以一起讨论学习。
六、系列推荐
- END -
下方扫码关注 bugstack虫洞栈,与小傅哥一起学习成长、共同进步,做一个码场最贵Coder!
-
回复【设计模式】,下载《重学Java设计模式》,这是一本互联网真实案例的实践书籍,从实际业务中抽离出,交易、营销、秒杀、中间件、源码等众多场景进行学习代码设计。 -
回复【面经手册】,下载《面经手册 • 拿大厂Offer》,这是一本有深度的Java核心内容,从数据结构、算法、并发编程以及JVM系列不断深入讲解,让懂了就是真的懂。
java
工程师、架构师,开发过交易&营销、写过运营&活动、设计过中间件也倒腾过中继器、IO板卡。不只是写Java语言,也搞过C#、PHP,是一个技术活跃的折腾者。 CodeGuide
、 itstack-demo-design
,持续霸榜 Trending,成为全球热门项目。 本文分享自微信公众号 - bugstack虫洞栈(bugstack)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Erupt 1.6.1 发布,全注解式开发,通用后台管理框架,提供全栈注解级解决方案
Erupt 是一个低代码全栈类框架,它使用Java 注解动态生成页面以及增、删、改、查、权限控制等后台功能。 零前端代码、零 CURD、自动建表,仅需一个类文件+ 简洁的注解配置,快速开发企业级 Admin 管理后台。 提供企业级中后台管理系统的全栈解决方案,大幅压缩研发周期,专注核心业务。 本次更新内容 Features 支持路由复用(已打开页面多页签切换)功能支持,支持配置化启用关闭 增加登录密码错误次数触发验证码配置 已加密MD5用户禁止修改为非MD5加密 添加 erupt-generator 模块,用于生成 erupt 代码 添加 erupt-tpl 模块,用于在 erupt 中自定义页面、自定义弹出层,支持 Thymeleaf /FreeMarker/ 原生H5 / Velocity,可根据引入Jar自动加载模板引擎 BugFix 修复,excel 导出最多只能导出500条数据(#9) 修复,链接类型菜单,点击进入后,左侧菜单不会切换UI到已点击状态(#8) 修复,连接类型菜单如果连接存在参数会被截断的问题(#6) 修复一对多引用新增时bool与对象数据不能正常渲染的问题 特...
- 下一篇
让 Flutter 在鸿蒙系统上跑起来
前言 鸿蒙系统 (HarmonyOS)是华为推出的一款面向未来、面向全场景的分布式操作系统。在传统单设备系统能力的基础上,鸿蒙提出了基于同一套系统能力、适配多种终端形态的分布式理念。自 2020 年 9 月 HarmonyOS 2.0 发布以来,华为加快了鸿蒙系统大规模落地的步伐,预计 2021 年底,鸿蒙系统会覆盖包括手机、平板、智能穿戴、智慧屏、车机在内数亿台终端设备。对移动应用而言,新的系统理念、新的交互形式,也意味着新的机遇。如果能够利用好鸿蒙的开发生态及其特性能力,可以让应用覆盖更多的交互场景和设备类型,从而带来新的增长点。 与面临的机遇相比,适配鸿蒙系统带来的挑战同样巨大。当前手机端,尽管鸿蒙系统仍然支持安卓 APK 安装及运行,但长期来看,华为势必会抛弃 AOSP,逐步发展出自己的生态,这意味着现有安卓应用在鸿蒙设备上将会逐渐变成“二等公民”。然而,如果在 iOS 及 Android 之外再重新开发和维护一套鸿蒙应用,在如今业界越来越注重开发迭代效率的环境下,所带来的开发成本也是难以估量的。因此,通过打造一套合适的跨端框架,以相对低的成本移植应用到鸿蒙平台,并利用好该系统...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Windows10,CentOS7,CentOS8安装Nodejs环境