经过测试环境的基本验证后,在线上试跑我们的Flink SQL批量从Hive抽数到HBase程序,出现了GC时间超阈值的警告,
Serial是单线程垃圾回收器,当需要执行垃圾回收时,程序会暂停一切工作,然后单线程执行垃圾回收.
前几篇文章我们已经彻底把垃圾回收机制给讲清楚了,包括ParNew和CMS两个垃圾回收器对新生代和老年代进行垃圾回收的运行原理,大家都了解的很清楚了。
ParNew 收集器其实就是 Serial 收集器的多线程版本,除了使⽤多条线程进⾏垃圾收集之外,其余⾏为包括 Serial 收集器可⽤的所有控制参数(例如:-XX: SurvivorRatio、-XX:PretenureSize’ Threshold、-XX: HandlePromotionFailure 等)、收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全⼀样,在实现上,这两种收集器也共⽤了相当多的代码
Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
Java堆内存被划分为新生代和年老代两部分,新生代主要使用复制和标记-清除垃圾回收年老代主要使用标记-整理垃圾回收算法,因此 java 虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器,JDK1.6 中 Sun HotSpot 虚拟机的垃圾收集器如下:
参考 【Android 内存优化】垃圾回收算法 ( 分代收集算法 | Serial 收集器 | ParNew 收集器 | Parallel Scavenge 收集器 | CMS 并发标记清除收集器 ) 博客 ;
当前主流的VM垃圾收集都采用“分代收集“算法,这种算法会根据对象存活周期的不同将内存划分为几块,
缺点: 当Serial收集器想进行垃圾回收的时候,必须暂停用户的所有进程,即stop the world。
[Full GC 23.32: [ParNew: 2356K->2310K(3251K), 0.000288sec]
我们前面提到了,垃圾回收器的 回收的内容、回收的时机以及回收的方式,接下来我们来看 Java 垃圾回收器。如果垃圾回收算法是内存回收的方法论的话,那么垃圾回收器就是内存回收的具体实现了。
JDK 自带了很多监控工具,都位于 JDK 的 bin 目录下,其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。
by Sven Augustus https://my.oschina.net/langxSpirit
不同版本的 JDK 选择的垃圾收集器也可能不同,我们在命令行查看安装的 JDK 的默认垃圾收集器,我这里是在 Windows 的 cmd 中输入 java -XX:+PrintCommandLineFlags -version,执行结果如下图。
垃圾收集 Garbage Collection 通常被称为“GC”,它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了。
前面文章中,我们介绍了 Java 虚拟机的内存结构,Java 虚拟机的垃圾回收机制,那么这篇文章我们说说具体执行垃圾回收的垃圾回收器。
默认情况下,当CPU数量少于等于8个的时候,并行线程数为8个。如果CPU数量大于8,并行线程数量为 3+(5*cpu_nums/8)
小型程序。默认情况下不会是这种选项,HotSpot会根据计算及配置和JDK版本自动选择收集器
-XX:+UseParNewGC :新生代使用ParNew回收器,老年代使用串行回收器
高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做“生产性”工作。直觉上,吞吐量越高程序运行越快。
概述 垃圾收集 Garbage Collection 通常被称为“GC”,它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了。 jvm 中,程序计数器、虚拟机栈、本地方法栈都是随线程而生随线程而灭,栈帧随着方法的进入和退出做入栈和出栈操作,实现了自动的内存清理,因此,我们的内存垃圾回收主要集中于 java 堆和方法区中,在程序运行期间,这部分内存的分配和使用都是动态的. 对象存活判断 判断对象是否存活一般有两种方式: 引用计数:每个对象有一个引用计数属性,新增一个引用时计数加
young generation-------serial, parnew, parallel scavenge tenured gencration---------CMS, Serial old(MSC), parallel old. parallel scavenge收集器是一个新生代收集器,他也是使用服饰算法的收集器,又是并行的多线程收集器 看上去和parnew差不多,有什么特别的呢? --parallel scavenge收集器的特点是它的关注点与其他收集器不同,CMS等收集器的关注点是 尽可能地缩短垃圾收集时用户线程的停顿时间,而parallel scavenge收集器的目的标准则时 达到一个可控制的吞吐量。 自适应调节策略是parallel scavenge收集器与parnew收集器的一个重要区别。 参数-- -XX:+UseAdaptiveSizePolicy MaxGCPauseMillis GCTimeTatio
每一种收集器的日志形式都是由它们自身的实现所决定的,换而言之,每个收集器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读,将各个收集器的日志都维持一定的共性,例如以下两段典型的GC日志:
第一篇《Jvm垃圾回收器(基础篇)》主要讲述了判断对象的生死?两种基础判断对象生死的算法、引用计数法、可达性分析算法,方法区的回收。在第二篇《Jvm垃圾回收器(算法篇)》中主要介绍了垃圾回收的几种常用算法:标记-清除、复制算法、标记-整理算法、分代收集算法。那么接下来我们重点研究Jvm的垃圾收集器(serial收集器、parnew收集器、parallel scavenge收集器、serial old 收集器、parallel old收集器、cms收集器、g1收集器)。前面说了那么多就是为它做铺垫的。
随着 JDK 版本的不断升级,其 GC 策略也随之不停革新,从早期的 1.4 到如今的 11(本文仅讨论在线上环境落地规模较大的版本),其对应的 GC 策略也随之由 Serial、Parallel、CMS 演进至当前的 G1 甚至即将落地的 ZGC 。每一次的调整无不是基于环境的适配性以及业务场景特性,无论如何,只要能够基于特定的操作系统内核、物理内存、JDK版本以及业务特性,达到收益最大化,采用何种实现策略都不为过。当然,还是建议大家以官方的推荐为准,基于自己的业务场景进行不断优化调整,这样才能保证万无一失,使得我们的业务能够健康发展。
随着 JDK 版本的不断升级,其 GC 策略也随之不停革新,从早期的 1.4 到如今的 11(本文仅讨论在线上环境落地规模较大的版本),其对应的 GC 策略也随之由 Serial、Parallel、CMS 演进至当前的 G1 甚至即将落地的 ZGC 。每一次的调整无不是基于环境的适配性以及业务场景特性,无论如何,只要能够基于特定的操作系统内核、物理内存、JDK 版本以及业务特性,达到收益最大化,采用何种实现策略都不为过。当然,还是建议大家以官方的推荐为准,基于自己的业务场景进行不断优化调整,这样才能保证万无一失,使得我们的业务能够健康发展。
上篇文章介绍了老年分担机制,在minorGC前会先判断一下老年代剩余空间是否大于需要移动的数据,如果大则直接fullGC,否则会看看是否配置了参数,没有则直接fullGC,有的话再算每次yangGC的平均值,再次比较老年代剩余空间,小于他的话则正常yangGC。
上篇文章我们一起分析了JVM的垃圾回收机制,了解了新生代的内存模型,老年代的空间分配担保原则,并简单的介绍了几种垃圾回收器。详细内容小伙伴们可以去看一下我的上篇文章:秒懂JVM的垃圾回收机制。
为了解决 Mark-Sweep 算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小 的两块。每次只使用其中一块,当这一块内存满后将尚存活的对象复制到另一块上去,把已使用 的内存清掉,如图:
常见的垃圾收集器有Serial GC、ParNew GC、CMS GC、Parallel GC、G1 GC
垃圾收集常用的算法有三种。标记-清除算法,标记-复制算法,标记-整理算法。下面一个一个来看:
client模式下默认的垃圾收集器组合,可通过-XX:+UseSerialGC强制开启。非常适合运行于客户端PC的小型应用程序,或者桌面应用程序(比如swing编写的用户界面程序),以及我们平时的开发、调试、测试等。
2、存储大对象,若新生代存放不下,老年代可以存放的下,则直接存放在老年代,也不会触发垃圾回收
http://blog.csdn.net/chjttony/article/details/7883748#comments
在两年前的文章 JVM 学习——垃圾收集器与内存分配策略中,已经对 GC 算法的原理以及常用的垃圾收集器做了相应的总结。今天这篇文章主要是对生产环境中(Java7)常用的两种垃圾收集器(ParNew:年轻代,CMS:老年代)从日志信息上进行分析,做一下总结,这样当我们在排查相应的问题时,看到 GC 的日志信息,不会再那么陌生,能清楚地知道这些日志是什么意思,GC 线程当前处在哪个阶段,正在做什么事情等。
HotSpot虚拟机提供了多种垃圾收集器,每种收集器都有各自的特点,没有最好的垃圾收集器,只有最适合的垃圾收集器 根据新生代和老年代各自的特点,我们应该分别为它们选择不同的收集器,以提升垃圾回收效率.
该行会在JVM Eden内放入一个1M数组,同时在main线程的虚拟机栈压入一个main方法栈帧,其栈帧内部有一“arr1”变量,该变量指向Eden的那1M数组:
在以往的文章中(垃圾收集算法),我们讲述了JVM中垃圾收集算法,像标记-清除、标记-整理、复制、分代等算法,这些只是垃圾收集的方法论,今天要介绍的就是垃圾收集的具体实现---垃圾收集器。
本篇主要介绍一下JVM的几种垃圾收集器。其示意图如下所示,上面的三个是新生代的收集器, 下面三个是老年代的收集器,其中G1收集器是可以用于新生代和老年代的收集工作。 JVM垃圾收集器 1、Serial
Serial 是一款用于新生代的单线程收集器,采用复制算法进行垃圾收集。Serial 进行垃圾收集时,不仅只用一条线程执行垃圾收集工作,它在收集的同时,所有的用户线程必须暂停(Stop The World)。
http://www.importnew.com/18694.html
Serial收集器 Serial收集器是最基本,发展最悠久的收集器,在JDK1.3.1之前是虚拟机新生代垃圾回收的唯一选择。这个收集器是一个单线程的。它的单线程的意义并不仅仅说明它只会使用一个CPU或
相信大家都了解 jps、jmap、jstack 等常用 java 堆栈输出命令,有过 dump、gc 分析的经验,面试中会经常被问到有关 JVM 问题,比如你是否了解你的程序在生产环境的基础配置,堆内存、栈内存怎么设置的,又是怎么估算的大小,或是垃圾回收器及回收垃圾算法的最佳使用策略。作为项目的核心开发人员,别把这些事当成是架构师要干的活,因为代码可是你一行一行码出来的,没人比你更清楚,你得负责从程序开发、黑白盒测试、项目验收、部署上线、集成交付、运维监控、用户体验等环节。越大的企业,项目模块分配的越细,这也并不代表你不需要了解整体系统的性能,其中任何一个环节出问题,都可能导致系统无法正常运行。
Allocation Failure:表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了
每个对象都有一个引用计数器,当对象被引用一次计数器就加 1;当引用失效时计数器就减 1。当对象的计数器为 0 时,对象就是要被回收的。简单高效,缺点是无法解决对象之间相互循环引用的问题。
1. 分代收集算法 : 每个对象的生命周期是不同的 , 某些对象如 Application 整个应用声明周期都存活 , 某些方法的局部变量对象 , 方法结束后 , 该局部对象就可以被回收了 , 不同声明周期的对象使用不同的垃圾回收算法 ;
如果垃圾回收的算法属于内存回收的方法论的话,那本文讨论的垃圾回收器就属于内存回收的具体实现。
[GC (Allocation Failure) [DefNew: 67932K->0K(78720K), 0.0002327 secs] 68792K->859K(253504K), 0.0002491 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 老年代串行收集器
领取专属 10元无门槛券
手把手带您无忧上云