Java 进阶 08 —— JVM 垃圾回收器
文章目录
- 垃圾回收器概述
- 垃圾回收器的分类
- 评估 GC 的性能指标
- 吞吐量(throughput)
- 暂停时间(pause time)
- 吞吐量 vs 暂停时间
- 不同的垃圾回收器概述
- 垃圾收集器发展史
- 7 款经典的垃圾回收器
- 7 款经典的垃圾回收器与垃圾分代之间的关系
- 垃圾收集器的组合关系
- 如何查看默认的垃圾回收器
- 垃圾回收器介绍
- Serial 回收器:串行回收
- 参数配置
- ParNew 回收器:并行回收
- 参数配置
- Parallel 回收器:吞吐量优先
- 参数配置
- CMS 回收器:低延迟
- CMS 工作原理
- 分析
- 优点
- 缺点
- 参数配置
- 小结
- G1 回收器:区域化分代式
- 概述
- 优势
- 缺点
- 参数配置
- 常见操作步骤
- 适用场景
- 分区 Region:化整为零
- 垃圾回收过程
- Remembered Set
- 垃圾回收过程一:年轻代回收过程
- 垃圾回收过程二:老年代并发标记过程
- 垃圾回收过程三:混合回收过程
- 垃圾回收可选过程四:Full GC
- G1 补充
- G1 回收器的优化建议
- 垃圾回收器总结
- 怎么选择垃圾回收器
- 面试
- GC 日志分析
- GC 日志参数设置
- GC 日志查看工具
- GC 日志补充说明
- 垃圾回收器的新发展
- 垃圾回收器的发展过程
- Shenandoah GC
- 令人震惊、革命性的 ZGC
- 面向大堆的 AliGC
垃圾回收器概述
垃圾收集器没有在规范中进行过多的规定,可以由不同的厂商,不同版本的 JVM 来实现。
由于 JDK 的版本处于高速迭代过程中,因此 Java 发展至今已经衍生了众多的 GC 版本。
从不同角度分析垃圾收集器,可以将 GC 分为不同的类型。
Java 不同版本的新特性需要关注的点:
- 语法层面,Lambda表达式,switch 表达式,自动装箱、拆箱,enum,<>,…
- API 层面:Stream API,新的时间日期,Optional,String,集合框架
- 底层优化:JVM 的优化,元空间,静态域,字符串常量池,GC 的变化,多语言的支持
垃圾回收器的分类
-
按线程数分,可以分为串行垃圾回收器(Serial Collector)和并行垃圾回收器(Parallel Collector)。
-
串行回收指的是在同一时间段内只允许有一个 CPU 用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束。
-
在诸如单 CPU 处理器或者较小的应用内存等硬件平台不是特别优越的场合,串行回收器的性能表现可以超过并行回收器和并发回收器。所以串行回收器默认被应用在客户端的 Client 模式下的 JVM 中。
-
在并发能力比较强的 CPU 上,并行回收器产生的停顿时间要短于串行回收器。
-
-
和串行回收相反,并行收集可以运用多个 CPU 同时执行垃圾回收,因此提升了应用的吞吐量,不过并行回收仍然与串行回收一样,采用独占式,使用了 STW 机制。
-
按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器。
- 并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间。
- 独占式垃圾回收器一旦运行,就停止应用程序中的所有用于线程,直到垃圾回收过程完全结束。
-
按碎片处理方式分,可以分为压缩式垃圾回收器和非压缩式垃圾回收器。
- 压缩式垃圾回收器会在回收完成后,对存活对象进行压缩整理,消除回收后的碎片。(再分配对象空间使用指针碰撞)
- 非压缩式的垃圾回收器不进行这步操作。(再分配对象空间使用空闲列表)
-
按工作的内存区间分,又可分为年轻代垃圾回收器和老年代垃圾回收器。
评估 GC 的性能指标
- 吞吐量:运行用户代码的时间占总运行时间的比例
- 总运行时间:程序的运行时间 + 内存回收的时间
- 垃圾收集开销:吞吐量的补数,垃圾收集所用时间与总运行时间的比例。
- 暂停时间:执行垃圾收集时,程序的工作线程被暂停的时间。
- 收集频率:相对于应用程序的执行,收集操作发生的频率。
- 内存占用:Java 堆区所占的内存大小。
- 快速:一个对象从诞生到被回收所经历的时间。
吞吐量、暂停时间、内存占用,这三者共同构成一个不可能三角。三者总体的表现会随着技术进步而越来越好。一款优秀的收集器通常最多同时满足其中的两项。
这三项里,暂停时间的重要性日益凸显。因为随着硬件发展,内存占用多些越来越能容忍,硬件性能的提升有有助于降低收集器运行时对应用程序的影响,即提高了吞吐量。而内存的扩大,对延迟反而带来负面的效果。
简单来说,主要抓住两点:吞吐量和暂停时间。
吞吐量(throughput)
吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值,即吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)
- 比如:虚拟机总共运行了 100 分钟,其中垃圾收集花掉 1 分钟,那吞吐量就是 99%
这种情况下,应用程序能容忍较高的暂停时间,因此,高吞吐量的应用程序有更长的时间基准,快速响应是不必考虑的。
吞吐量优先,意味着在单位时间内,STW 的时间最短:0.2 + 0.2 = 0.4
暂停时间(pause time)
暂停时间是指一个时间段内应用程序线程暂停,让 GC 线程执行的状态
- 例如,GC 期间 100 毫秒的暂停时间意味着在这 100 毫秒期间内没有应用程序线程是活动的。
暂停时间优先,意味着尽可能让单次 STW 的时间最短:0.1 + 0.1 + 0.1 + 0.1 + 0.1 = 0.5
吞吐量 vs 暂停时间
高吞吐量较好因为这会让应用程序的最终用户感觉到只有应用程序线程在做”生产性“工作。直觉上,吞吐量越高程序运行越快。
低暂停时间(低延迟)较好因为从最终用户的角度来看不管是 GC 还是其他原因导致一个应用被挂起始终是不好的。这取决于应用程序的类型,有时候甚至短暂的 200 毫秒暂停都可能打断终端用户体验。因此具有低的较大暂停时间是非常重要的,特别是对于一个交互式应用程序。
不幸的是 ”高吞吐量“ 和 ”低暂停时间“ 是一对相互竞争的目标(矛盾)。
- 因为如果选择以吞吐量优先,那么必然需要降低内存回收的执行频率,但是这样会导致 GC 需要更长的暂停时间来执行内存回收。
- 相反的,如果选择以低延迟优先为原则,那么为了降低每次执行内存回收时的暂停时间,也只能频繁地执行内存回收,但这又引起了年轻代内存的缩减和导致程序吞吐量的下降。
在设计(或使用)GC 算法时,我们必须确定我们的目标:一个 GC 算法只可能针对两个目标之一(即只专注于较大吞吐量或最小暂停时间),或尝试找到一个二者的折中。
现在标准:在最大吞吐量优先的情况下,降低停顿时间。
不同的垃圾回收器概述
垃圾收集器发展史
有了虚拟机,就一定需要收集垃圾的机制,这就是 Grabage Collection,对应的产品我们称为 Garbage Collector。
- 1993 年随 JDK 1.3.1 一起来的是串行方式的 Serial GC,它是第一款 GC。ParNew 垃圾收集器是 Serial 收集器的多线程版本。
- 2002 年 2 月 26 日,Parallel GC 和 Concurrent Mark Sweep GC 跟随 JDK 1.4.2 一起发布。
- Parallel GC 在 JDK 6 之后成为 HotSpot 默认 GC。
- 2012 年,在 JDK 1.7u4 版本中,G1 可用。
- 2017 年,JDK 9 中 G1 变成默认的垃圾收集器,以替代 CMS。
- 2018 年 3 月,JDK 10 中 G1 垃圾回收器的并行完整垃圾回收,实现并行性来改善最坏情况下的延迟。
- 2018 年 9 月,JDK 11 发布。引入 Epsilon 垃圾回收器,又被称为 ”No-Op“(无操作)
- 2019 年 3 月,JDK 12 发布。增强 G1,自动返回未用堆内存给操作系统。同时,引入 Shenandoah GC,是一个低停顿时间的 GC(Experimental)。
- 2019 年 9 月,JDK 13 发布。增强 ZGC,自动返回未用堆内存给操作系统。
- 2020 年 3 月,JDK 14 发布。删除 CMS 垃圾回收器。拓展 ZGC 在 macOS 和 Windows 上的应用。
7 款经典的垃圾回收器
串行回收器:Serial、Serial Old
并行回收器:ParNew、Parallel Scavenge、Parallel Old
并发回收器:CMS、G1
7 款经典的垃圾回收器与垃圾分代之间的关系
新生代收集器:Serial、ParNew、Parallel Scavenge
老年代收集器:Serial Old、Parallel Old、CMS
整堆垃圾收集器:G1
垃圾收集器的组合关系
-
两个收集器间有连线,表明它们可以搭配使用:
Serial / Serial Old 、Serial / CMS 、ParNew / Serial Old 、 ParNew / CMS 、Parallel Scavenge / Serial Old 、Parallel Scavenge / Parallel Old 、G1
-
其中 Serial Old 作为 CMS 出现 ”Concurrent Mode Failure“ 失败的后备预案。
-
(红色虚线)由于维护和兼容性测试的版本,在 JDK 8 时将 Serial + CMS、ParNew + Serial Old 这两个组合声明为废弃(JEP 173),并在 JDK 9 中完全取消了这些组合的支持(JEP 214),即,移除了这些组合。
-
(绿色虚线)JDK 14 中:弃用 Parallel Scavenge 和 Serial Old 组合(JEP 366)
-
(青色虚线)JDK 14中:删除 CMS 垃圾回收器(JEP 363)
如何查看默认的垃圾回收器
-XX:+PrintCommandLineFlags
查看命令行相关参数(包含使用的垃圾收集器)
java -XX:+PrintCommandLineFlags -version
使用命令行指令: jinfo -flag 相关垃圾回收器参数 进程 ID
$ jinfo -flag UseParallelGC 58951
-XX:-UseParallelGC
$ jinfo -flag UseParallelOldGC 58951
-XX:-UseParallelOldGC
$ jinfo -flag UseG1GC 58951
-XX:-UseG1GC
$ jinfo -flag UseConcMarkSweepGC 58951
-XX:+UseConcMarkSweepGC
垃圾回收器介绍
Serial 回收器:串行回收
Serial 收集器是最基本、历史最悠久的垃圾收集器了。JDK 1.3 之前回收新生代唯一的选择。
Serial 收集器作为 HotSpot 中 Client 模式下的默认新生垃圾收集器。
Serial 收集器采用复制算法、串行回收和 STW 机制的方式执行内存回收。
除了年轻代之外,Serial 收集器还提供用于执行老年代垃圾收集的 Serial Old 收集器。Serial Old 收集器同样也采用了串行回收和 STW 机制,只不过内存回收算法使用的是标记-压缩算法。
- Serial Old 是运行在 Client 模式下默认的老年代的垃圾回收器。
- Serial Old 在 Server 模式下主要有两个用途:①与新生代的 Parallel Scavenge 配合使用 ②作为老年代 CMS 收集器的后备垃圾收集方案。
这个收集器是一个单线程的收集器,但它的 ”单线程“ 的意义并不仅仅说明它只会使用一个 CPU 或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。
优势:简单而高效(与其他收集器的单线程比),对于限定单个 CPU 的环境来说,Serial 收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率。
- 运行在 Client 模式下的虚拟机是个不错的选择。
在用户的桌面应用场景中,可用内存一般不大(几十 MB 至一两百 MB),可以在较短时间内完成垃圾回收(几十 ms 至一百多 ms),只要不频繁发生,使用串行回收器是可以接受的。
参数配置
在 HotSpot 虚拟机中,使用 -XX:UseSerialGC
参数可以指定年轻代和老年代都是用串行收集器。
- 等价于新生代使用 Serial GC,且老年代使用 Serial Old GC。
总结:这种垃圾收集器大家了解,现在已经不用串行的了。而且在限定单核 CPU 才可以用。现在都不是单核的了。
对于交互较强的应用而言,这种垃圾收集器是不能接受的。一般在 Java Web 应用程序中是不会采用串行垃圾收集器的。
ParNew 回收器:并行回收
如果说 Serial GC 是年轻代中的单线程垃圾收集器,那么 ParNew 收集器则是 Serial 收集器的多线程版本。
- Par 是 Parallel 的缩写,New:只能处理的是新生代
ParNew 收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别。ParNew 收集器在年轻代中同样也是采用复制算法、STW 机制。
ParNew 是很多 JVM 运行在 Server 模式下新生代的默认垃圾收集器。
- 对于新生代,回收次数频繁,使用并行方式高效。
- 对于老年代,回收次数少,使用串行方式节省资源。(CPU并行需要切换线程,串行可以省去切换线程的资源)
由于 ParNew 收集器是基于并行回收,那么是否可以断定 ParNew 收集器的回收效率在任何场景下都会比 Serial 收集器更高效?
- ParNew 收集器运行在多 CPU 环境下,由于可以充分利用多 CPU、多核心等物理硬件资源优势,可以更快速地完成垃圾收集,提升程序的吞吐量。
- 但是在单个 CPU 的环境下,ParNew 收集器不比 Serial 收集器更高效。虽然 Serial 收集器是基于串行回收,但是由于 CPU 不需要频繁地做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开销。
除 Serial 外,目前只有 ParNew GC 能与 CMS 收集器配合工作。
参数配置
在程序中,开发人员可以通过选项 -XX:+UseParNewGC
手动指定使用 ParNew 收集器执行内存回收任务。它表示年轻代使用并行收集器,不影响老年代。
-XX:ParallelGCThreads
限制线程数量,默认开启和 CPU 数相同的线程数。
Parallel 回收器:吞吐量优先
HotSpot 的年轻代中除了拥有 ParNew 收集器是基于并行回收以外,Parallel Scavenge 收集器同样也采用了复制算法、并行回收和 STW 机制。
那么 Parallel 收集器的出现是否多此一举?
- 和 ParNew 收集器不同,Parallel Scavenge 收集器的目标是达到一个可控的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器。
- 自适应调节策略也是 Parallel Scavenge 与 ParNew 的一个重要区别。
高吞吐量则可以高效地利用 CPU 时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中使用。例如,那些执行批量处理、订单处理、工资支付、科学计算的应用程序。
Parallel 收集器在 JDK 1.6 时提供了用于执行老年代垃圾收集的 Parallel Old 收集器,用来代替老年代的 Serial Old 收集器。
Parallel Old 收集器采用了标记-压缩算法,但同样也是基于并行回收和 STW 机制。
在吞吐量优先的应用场景中,Parallel 收集器和 Parallel Old 收集器的组合,在 Server 模式下的内存回收性能很不错。
在 Java 8 中,默认也是此垃圾收集器。
参数配置
-XX:+UserParallelGC
手动指定年轻代使用 Parallel 并行收集器执行内存回收任务。-XX:+UseParallelOld
手动指定老年代都是使用并行回收收集器。- 上面两个参数,分别适用于新生代和老年代。默认 JDK 8 是开启的。
- 上面两个参数,默认开启一个,另一个也会被开启。(互相激活)
-XX:ParallelGCTheads
设置年轻代并行收集器的线程数。一般地,最好与 CPU 数量相等,以避免过多的线程数影响垃圾收集性能。- 在默认情况下,当 CPU 数量小于 8 个,ParallelGCThreads 的值等于 CPU 数量。
- 当 CPU 数量大于 8 个,ParallelGCThreads 的值等于
3 + ((5 * CPU_COUNT) / 8 )
。
-XX:MaxGCPauseMillis
设置垃圾收集器最大停顿时间(即 STW 的时间)。单位是毫秒。- 为了尽可能地把停顿时间控制在 MaxGCPauseMillis 以内,收集器在工作时会调整 Java 堆大小或者其他一些参数。
- 对于用户来讲,停顿时间越短体验越好。但是在服务端,我们注重高并发,整体的吞吐量。所以服务器端适合 Parallel,进行控制
- 该参数使用需要谨慎。
-XX:GCTimeRatio
垃圾收集时间占总时间的比例(= 1 / (N + 1))。用于衡量吞吐量的大小。- 取值范围(0, 100)。默认值 99,也就是垃圾回收时间不超过 1%。
- 与前一个
-XX:MaxGCPauseMillis
参数有一定的矛盾性。暂停时间越长,Radio 参数就容易超过设定的比例。
-XX:+UseAdaptiveSizePolicy
设置 Parallel Scavenge 收集器具有自适应调节策略。- 在这种模式下,年轻代的大小,Eden 和 Survivor 的比例、晋升老年代的对象年龄等参数会被自动调整,以达到在堆大小、吞吐量和停顿时间之间的平衡点。
- 在手动调优比较困难的场合,可以直接使用这种自适应的方式,仅指定虚拟机的最大堆、目标的吞吐量(GCTimeRatio)和停顿时间(MaxGCPauseMillis),让虚拟机自己完成调度工作。
CMS 回收器:低延迟
在 JDK 1.5 时期,HotSpot 推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS(Concurrent-Mark-Sweep)收集器,这款收集器是 HotSpot 虚拟中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。
CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验。
- 目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。
CMS 的垃圾收集算法采用 标记-清除 算法,并且也会 STW。
不幸的是,CMS 作为老年代的收集器,却无法与 JDK 1.4.0 中已经存在的新生代收集器 Parallel Scavenge 收集器配合工作,所以在 JDK 1.5 中使用 CMS 来收集老年代的时候,新生代只能选择 ParNew 或者 Serial 收集器中的一个。
在 G1 出现之前,CMS 使用还是非常广泛的,一直到今天,任然有很多系统使用 CMS GC。
CMS 工作原理
CMS 整个过程比之前的收集器要复杂,整个过程分为 4 个主要阶段,即初始标记阶段、并发标记阶段、重新标记阶段、并发清除阶段。
- 初始标记(Initial-Mark)阶段:在这个阶段中,程序用所有的工作线程都将会因为 STW 机制而出现短暂的暂停,这个阶段的主要任务仅仅是标记出 GC Roots 能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小,所以这里的速度非常快。
- 并发标记(Concurrent-Mark)阶段:从 GC Roots 的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行。
- 重新标记(Remark)阶段:由于在并发标记阶段中,程序的工作线程会和垃圾收集线程同时运行或交叉运行,因此为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短。
- 并发清除(Concurrent-Sweep)阶段:此阶段清理删除掉标记阶段的已经死亡的对象,释放内存空间。由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的。
分析
尽管 CMS 收集器采用的是并发回收(非独占式),但是在其初始化标记和再次标记这两个阶段中仍然需要执行 STW 机制暂停程序中的工作线程,不过暂停时间并不会太长,因此可以说明目前所有的垃圾收集器都做不到完全不需要 STW,只是尽可能的缩短暂停时间。
由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作,所以整体的回收是低延迟的。
另外,由于在垃圾收集阶段用户线程没有中断,所以在 CMS 回收过程中,还应该确保应用程序用户线程有足够的内存可用。因此,CMS 收集器不能像其他收集器那样等到老年代几乎完全被填满了在进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在 CMS 工作过程中依然有足够的内存空间支持应用程序运行。要是 CMS 运行期间预留的内存无法满足程序需要,就会出现一次 ”Concurrent Mode Failure“ 失败,这时虚拟机将启动后备预案:临时启用 Serial Old 收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。
CMS 收集器的垃圾收集算法采用的是 标记-清除 算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块,不可避免地将会产生一些内存碎片。那么 CMS 在为新对象分配内存空间时,将无法使用指针碰撞(Bump the Pointer)技术,而只能选择空闲列表(Free List)执行内存分配。
有人会觉得既然 Mark Sweep 会造成内存碎片,那么为什么不把算法换成 Mark Compact 呢?
答案其实很简单,因为当并发清除的时候,用 Compact 整理内存的话,原来的用户线程使用的内存还怎么用?要保证用户线程能继续执行,前提得是它运行的资源不受影响。Mark Compact 更适合 STW 这种场景下使用。
优点
- 并发收集
- 低延迟
缺点
- 会产生内存碎片,导致并发清除后,用户线程可用的空间不足。在无法分配大对象的情况下,不得不提前触发 Full GC。
- 对 CPU 资源非常敏感,在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量会降低。
- 无法处理浮动垃圾,可能会出现 ”Concurrent Mode Failure“ 失败而导致另一次 Full GC 的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的,那么在并发标记阶段如果产生新的垃圾对象,CMS 将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行 GC 时释放这些之前未被回收的内存空间。
参数配置
-XX:+UseConcMarkSweepGC
手动指定使用 CMS 收集器执行内存回收任务。- 开启该参数后会自动将
-XX:+UseParNewGC
打开。即:年轻代使用 ParNew 收集器 + 老年代使用 CMS 收集器 + 老年代的备用收集器 Serial Old 收集器
- 开启该参数后会自动将
-XX:CMSInitiatingOccupanyFraction
设置堆内存使用率的阈值,一旦到达该阈值,便开始进行回收。- JDK 5 及以前版本的默认值为 68,即当老年代的空间使用率达到 68% 时,会执行一次 CMS 回收。JDK 6 及以上的版本默认值为 92%。
- 如果内存增长缓慢,则可以设置一个稍大的值,大的阈值可以有效降低 CMS 的触发频率,减少老年代回收的次数可以较为明显地改善应用程序性能。反之,如果应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低 Full GC 的执行次数。
-XX:+UseCMSCompactAtFullCollection
用于指定在执行完 Full GC 后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了。-XX:CMSFullGCsBeforeCompaction
设置在执行多少次 Full GC 后对内存空间进行压缩整理。-XX:ParallelCMSThreads
设置 CMS 的线程数量。- CMS 默认启动的线程数是 (ParallelCMSThreads + 3) / 4
- ParallelCMSThreads 是年轻代并行收集器(ParNew)的线程数。当 CPU 资源比较紧张时,受到 CMS 收集器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕。
小结
HotSpot 有这么多的垃圾回收器,那么如果有人问,Serial GC、Parallel GC、CMS GC 这三个 GC 有什么不同呢?
- 如果你想要最小化地使用内存和并行开销,请选择 Serial GC
- 如果你想要最大化应用程序的吞吐量,请选择 Parallel GC
- 如果你想要最小化 GC 的中断或停顿时间,请选择 CMS GC
JDK 9 新特性:CMS 被标记为 Deprecate 了(JEP291)
- 如果对 JDK 9 及以上版本的 HotSpot 虚拟机使用参数
-XX:+UseConcMarkSweepGC
来开启 CMS 收集器的话,用户会收到一个警告信息,提示 CMS 为了将会被去除。
JDK 14 新特性:去除 CMS 垃圾收集器(JEP363)
- 移除了 CMS 垃圾收集器,如果在 JDK 14 中使用
-XX:+UseConcMarkSweepGC
的话,JVM 不会报错,只是给出警告,但是不会退出。JVM 会自动使用默认的 GC。
G1 回收器:区域化分代式
1.既然我们已经有了前面几个强大的 GC,为什么还要发布 Garbage First(G1)GC?
原因就在于对于应用程序所应用的业务越来越庞大、复杂,用户越来越多,没有 GC 就不能保证应用程序正常进行,而经常造成 STW 的 GC 又跟不上实际的需求,所以才会不断地尝试对 GC 进行优化。G1(Garbage First)垃圾回收器是在 Java 7 Update 4 之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一。
与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。
官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量,所以才担当起”全功能收集器“的重任与期望。
2.为什么名字叫做 Garbage First(G1)呢?
因为 G1 是一个并行回收器,它把堆内存分割成很多不相关的区域(Region)(物理上不连续的)。使用不同的 Region 来表示 Eden、Survivor0、Survivor1、老年代等。
G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region。
由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给 G1 一个名字:垃圾优先(Garbage First)。
概述
G1(Garbage First)是一款面向服务端应用的垃圾收集器,主要针对配备多核 CPU 及大容量内存的机器,以极高概率满足 GC 停顿时间的同时,还兼具高吞吐量的性能特征。
在 JDK 1.7 版本正式启用,移除了 Experimental 的标识,是 JDK 9 以后的默认垃圾回收器,取代了 CMS 回收器以及 Parallel + Parallel Old 组合。被 Oracle 官方称为 ”全功能的垃圾收集器“。
与此同时,CMS 已经在 JDK 9 中被标记为废弃(Deprecated)。在 JDK 8 中还不是默认的垃圾回收器,需要使用 -XX:+UseG1GC
来使用。
优势
与其他的 GC 收集相比,G1 使用了全新的分区算法,其特定如下所示:
- 并行与并发
- 并行性:G1 在回收期间,可以有多个 GC 线程同时工作,有效利用多核计算能力。此时用户线程 STW
- 并发性:G1 拥有与应用程序交替执行的能力,部分工作可以和应用程序同时执行,因此,一般来说,不会在整个回收阶段发生完全阻塞应用程序的情况。
- 分代收集
- 从分代上看,G1 依然属于分代型垃圾回收器,它会区分年轻代和老生代,年轻代依然有 Eden 区和 Survivor 区。但从堆的结构上看,它不要求整个 Eden 区、年轻代或者老年代都是连续的,也不再坚持固定大小和固定数量。
- 将堆空间分为若干个区域(Region),这些区域中包含了逻辑上的年轻代和老年代。
- 和之前的各类回收器不同,它同时兼顾年轻代和老年代。对比其他回收器,或者工作在年轻代,或者工作在老年代。
- 空间整合
- CMS:”标记-清除“ 算法、内存碎片、若干次 GC 后进行一次碎片整理
- G1 将内存划分成为一个个的 Region。内存的回收是以 Region 作为基本单位的。Region 之间是复制算法,但整体上实际可看做是标记-压缩(Mark-Compact)算法,两种算法都可以避免内存碎片。这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC。尤其是当 Java 堆非常大的时候,G1 的优势更加明显。
- 可预测的停顿时间模型(即软实时 soft real-time)
- 这是 G1 相对于 CMS 的另一大优势,G1 除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为 M 毫秒的时间片段内,消耗在垃圾收集上的时间不得超过 N 毫秒。
- 由于分区的原因,G1 可以只选择部分区域进行内存回收,这样缩小了回收的范围,因此对于全局停顿情况的发生也能得到较好的控制。
- G1 跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的 Region。保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。
- 相比于 CMS GC,G1 未必能做到 CMS 在最好情况下的延迟停顿,但是最差情况要好很多。
- 这是 G1 相对于 CMS 的另一大优势,G1 除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为 M 毫秒的时间片段内,消耗在垃圾收集上的时间不得超过 N 毫秒。
缺点
相较于 CMS,G1 还不具备全方位、压倒性优势。比如在用户程序运行过程中,G1 无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(Overload)都要比 CMS 要高。
从经验上说,在小内存应用上 CMS 的表现大概率会优于 G1,而 G1 在大内存应用上则发挥其优势。平衡点在 6-8 GB 之间。
参数配置
-XX:+UseG1GC
手动指定使用 G1 收集器执行内存回收任务。JDK 9 及以后默认开启。-XX:G1HeapRegionSize
设置每个 Region 的大小。值是 2 的幂,范围是 1 MB 到 32 MB 之间,目标是根据最小的 Java 堆大小划分出约 2048 个区域。默认是堆内存的 1/2000。-XX:MaxGCPauseMillis
设置期望达到的最大 GC 停顿时间指标(JJVM 会尽力实现,但不保证达到)。默认值是 200 ms。-XX:ParallelGCThread
设置 STW 工作线程数的值。最多设置为 8。-XX:ConcGCThreads
设置并发标记的线程数。将 n 设置为并行垃圾回收线程数(ParallelGCThreads)的 1/4 左右。-XX:InitiatingHeapOccupanyPercent
设置触发并发 GC 周期的 Java 堆占用率阈值。超过此值,就触发 GC。默认值是 45。
常见操作步骤
G1 的设计原则就是简化 JVM 性能调优,开发人员只需要简单的三步即可完成调优:
- 第一步,开启 G1 垃圾收集器
- 第二步:设置堆的最大内存
- 第三步:设置最大的停顿时间
G1 中提供了三种垃圾回收模式:Young GC、Mixed GC 和 Full GC,在不同的条件下被触发。
适用场景
- 面向服务端应用,针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)
- 最主要的应用是需要低 GC 延迟,并具有大堆的应用程序提供解决方案
- 如:在堆大小约 6GB 或更大时,可预测的暂停时间可以低于 0.5 秒;G1 通过每次只清理一部分而不是全部的 Region 的增量式清理来保证每次 GC 停顿时间不会太长。
- 用来替换掉 CMS 收集器,在下面的情况时,使用 G1 可能比 CMS 好:
- 超过 50% 的 Java 堆被活动数据占用
- 对象分配频率或年代提升频率变化很大
- GC 停顿时间过长(长于 0.5 至 1 秒)
- HotSpot 垃圾收集器里,除了 G1 以外,其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作,而 G1 GC 可以采用应用线程承担后台运行的 GC 工作,即当 JVM 的 GC 线程处理速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程。(啥意思?)
分区 Region:化整为零
使用 G1 收集器时,它将整个 Java 堆划分成约 2048 个大小相同的独立 Region 块,每个 Region 块大小根据堆空间的实际大小而定,整体被控制在 1MB 到 32 MB 之间,且为 2 的 N 次幂,即 1 MB,2 MB,4 MB,8 MB,16 MB,32 MB。可以通过 -XX:G1HeapRegionSize
设定。所有的 Region 大小相同,且在 JVM 生命周期内不会被改变。
虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了,它们都是一部分 Region(不需要连续)的集合。通过 Region 的动态分配方式实现逻辑上的连续。
一个 Region 有可能属于 Eden、Survivor 或者 Old/Tenured 内存区域。但是一个 Region 只可能属于一个角色。图中的 E 表示该 Region 属于 Eden 内存区域,S 表示属于 Survivor 内存区域,O 表示属于 Old 内存区域。图中空白的表示未使用的内存空间。
G1 垃圾收集器还增加了一种新的内存区域,叫做 Humongous 内存区域,如图中的 H 块。主要用于存储大对象,如果超过一个 Region 的50%,就放到 H。(这里老师讲解有误,在《JVM G1源码分析和调优》书中写到:对于大对象分为两类,一类是大于HeapRegionSize的一半,但是小于HeapRegionSize,即一个完整的堆分区可以保存,则直接从空闲列表直接拿一个堆分区,或者分配一个新的堆分区。如果是连续对象,则需要多个堆分区,思路同上,但是处理的时候需要加锁。)
设置 H 的原因:
对于堆中的大对象,默认直接会分配到老年代,但是如果它是一个短期存在的大对象,就会对垃圾收集器造成负面影响。为了解决这个问题,G1 划分了一个 Humongous 区,它用来专门存放大对象。**如果一个 H 区装不下一个大对象,那么 G1 会寻找连续的 H 区来存储。**为了能找到连续的 H 区,有时候不得不启用 Full GC。G1 的大多数行为都把 H 区作为老年代的一部分来看待。
垃圾回收过程
G1 GC 的垃圾回收过程主要包括如下三个环节:
- 年轻代 GC(Young GC)
- 老年代并发标记过程(Concurrent Marking)
- 混合回收(Mixed GC)
- (如果需要,单线程、独占式、高强度的 Full GC 还是继续存在的。它针对 GC 的评估失败提供了一种失败保护机制,即强力回收。)
Young GC → Young GC + Concurrent Marking → Mixed GC → Full GC
应用程序分配内存,当年轻代的 Eden 区用尽时开始年轻代回收过程;G1 年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期,G1 GC 暂停所有应用程序线程,启动所线程执行年轻代回收。然后从年轻代区间移动存活对象到 Survivor 区间或者老年代区间,也有可能是两个区间都会涉及。
当堆内存使用达到一定值(默认 45%)时,开始老年代并发标记过程。
标记完成马上开始混合回收过程。对于一个混合回收期,G1 GC 从老年区间移动存活对象到空闲区间,这些空闲区间也就成为了老年代的一部分。和年轻代不同,老年代的 G1 回收器和其他 GC 不同**,G1 的老年代回收器不需要整个老年代被回收,一次只需要扫描/回收一小部分老年代的 Region 就可以了**。同时,这个老年代 Region 是和年轻代一起被回收的。
举个例子:一个 Web 服务器,Java 进程最大堆内存为 4 G,每分钟响应 1500 个请求,每 45 秒钟会新分配大约 2 G 内存。G1 会每 45 秒钟进行一次年轻代回收,每 31 个小时整个堆的使用率会达到 45 %,会开始老年代并发标记过程,标记完成后开始四到五次的混合回收。
Remembered Set
- 一个对象被不同区域引用的问题
- 一个 Region 不可能是孤立的,一个 Region 中的对象可能被其他任意 Region 中的对象引用,判断对象存活时,是否需要扫描整个 Java 堆才能保证准确?
- 在其他的分代收集器,也存在这样的问题(而 G1 更突出)
- 回收新生代也不得不同时扫描老年代?
- 这样的话会降低 Minor GC 的效率
解决方法:
- 无论 G1 还是其他分代收集器,JVM 都是使用 Remembered Set 来避免全局扫描;
- 每个 Region 都有一个对应的 Remembered Set;
- 每次 Reference 类型数据写操作时,都会产生一个写屏障(Write Barrier)暂时中断操作;
- 然后检查将要写入的引用指向的对象是否和该 Reference 类型数据在不同的 Region(其他收集器:检查老年代对象是否引用了新生代对象);
- 如果不同,通过 CardTable(Remembered Set 的实现) 把相关引用信息记录到引用指向对象所在 Region 对应的 Remembered Set 中;
- 当进行垃圾收集时,在 GC Roots 的枚举范围加入 Remembered Set,就可以保证不进行全局扫描,也不会有遗漏。
垃圾回收过程一:年轻代回收过程
JVM 启动时,G1 先准备好 Eden 区,程序在运行过程中不断创建对象到 Eden 区,当 Eden 空间耗尽时,G1 会启动一次年轻代垃圾回收过程。
年轻代垃圾回收只会收集 Eden 区和 Survivor 区。
YGC 时,首先 G1 停止应用程序的执行(STW),G1 创建回收集(Collection Set),回收集是指需要被回收的内存分段的集合,年轻代回收过程的回收集包含年轻代 Eden 区和 Survivor 区所有的内存分段。
然后开始如下回收过程:
-
第一阶段,扫描根。
根是指 static 变量指向的对象,正在执行的方法调用链上的局部变量等。根引用连同 RSet 记录的外部引用作为扫描存活对象的入口。
-
第二阶段,更新 RSet。
处理 Dirty Card Queue 中的 card,更新 RSet。此阶段完成后,RSet 可以准确的反映老年代对所在的内存分段中对象的引用。
-
第三阶段:处理 RSet。
识别被老年代对象所指向的 Eden 中的对象,这些被指向的 Eden 中的对象被认为是存活的对象。
-
第四阶段:复制对象。
此阶段,对象树被遍历,Eden 区内存段中存活的对象会被复制到 Survivor 区中空的内存分段,Survivor 区内存段中存活的对象如果年龄未达到阈值,年龄会加 1,达到阈值会被复制到 Old 区中的内存分段,如果 Survivor 空间不够,Eden 空间的部分数据会直接晋升到老年代空间。
-
第五阶段:处理引用。
处理 Soft、Weak、Phantom、Final、JNI Weak 等引用(这里可能描述不准确)。最终 Eden 空间的数据为空,GC 停止工作,而目标内存中的对象都是连续存储的,没有碎片,所以复制过程可以达到内存整理的效果,减少碎片。
注:对于应用程序的引用赋值语句 object.fieled = object,JVM 会在之前和之后执行特殊的操作以在 Dirty Card Queue 中入队一个保存了对象引用信息的 card,在年轻代回收的时候,G1 会对 Dirty Card Queue 中所有的 card 进行处理,以更新 RSet,保证 RSet 实时准确的反映引用关系。
那为什么不在引用赋值语句处直接更新 RSet 呢?这是为了性能的需要,RSet 的处理需要线程同步,开销会很大,使用队列性能会好很多。
垃圾回收过程二:老年代并发标记过程
- 1.初始标记过程(STW):标记从根节点直接可达的对象。这个阶段是 STW 的,并且会触发一次年轻代 GC。
- 2.根区域扫描(Root Region Scanning):G1 GC 扫描 Survivor 区直接可达的老年代区域对象,并标记被引用的对象。这一过程必须在 Young GC 之前完成。
- 3.并发标记(Concurrent Marking):在整个堆中进行并发标记(和应用程序并发执行),此过程可能被 Young GC 中断。在并发标记阶段,若发现区域对象中所有的对象都是垃圾,那这个区域会被立即回收(实时回收)。同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例)。
- 4.再次标记(Remark,STW):由于应用程序持续进行,需要修正上一次的标记结果。是 STW 的。G1 中采用了比 CMS 更快的初始快照算法:snapshot-at-the-beginning(SATB)。
- 5.独占清理(cleanup,STW):计算各个区域的存活对象和 GC 回收比例,并进行排序,识别可以混合回收的区域。为下阶段做铺垫。是 STW 的。
- 6.并发清理阶段:识别并清理完全空闲的区域
垃圾回收过程三:混合回收过程
当越来越多的对象晋升到老年代 Old Region 时,为了避免堆内存被耗尽,虚拟机会触发一个混合的垃圾收集器,即 Mixed GC,该算法并不是一个 Old GC,除了回收整个 Young Region,还会回收一部分的 Old Region。这里需要注意:是一部分老年代,而不是全部老年代。可以选择哪些 Old Region 进行收集,从而可以对垃圾回收的耗时时间进行控制。也要注意的是 Mixed GC 并不是 Full GC。
- 并发标记结束以后,老年代中百分百为垃圾的内存分段被回收了,部分为垃圾的内存分段被计算了出来。默认情况下,这些老年代的内存分段会分8次(可以通过
-XX:G1MixedGCCountTarget
设置)被回收。 - 混合回收的回收集(Collection Set)包括八分之一的老年代内存分段,Eden 区内存分段,Survivor 区内存分段。混合回收的算法和年轻代回收的算法完全一样,只是回收集多了老年代的内存分段。具体过程请参考上面的年轻代回收过程。
- 由于老年代中的内存分段默认分8次回收,G1 会优先回收垃圾多的内存分段。**垃圾占内存分段比例越高的,越会被先回收。**并且有一个阈值会决定内存分段是否被回收。
-XX:G1MixedGCLiveThresholdPercent
,默认为 65%,意思是垃圾占内存分段比例要达到 65% 才会被回收。如果垃圾占比太低,意味着存活的对象占比高,在复制的时候会花费更多的时间。 - 混合回收并不一定要进行 8 次。有一个阈值
-XX:G1HeapWastePercent
,默认值为 10%,意思是允许整个堆内存中有 10% 的空间被浪费,意味着如果发现可以回收的垃圾占堆内存的比例低于 10%,则不再进行混合回收。因为 GC 会花费很多的时间但是回收到的内存却很少。
垃圾回收可选过程四:Full GC
G1的初衷就是要避免 Full GC 的出现。但是如果上述方式不能正常工作,G1 会停止应用程序的执行(Stop-The-World),使用单线程的内存回收算法进行垃圾回收,性能会非常差,应用程序停顿时间会很长。
要避免 Full GC 的发生,一旦发生 Full GC,需要对JVM参数进行调整。什么时候会发生 Full GC 呢?比如堆内存太小,当 G1 在复制存活对象的时候没有空的内存分段可用,则会回退到 Full GC,这种情况可以通过增大内存解决。
导致 G1 Full GC 的原因可能有两个:
- Evacuation 的时候没有足够的 To Space 来存放晋升的对象;
- 并发处理过程完成之前空间耗尽。
G1 补充
从 Oracle 官方透露出来的信息可获知,回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行,但这件事情做起来比较复杂,考虑到 G1 只是回一部分 Region,停顿时间是用户可控制的,所以并不迫切去实现,**而选择把这个特性放到了 G1 之后出现的低延迟垃圾收集器(即 ZGC)中。**另外,还考虑到 G1 不是仅仅面向低延迟,停顿用户线程能够最大幅度提高垃圾收集效率,为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。
G1 回收器的优化建议
- 年轻代大小
- 避免使用 -Xmn 或 -XX:NewRatio 等相关选项显式设置年轻代大小,因为固定年轻代的大小会覆盖可预测的暂停时间目标。我们让 G1 自己去调整
- 暂停时间目标不要太过严苛
- G1 GC 的吞吐量目标是 90% 的应用程序时间和 10% 的垃圾回收时间
- 评估 G1 GC 的吞吐量时,暂停时间目标不要太严苛。目标太过严苛表示你愿意承受更多的垃圾回收开销,而这些会直接影响到吞吐量。
垃圾回收器总结
截止 JDK 1.8,一共有 7 款不同的垃圾收集器。每一款的垃圾收集器都有不同的特点,在具体使用的时候,需要根据具体的情况选用不同的垃圾收集器。
垃圾收集器 | 分类 | 作用位置 | 使用算法 | 特点 | 适用场景 |
---|---|---|---|---|---|
Serial | 串行运行 | 新生代 | 复制算法 | 响应速度优先 | 适用于单 CPU 环境下的 Client 模式 |
ParNew | 并行运行 | 新生代 | 复制算法 | 响应速度优先 | 多 CPU 环境 Server 模式下与 CMS 配合使用 |
Parallel | 并行运行 | 新生代 | 复制算法 | 吞吐量优先 | 适用于后台运算而不需要太多交互的场景 |
Serial Old | 串行运行 | 老年代 | 标记-压缩算法 | 响应速度优先 | 适用于单 CPU 环境下的 Client 模式 |
Parallel Old | 并行运行 | 老年代 | 标记-压缩算法 | 吞吐量优先 | 适用于后台运算而不需要太多交互的场景 |
CMS | 并发运行 | 老年代 | 标记-清除算法 | 响应速度优先 | 适用于互联网或 B/S 业务 |
G1 | 并发、并行运行 | 新生代、老年代 | 标记-压缩算法、复制算法 | 响应速度优先 | 面向服务端应用 |
GC 发展阶段
Serial → Parallel → CMS → G1 → ZGC
怎么选择垃圾回收器
Java 垃圾收集器的配置对于 JVM 优化来说是一个很重要的选择,选择合适的垃圾收集器可以让 JVM 的性能有一个很大的提升。怎么选择垃圾收集器?
- 优先调整堆的大小让 JVM 自适应完成。
- 如果内存小于 100M,使用串行收集器
- 如果是单核、单机程序,并且没有停顿时间的要求,串行收集器
- 如果是多 CPU、需要高吞吐量、允许停顿时间超过 1 秒,选择并行或者 JVM 自己选择
- 如果是多 CPU、追求低停顿时间,需快速响应(比如延迟不能超过 1 秒,如互联网应用),使用并发收集器
- 官方推荐 G1,性能高。现在互联网的项目,基本都是使用 G1。
最后需要明确一个观点:
- 没有最好的收集器,更没有万能的收集算法
- 调优永远是针对特定场景、特定需求,不存在一劳永逸的收集器
面试
- 对于垃圾收集,面试官可以循序渐进从理论、实践各种角度深入,也未必是要求面试者什么都懂。但如果你懂得原理,一定会成为面试中的加分项。这里较通用、基础性的部分如下:
- 垃圾收集的算法有哪些?如何判断一个对象是否可以回收?
- 垃圾收集器工作的基本流程。
- 另外,大家需要多关注垃圾回收器这一章的各种常用的参数
GC 日志分析
GC 日志参数设置
通过阅读GC日志,我们可以了解Java虚拟机内存分配与回收策略。
内存分配与垃圾回收的参数列表
- -XX:+PrintGC :输出GC日志。类似:-verbose:gc
- -XX:+PrintGCDetails :输出GC的详细日志
- -XX:+PrintGCTimestamps :输出GC的时间戳(以基准时间的形式)
- -XX:+PrintGCDatestamps :输出GC的时间戳(以日期的形式,如2013-05-04T21: 53: 59.234 +0800)
- -XX:+PrintHeapAtGC :在进行GC的前后打印出堆的信息
- -Xloggc:…/logs/gc.log :日志文件的输出路径
GC 日志查看工具
GCViewer、GCEasy、GCHisto、GCLogViewer、Hpjmeter、garbagecat 等
GC 日志补充说明
- “[GC” 和 “[Full GC” 说明了这次垃圾收集的停顿类型,如果有 Full 则说明 GC 发生了 “Stop The World”
- 使用 Serial 收集器在新生代的名字是 Default New Generation,因此显示的是 “[DefNew”
- 使用 ParNew 收集器在新生代的名字会变成 “ParNew”,意思是 “Parallel New Generation”
- 使用 Parallel scavenge 收集器在新生代的名字是 “PSYoungGen”
- 老年代的收集和新生代道理一样,名字也是收集器决定的
- 使用 G1 收集器的话,会显示为 “garbage-first heap”
- Allocation Failure 表明本次引起 GC 的原因是因为在年轻代中没有足够的空间能够存储新的数据了。
- [PSYoungGen: 5986K->696K(8704K) ] 5986K->704K (9216K)
- 中括号内:GC 回收前年轻代大小,回收后大小,(年轻代总大小)
- 括号外:GC 回收前年轻代和老年代大小,回收后大小,(年轻代和老年代总大小)
- user 代表用户态回收耗时,sys 内核态回收耗时,real 实际耗时。由于多核线程切换的原因,时间总和可能会超过 real 时间
垃圾回收器的新发展
垃圾回收器的发展过程
GC 仍然处于飞速发展之中,目前的默认选项 G1 GC 在不断的进行改进,很多我们原来认为的缺点,例如串行的 Full GC、Card Table 扫描的低效等,都已经被大幅改进,例如,JDK10 以后,Full GC 已经是并行运行,在很多场景下,其表现还略优于 Parallel GC 的并行 Full GC 实现。
即使是 Serial GC,虽然比较古老,但是简单的设计和实现未必就是过时的,它本身的开销,不管是GC相关数据结构的开销,还是线程的开销,都是非常小的,所以随着云计算的兴起,在 Serverless 等新的应用场景下,Serial GC 找到了新的舞台。
比较不幸的是 CMS GC,因为其算法的理论缺陷等原因,虽然现在还有非常大的用户群体,但在 JDK 9 中已经被标记为废弃,并在 JDK 14 版本中移除。
现在 G1 回收器已成为默认回收器好几年了。我们还看到了引入了两个新的收集器:ZGC(JDK 11出现)和 Shenandoah(Open JDK 12),其特点:主打低停顿时间。
Shenandoah GC
Open JDK12的Shenandoash GC:低停顿时间的GC(实验性)
Shenandoah 无疑是众多 GC 中最孤独的一个。是第一款不由 Oracle 公司团队领导开发的 Hotspot 垃圾收集器。不可避免的受到官方的排挤。比如号称 openJDK 和 OracleJDK 没有区别的 Oracle 公司仍拒绝在 Oracle JDK12 中支持 Shenandoah。
Shenandoah 垃圾回收器最初由 RedHat 进行的一项垃圾收集器研究项目 Pauseless GC 的实现,旨在针对 JVM 上的内存回收实现低停顿的需求。在 2014 年贡献给 OpenJDK。
Red Hat 研发 Shenandoah 团队对外宣称,Shenandoah 垃圾回收器的暂停时间与堆大小无关,这意味着无论将堆设置为 200MB 还是200GB,99.9% 的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。
这是 RedHat 在 2016 年发表的论文数据,测试内容是使用 ES 对 200GB 的维基百科数据进行索引。从结果看:
- 停顿时间比其他几款收集器确实有了质的飞跃,但也未实现最大停顿时间控制在十毫秒以内的目标。
- 而吞吐量方面出现了明显的下降,总运行时间是所有测试收集器里最长的。
总结
- Shenandoah GC 的弱项:高运行负担下的吞吐量下降。
- Shenandoah GC 的强项:低延迟时间。
相关解读:尚硅谷宋红康Java12&13新特性教程(深入解读java12&13)
https://www.bilibili.com/video/BV1jJ411M7kQ
令人震惊、革命性的 ZGC
官方文档:https://docs.oracle.com/en/java/javase/12/gctuning/
ZGC 与 Shenandoah 目标高度相似,在尽可能对吞吐量影响不大的前提下,实现在任意堆内存大小下都可以把垃圾收集的停颇时间限制在十毫秒以内的低延迟。
《深入理解Java虚拟机》一书中这样定义 ZGC:ZGC 收集器是一款基于 Region 内存布局的,(暂时)不设分代的,使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的,以低延迟为首要目标的一款垃圾收集器。
ZGC 的工作过程可以分为 4 个阶段:并发标记 - 并发预备重分配 - 并发重分配 - 并发重映射 等。
ZGC 几乎在所有地方并发执行的,除了初始标记的是 STW 的。所以停顿时间几乎就耗费在初始标记上,这部分的实际时间是非常少的。
在 ZGC 的强项停顿时间测试上,它毫不留情的将 Parallel、G1 拉开了两个数量级的差距。无论平均停顿、95% 停顿、99.8% 停顿、99. 98% 停顿,还是最大停顿时间,ZGC 都能毫不费劲控制在 10 毫秒以内。
虽然 ZGC 还在试验状态,没有完成所有特性,但此时性能已经相当亮眼,用“令人震惊、革命性”来形容,不为过。未来将在服务端、大内存、低延迟应用的首选垃圾收集器。
面向大堆的 AliGC
AliGC 是阿里巴巴 JVM 团队基于 G1 算法,面向大堆(LargeHeap)应用场景。指定场景下的对比:
如若内容造成侵权/违法违规/事实不符,请联系编程学习网邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
相关文章
- ‘keytool‘ 不是内部或外部命令,也不是可运行的程序
关于As里直接输入keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey 报错问题 直接上步骤: C盘的User里面找到.android文件路径类似:C:\Users\86136\.android 这个下面就有debug.keystore文件,也就是C:\User…...
2024/4/27 23:47:29 - wsl字体配置(修改注册表)
本文主要记录配置wsl字体遇到的问题即采用的解决方案。 1.为什么要改注册表 首先,wsl字体可以在”默认值“里修改,但是一旦进入到vim中就立刻被打回原型(宋体)。难受的同时,找到了改注册表的解决方案。 2.ubuntu.exe到底在哪里…...
2024/4/28 4:23:25 - Java 进阶 07 —— JVM 垃圾回收相关概念
文章目录System.gc() 的理解内存溢出与内存泄露内存溢出内存泄露Stop The World垃圾回收的并行与并发并发(Concurrent)并行(Parallel)并发 vs 并行垃圾回收的并发与并行安全点与安全区域安全点(Safe Point)…...
2024/4/28 22:10:21 - 基于WEB的开放性实验室管理系统
技术:Java、JSP等 摘要:高等学校实验室是进行实验教学、开展科学研究、推动科技发展的重要基地,是学校教学科研工作的重要组成部分,实验室建设与管理水平直接关系到培养人才的质量。而互联网目前正极大地改变着我们的生活…...
2024/4/28 4:36:58 - Mybatis访问Db2小例子
环境 Db2 $ db2level DB21085I This instance or install (instance name, where applicable: "db2inst1") uses "64" bits and DB2 code release "SQL11050" with level identifier "0601010F". Informational tokens are "D…...
2024/4/28 19:04:57 - python深度学习笔记3—— 卷积神经网络简介
卷积运算 密集连接层和卷积层的根本区别: Dense 层从输入特征空间中学到的是全局模式(比如对于 MNIST 数字,全局模式就是涉及所有像素的模式) 卷积层学到的是局部模式,对于图像来说,学到的就是在输入图像的…...
2024/4/28 17:00:21 - 《Java接口与抽象类异同(细节太多)|CSDN创作打卡》
目录 接口 1、接口的定义 2、接口变量 3、接口的使用 4、不同类实现接口实例 抽象类 1、抽象类的定义 2、抽象方法的定义 3、抽象类实例 抽象类与接口的区别 一起进步吧! 接口 1、接口的定义 接口用于规范对象应有的行为。接w口定义形式如下:…...
2024/4/27 21:17:53 - nodejs入门
0. 学习目标 能够按照文档安装Node.js 能够使用npm安装组件 能够使用webpack打包js 能够说出es6中let和const变量的区别 使用解构表达式处理对象属性 能够使用export导出模块文件 能够使用import导入模块文件 1. Node.js 1.1. 什么是Node.js 简单的说 Node.js 就是运行…...
2024/4/28 11:56:50 - MySQL 的“回表”
小伙伴们在面试的时候,有一个特别常见的问题,那就是数据库的回表。什么是回表?为什么需要回表? 今天就来和大家聊一聊这个话题。 1. 索引结构 要搞明白这个问题,需要大家首先明白 MySQL 中索引存储的数据结构。这个…...
2024/4/28 22:31:51 - showdoc安装与脚本生成文档
前言 showdoc官方提供了一种自动化生成接口和文档的方案。在代码里编写特定格式的程序注释,然后程序就可以通过读取这些注释来自动生成文档。由于这种方式不跟特定的语言耦合,因此它的使用范围相当广泛,可以支持c、java、php、node等等常见的…...
2024/4/16 21:31:50 - Sketch VS Pixso:这两款热门界面设计软件,谁更能打?
设计团队进行文件迁移的时候,最大的麻烦不是整理、清理或传输文件至另一台设备,而是采用新的设计软件。就好比你仍然是用键盘打字,但是字母键位于键盘的右边而不是左边,操作者需要大量时间重新训练肌肉记忆,适用新的工…...
2024/4/13 9:55:51 - #systemverilog# 关键字之 program
一 概览 关键字 program ,是在 systermverilog 中才引入的。通常,module 是Verilog世界中的基本构建块。module 中可以包含其他模块的层次结构module 、wire、任务和函数声明,以及过程语句 always 或者 initial 。这个结构对于描述硬件非常有效。然而,对于测试台来说,重…...
2024/4/19 11:57:59 - nvm安装node时,npm自动安装失败,问题研究所得...
废话:在搭建RN环境后,日常打开原来的react项目,发现报错,是因为react项目中用到了sass相关...,尝试解决无果,决定重新配置node环境。 一、产生问题: 第一步:用网上推荐的nvm安装包…...
2024/4/13 9:55:56 - IO流小结
IO流小总结1.IO流总述1.1划分1.2明确IO流的功能2.File类概述2.1File类的一些基本操作2.2 文件的递归调用显示内容3.输入流和输出流3.1输入流3.2输出流(一般要配合缓存)4.序列化和反序列化(ObjectOutputStream和ObjectInputStream)…...
2024/4/13 9:56:01 - 若依前端Vue代码中怎样获取当前登录用户
场景 若依微服务版手把手教你本地搭建环境并运行前后端项目: 若依微服务版手把手教你本地搭建环境并运行前后端项目_BADAO_LIUMANG_QIZHI的博客-CSDN博客_若依微服务 在上面搭建起来前后端架构的基础上,怎样在前端Vue代码中获取当前登录用户。 注&…...
2024/4/20 16:02:45 - 刘二大人《Pytorch深度学习与实践》08加载数据集课后作业——titanic生存预测
具体代码如下,文件路径需要换成自己的 import numpy as np import torch from torch.utils.data import Dataset import pandas as pd from torch.utils.data import DataLoader# 数据准备 # 1、定义自己的数据集类 class My_dataset(Dataset): # 定义自己的数据集…...
2024/4/19 12:17:48 - 美赛 7:图论模型、分类模型(十大模型篇)
目录 五、图论模型 1.迪杰斯特拉(Dijkstra)算法、贝尔曼-福特(Bellman-Ford)算法 2.弗洛伊德(Floyd)算法 六、分类模型 1.逻辑回归 2.Fisher线性判别分析 五、图论模型 图论模型主要解决最短路径问题…...
2024/4/19 15:39:32 - java面向对象 和类
1.java面向对象概述 面向对象简称 OO(Object Oriented),20 世纪 80 年代以后,有了面向对象分析(OOA)、 面向对象设计(OOD)、面向对象程序设计(OOP)等新的系统开发方式模型的研究。 面向对象是一种思想,能让复杂问题简单化,程序员不需要了解具体的实现过程,只需要…...
2024/4/13 9:55:56 - Linux学习九章之文件的归档和压缩
目录 第九章 文件的归档和压缩 9.1 tar命令进行文件的归档和压缩 9.1.1 归档和压缩文件 9.1.2 tar 归档压缩 9.2 zip管理压缩文件 9.3 了解gzip-bzip2- xz管理压缩文件-file-sort查看文件 9.3.1 压缩工具 9.3.2 file查看文件 9.3.3 按一定规则排序查看文件 9.…...
2024/4/13 9:56:06 - 基于FPGA可编程网卡的高性能采集方案
架构困境:性能的天花板触手可及 在过去的20多年中,处理器的性能以每年大约55%速度快速提升,而内存性能的提升速度则只有每年10%左右。内存瓶颈导致高性能处理器难以发挥出应有的功效,这对日益增长的高性能计算形成了极大的制约。…...
2024/4/19 11:17:48
最新文章
- 【C语言】贪吃蛇详解(附源码)
一、贪吃蛇实现效果 【C语言】贪吃蛇(控制台) 二、源码 🎈🎈🎈Snake 残风也想永存/C语言项目 - 码云 - 开源中国 (gitee.com)🎈🎈🎈 三、如何使用C语言去实现一个贪吃蛇?…...
2024/4/29 0:08:10 - 梯度消失和梯度爆炸的一些处理方法
在这里是记录一下梯度消失或梯度爆炸的一些处理技巧。全当学习总结了如有错误还请留言,在此感激不尽。 权重和梯度的更新公式如下: w w − η ⋅ ∇ w w w - \eta \cdot \nabla w ww−η⋅∇w 个人通俗的理解梯度消失就是网络模型在反向求导的时候出…...
2024/3/20 10:50:27 - 09 spring-boot-acurator 定时检测 redis 集群导致 “IOException: Too many open files“
前言 问题的现象主要是如下 项目刚启动的时候 十分正常, 然后 随着时间的推移, 比如说 项目跑了 四五天之后 项目 突然出现问题, 一部分服务能够正常访问, 一部分服务抛出异常 异常信息 就是 too many files 这里的主要的问题是 在异常之前, redis 集群没有密码, 然后 …...
2024/4/27 9:24:59 - 图像处理相关知识 —— 椒盐噪声
椒盐噪声是一种常见的图像噪声类型,它会在图像中随机地添加黑色(椒)和白色(盐)的像素点,使图像的质量降低。这种噪声模拟了在图像传感器中可能遇到的问题,例如损坏的像素或传输过程中的干扰。 椒…...
2024/4/23 15:25:06 - nodeJs 实现视频的转换(超详细教程)
前段时间拿到一个视频是4k的,没法播放,于是通过 node.js 和 ffmpeg 实现了视频的转换。在win10 系统下实现。 所需工具 node 16.19 直接安装 ffmpeg-5.1.1-essentials_build 解压后重名 ffmpeg 放到C盘 然后配置下环境变量 Git-2.42.0.2-64-bit 直接…...
2024/4/28 12:48:25 - 【外汇早评】美通胀数据走低,美元调整
原标题:【外汇早评】美通胀数据走低,美元调整昨日美国方面公布了新一期的核心PCE物价指数数据,同比增长1.6%,低于前值和预期值的1.7%,距离美联储的通胀目标2%继续走低,通胀压力较低,且此前美国一季度GDP初值中的消费部分下滑明显,因此市场对美联储后续更可能降息的政策…...
2024/4/28 13:52:11 - 【原油贵金属周评】原油多头拥挤,价格调整
原标题:【原油贵金属周评】原油多头拥挤,价格调整本周国际劳动节,我们喜迎四天假期,但是整个金融市场确实流动性充沛,大事频发,各个商品波动剧烈。美国方面,在本周四凌晨公布5月份的利率决议和新闻发布会,维持联邦基金利率在2.25%-2.50%不变,符合市场预期。同时美联储…...
2024/4/28 3:28:32 - 【外汇周评】靓丽非农不及疲软通胀影响
原标题:【外汇周评】靓丽非农不及疲软通胀影响在刚结束的周五,美国方面公布了新一期的非农就业数据,大幅好于前值和预期,新增就业重新回到20万以上。具体数据: 美国4月非农就业人口变动 26.3万人,预期 19万人,前值 19.6万人。 美国4月失业率 3.6%,预期 3.8%,前值 3…...
2024/4/26 23:05:52 - 【原油贵金属早评】库存继续增加,油价收跌
原标题:【原油贵金属早评】库存继续增加,油价收跌周三清晨公布美国当周API原油库存数据,上周原油库存增加281万桶至4.692亿桶,增幅超过预期的74.4万桶。且有消息人士称,沙特阿美据悉将于6月向亚洲炼油厂额外出售更多原油,印度炼油商预计将每日获得至多20万桶的额外原油供…...
2024/4/28 13:51:37 - 【外汇早评】日本央行会议纪要不改日元强势
原标题:【外汇早评】日本央行会议纪要不改日元强势近两日日元大幅走强与近期市场风险情绪上升,避险资金回流日元有关,也与前一段时间的美日贸易谈判给日本缓冲期,日本方面对汇率问题也避免继续贬值有关。虽然今日早间日本央行公布的利率会议纪要仍然是支持宽松政策,但这符…...
2024/4/27 17:58:04 - 【原油贵金属早评】欧佩克稳定市场,填补伊朗问题的影响
原标题:【原油贵金属早评】欧佩克稳定市场,填补伊朗问题的影响近日伊朗局势升温,导致市场担忧影响原油供给,油价试图反弹。此时OPEC表态稳定市场。据消息人士透露,沙特6月石油出口料将低于700万桶/日,沙特已经收到石油消费国提出的6月份扩大出口的“适度要求”,沙特将满…...
2024/4/27 14:22:49 - 【外汇早评】美欲与伊朗重谈协议
原标题:【外汇早评】美欲与伊朗重谈协议美国对伊朗的制裁遭到伊朗的抗议,昨日伊朗方面提出将部分退出伊核协议。而此行为又遭到欧洲方面对伊朗的谴责和警告,伊朗外长昨日回应称,欧洲国家履行它们的义务,伊核协议就能保证存续。据传闻伊朗的导弹已经对准了以色列和美国的航…...
2024/4/28 1:28:33 - 【原油贵金属早评】波动率飙升,市场情绪动荡
原标题:【原油贵金属早评】波动率飙升,市场情绪动荡因中美贸易谈判不安情绪影响,金融市场各资产品种出现明显的波动。随着美国与中方开启第十一轮谈判之际,美国按照既定计划向中国2000亿商品征收25%的关税,市场情绪有所平复,已经开始接受这一事实。虽然波动率-恐慌指数VI…...
2024/4/28 15:57:13 - 【原油贵金属周评】伊朗局势升温,黄金多头跃跃欲试
原标题:【原油贵金属周评】伊朗局势升温,黄金多头跃跃欲试美国和伊朗的局势继续升温,市场风险情绪上升,避险黄金有向上突破阻力的迹象。原油方面稍显平稳,近期美国和OPEC加大供给及市场需求回落的影响,伊朗局势并未推升油价走强。近期中美贸易谈判摩擦再度升级,美国对中…...
2024/4/27 17:59:30 - 【原油贵金属早评】市场情绪继续恶化,黄金上破
原标题:【原油贵金属早评】市场情绪继续恶化,黄金上破周初中国针对于美国加征关税的进行的反制措施引发市场情绪的大幅波动,人民币汇率出现大幅的贬值动能,金融市场受到非常明显的冲击。尤其是波动率起来之后,对于股市的表现尤其不安。隔夜美国股市出现明显的下行走势,这…...
2024/4/25 18:39:16 - 【外汇早评】美伊僵持,风险情绪继续升温
原标题:【外汇早评】美伊僵持,风险情绪继续升温昨日沙特两艘油轮再次发生爆炸事件,导致波斯湾局势进一步恶化,市场担忧美伊可能会出现摩擦生火,避险品种获得支撑,黄金和日元大幅走强。美指受中美贸易问题影响而在低位震荡。继5月12日,四艘商船在阿联酋领海附近的阿曼湾、…...
2024/4/28 1:34:08 - 【原油贵金属早评】贸易冲突导致需求低迷,油价弱势
原标题:【原油贵金属早评】贸易冲突导致需求低迷,油价弱势近日虽然伊朗局势升温,中东地区几起油船被袭击事件影响,但油价并未走高,而是出于调整结构中。由于市场预期局势失控的可能性较低,而中美贸易问题导致的全球经济衰退风险更大,需求会持续低迷,因此油价调整压力较…...
2024/4/26 19:03:37 - 氧生福地 玩美北湖(上)——为时光守候两千年
原标题:氧生福地 玩美北湖(上)——为时光守候两千年一次说走就走的旅行,只有一张高铁票的距离~ 所以,湖南郴州,我来了~ 从广州南站出发,一个半小时就到达郴州西站了。在动车上,同时改票的南风兄和我居然被分到了一个车厢,所以一路非常愉快地聊了过来。 挺好,最起…...
2024/4/28 1:22:35 - 氧生福地 玩美北湖(中)——永春梯田里的美与鲜
原标题:氧生福地 玩美北湖(中)——永春梯田里的美与鲜一觉醒来,因为大家太爱“美”照,在柳毅山庄去寻找龙女而错过了早餐时间。近十点,向导坏坏还是带着饥肠辘辘的我们去吃郴州最富有盛名的“鱼头粉”。说这是“十二分推荐”,到郴州必吃的美食之一。 哇塞!那个味美香甜…...
2024/4/25 18:39:14 - 氧生福地 玩美北湖(下)——奔跑吧骚年!
原标题:氧生福地 玩美北湖(下)——奔跑吧骚年!让我们红尘做伴 活得潇潇洒洒 策马奔腾共享人世繁华 对酒当歌唱出心中喜悦 轰轰烈烈把握青春年华 让我们红尘做伴 活得潇潇洒洒 策马奔腾共享人世繁华 对酒当歌唱出心中喜悦 轰轰烈烈把握青春年华 啊……啊……啊 两…...
2024/4/26 23:04:58 - 扒开伪装医用面膜,翻六倍价格宰客,小姐姐注意了!
原标题:扒开伪装医用面膜,翻六倍价格宰客,小姐姐注意了!扒开伪装医用面膜,翻六倍价格宰客!当行业里的某一品项火爆了,就会有很多商家蹭热度,装逼忽悠,最近火爆朋友圈的医用面膜,被沾上了污点,到底怎么回事呢? “比普通面膜安全、效果好!痘痘、痘印、敏感肌都能用…...
2024/4/27 23:24:42 - 「发现」铁皮石斛仙草之神奇功效用于医用面膜
原标题:「发现」铁皮石斛仙草之神奇功效用于医用面膜丽彦妆铁皮石斛医用面膜|石斛多糖无菌修护补水贴19大优势: 1、铁皮石斛:自唐宋以来,一直被列为皇室贡品,铁皮石斛生于海拔1600米的悬崖峭壁之上,繁殖力差,产量极低,所以古代仅供皇室、贵族享用 2、铁皮石斛自古民间…...
2024/4/28 5:48:52 - 丽彦妆\医用面膜\冷敷贴轻奢医学护肤引导者
原标题:丽彦妆\医用面膜\冷敷贴轻奢医学护肤引导者【公司简介】 广州华彬企业隶属香港华彬集团有限公司,专注美业21年,其旗下品牌: 「圣茵美」私密荷尔蒙抗衰,产后修复 「圣仪轩」私密荷尔蒙抗衰,产后修复 「花茵莳」私密荷尔蒙抗衰,产后修复 「丽彦妆」专注医学护…...
2024/4/26 19:46:12 - 广州械字号面膜生产厂家OEM/ODM4项须知!
原标题:广州械字号面膜生产厂家OEM/ODM4项须知!广州械字号面膜生产厂家OEM/ODM流程及注意事项解读: 械字号医用面膜,其实在我国并没有严格的定义,通常我们说的医美面膜指的应该是一种「医用敷料」,也就是说,医用面膜其实算作「医疗器械」的一种,又称「医用冷敷贴」。 …...
2024/4/27 11:43:08 - 械字号医用眼膜缓解用眼过度到底有无作用?
原标题:械字号医用眼膜缓解用眼过度到底有无作用?医用眼膜/械字号眼膜/医用冷敷眼贴 凝胶层为亲水高分子材料,含70%以上的水分。体表皮肤温度传导到本产品的凝胶层,热量被凝胶内水分子吸收,通过水分的蒸发带走大量的热量,可迅速地降低体表皮肤局部温度,减轻局部皮肤的灼…...
2024/4/27 8:32:30 - 配置失败还原请勿关闭计算机,电脑开机屏幕上面显示,配置失败还原更改 请勿关闭计算机 开不了机 这个问题怎么办...
解析如下:1、长按电脑电源键直至关机,然后再按一次电源健重启电脑,按F8健进入安全模式2、安全模式下进入Windows系统桌面后,按住“winR”打开运行窗口,输入“services.msc”打开服务设置3、在服务界面,选中…...
2022/11/19 21:17:18 - 错误使用 reshape要执行 RESHAPE,请勿更改元素数目。
%读入6幅图像(每一幅图像的大小是564*564) f1 imread(WashingtonDC_Band1_564.tif); subplot(3,2,1),imshow(f1); f2 imread(WashingtonDC_Band2_564.tif); subplot(3,2,2),imshow(f2); f3 imread(WashingtonDC_Band3_564.tif); subplot(3,2,3),imsho…...
2022/11/19 21:17:16 - 配置 已完成 请勿关闭计算机,win7系统关机提示“配置Windows Update已完成30%请勿关闭计算机...
win7系统关机提示“配置Windows Update已完成30%请勿关闭计算机”问题的解决方法在win7系统关机时如果有升级系统的或者其他需要会直接进入一个 等待界面,在等待界面中我们需要等待操作结束才能关机,虽然这比较麻烦,但是对系统进行配置和升级…...
2022/11/19 21:17:15 - 台式电脑显示配置100%请勿关闭计算机,“准备配置windows 请勿关闭计算机”的解决方法...
有不少用户在重装Win7系统或更新系统后会遇到“准备配置windows,请勿关闭计算机”的提示,要过很久才能进入系统,有的用户甚至几个小时也无法进入,下面就教大家这个问题的解决方法。第一种方法:我们首先在左下角的“开始…...
2022/11/19 21:17:14 - win7 正在配置 请勿关闭计算机,怎么办Win7开机显示正在配置Windows Update请勿关机...
置信有很多用户都跟小编一样遇到过这样的问题,电脑时发现开机屏幕显现“正在配置Windows Update,请勿关机”(如下图所示),而且还需求等大约5分钟才干进入系统。这是怎样回事呢?一切都是正常操作的,为什么开时机呈现“正…...
2022/11/19 21:17:13 - 准备配置windows 请勿关闭计算机 蓝屏,Win7开机总是出现提示“配置Windows请勿关机”...
Win7系统开机启动时总是出现“配置Windows请勿关机”的提示,没过几秒后电脑自动重启,每次开机都这样无法进入系统,此时碰到这种现象的用户就可以使用以下5种方法解决问题。方法一:开机按下F8,在出现的Windows高级启动选…...
2022/11/19 21:17:12 - 准备windows请勿关闭计算机要多久,windows10系统提示正在准备windows请勿关闭计算机怎么办...
有不少windows10系统用户反映说碰到这样一个情况,就是电脑提示正在准备windows请勿关闭计算机,碰到这样的问题该怎么解决呢,现在小编就给大家分享一下windows10系统提示正在准备windows请勿关闭计算机的具体第一种方法:1、2、依次…...
2022/11/19 21:17:11 - 配置 已完成 请勿关闭计算机,win7系统关机提示“配置Windows Update已完成30%请勿关闭计算机”的解决方法...
今天和大家分享一下win7系统重装了Win7旗舰版系统后,每次关机的时候桌面上都会显示一个“配置Windows Update的界面,提示请勿关闭计算机”,每次停留好几分钟才能正常关机,导致什么情况引起的呢?出现配置Windows Update…...
2022/11/19 21:17:10 - 电脑桌面一直是清理请关闭计算机,windows7一直卡在清理 请勿关闭计算机-win7清理请勿关机,win7配置更新35%不动...
只能是等着,别无他法。说是卡着如果你看硬盘灯应该在读写。如果从 Win 10 无法正常回滚,只能是考虑备份数据后重装系统了。解决来方案一:管理员运行cmd:net stop WuAuServcd %windir%ren SoftwareDistribution SDoldnet start WuA…...
2022/11/19 21:17:09 - 计算机配置更新不起,电脑提示“配置Windows Update请勿关闭计算机”怎么办?
原标题:电脑提示“配置Windows Update请勿关闭计算机”怎么办?win7系统中在开机与关闭的时候总是显示“配置windows update请勿关闭计算机”相信有不少朋友都曾遇到过一次两次还能忍但经常遇到就叫人感到心烦了遇到这种问题怎么办呢?一般的方…...
2022/11/19 21:17:08 - 计算机正在配置无法关机,关机提示 windows7 正在配置windows 请勿关闭计算机 ,然后等了一晚上也没有关掉。现在电脑无法正常关机...
关机提示 windows7 正在配置windows 请勿关闭计算机 ,然后等了一晚上也没有关掉。现在电脑无法正常关机以下文字资料是由(历史新知网www.lishixinzhi.com)小编为大家搜集整理后发布的内容,让我们赶快一起来看一下吧!关机提示 windows7 正在配…...
2022/11/19 21:17:05 - 钉钉提示请勿通过开发者调试模式_钉钉请勿通过开发者调试模式是真的吗好不好用...
钉钉请勿通过开发者调试模式是真的吗好不好用 更新时间:2020-04-20 22:24:19 浏览次数:729次 区域: 南阳 > 卧龙 列举网提醒您:为保障您的权益,请不要提前支付任何费用! 虚拟位置外设器!!轨迹模拟&虚拟位置外设神器 专业用于:钉钉,外勤365,红圈通,企业微信和…...
2022/11/19 21:17:05 - 配置失败还原请勿关闭计算机怎么办,win7系统出现“配置windows update失败 还原更改 请勿关闭计算机”,长时间没反应,无法进入系统的解决方案...
前几天班里有位学生电脑(windows 7系统)出问题了,具体表现是开机时一直停留在“配置windows update失败 还原更改 请勿关闭计算机”这个界面,长时间没反应,无法进入系统。这个问题原来帮其他同学也解决过,网上搜了不少资料&#x…...
2022/11/19 21:17:04 - 一个电脑无法关闭计算机你应该怎么办,电脑显示“清理请勿关闭计算机”怎么办?...
本文为你提供了3个有效解决电脑显示“清理请勿关闭计算机”问题的方法,并在最后教给你1种保护系统安全的好方法,一起来看看!电脑出现“清理请勿关闭计算机”在Windows 7(SP1)和Windows Server 2008 R2 SP1中,添加了1个新功能在“磁…...
2022/11/19 21:17:03 - 请勿关闭计算机还原更改要多久,电脑显示:配置windows更新失败,正在还原更改,请勿关闭计算机怎么办...
许多用户在长期不使用电脑的时候,开启电脑发现电脑显示:配置windows更新失败,正在还原更改,请勿关闭计算机。。.这要怎么办呢?下面小编就带着大家一起看看吧!如果能够正常进入系统,建议您暂时移…...
2022/11/19 21:17:02 - 还原更改请勿关闭计算机 要多久,配置windows update失败 还原更改 请勿关闭计算机,电脑开机后一直显示以...
配置windows update失败 还原更改 请勿关闭计算机,电脑开机后一直显示以以下文字资料是由(历史新知网www.lishixinzhi.com)小编为大家搜集整理后发布的内容,让我们赶快一起来看一下吧!配置windows update失败 还原更改 请勿关闭计算机&#x…...
2022/11/19 21:17:01 - 电脑配置中请勿关闭计算机怎么办,准备配置windows请勿关闭计算机一直显示怎么办【图解】...
不知道大家有没有遇到过这样的一个问题,就是我们的win7系统在关机的时候,总是喜欢显示“准备配置windows,请勿关机”这样的一个页面,没有什么大碍,但是如果一直等着的话就要两个小时甚至更久都关不了机,非常…...
2022/11/19 21:17:00 - 正在准备配置请勿关闭计算机,正在准备配置windows请勿关闭计算机时间长了解决教程...
当电脑出现正在准备配置windows请勿关闭计算机时,一般是您正对windows进行升级,但是这个要是长时间没有反应,我们不能再傻等下去了。可能是电脑出了别的问题了,来看看教程的说法。正在准备配置windows请勿关闭计算机时间长了方法一…...
2022/11/19 21:16:59 - 配置失败还原请勿关闭计算机,配置Windows Update失败,还原更改请勿关闭计算机...
我们使用电脑的过程中有时会遇到这种情况,当我们打开电脑之后,发现一直停留在一个界面:“配置Windows Update失败,还原更改请勿关闭计算机”,等了许久还是无法进入系统。如果我们遇到此类问题应该如何解决呢࿰…...
2022/11/19 21:16:58 - 如何在iPhone上关闭“请勿打扰”
Apple’s “Do Not Disturb While Driving” is a potentially lifesaving iPhone feature, but it doesn’t always turn on automatically at the appropriate time. For example, you might be a passenger in a moving car, but your iPhone may think you’re the one dri…...
2022/11/19 21:16:57