jvm GC

JavaGC、新生代、老年代

Java 中的堆是 JVM所管理的最大的一块内存空间,主要用于存放各种类的实例对象。

在 Java 中,堆被划分成两个不同的区域:新生代 ( Young )、老年代 ( Old )。新生代 ( Young )又被划分为

三个区域:Eden、From Survivor、To Survivor。

这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象,包括内存的分配以及回收。

堆的内存模型大致为:

从图中可以看出: 堆大小 =新生代 + 老年代。其中,堆的大小可以通过参数 –Xms、-Xmx 来指定。

(本人使用的是 JDK1.6,以下涉及的 JVM 默认值均以该版本为准。)
   默认的,新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 (该值可以通过参数 –XX:NewRatio 来指定

),即:新生代 ( Young ) = 1/3 的堆空间大小。老年代 ( Old ) = 2/3 的堆空间大小。其中,新生代 ( Young )

被细分为 Eden 和 两个 Survivor 区域,这两个 Survivor 区域分别被命名为 from 和 to,以示区分。

默认的,Edem : from : to = 8 :1 : 1 (可以通过参数–XX:SurvivorRatio 来设定 ),即: Eden = 8/10 的

新生代空间大小,from = to = 1/10 的新生代空间大小。

JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务,所以无论什么时候,总是有一块Survivor

区域是空闲着的。

因此,新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。

GC 堆                                                                                  

Java 中的堆也是 GC收集垃圾的主要区域。GC 分为两种:Minor GC、FullGC ( 或称为 Major GC )。

Minor GC 是发生在新生代中的垃圾收集动作,所采用的是复制算法

新生代几乎是所有 Java 对象出生的地方,即 Java 对象申请的内存以及存放都是在这个地方。Java 中的大部

分对象通常不需长久存活,具有朝生夕灭的性质。

当一个对象被判定为 "死亡" 的时候,GC 就有责任来回收掉这部分对象的内存空间。新生代是 GC 收集垃圾的

频繁区域。

当对象在 Eden ( 包括一个 Survivor 区域,这里假设是 from 区域 ) 出生后,在经过一次 Minor GC后,如

果对象还存活,并且能够被另外一块 Survivor 区域所容纳(上面已经假设为 from 区域,这里应为 to 区域,

即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 ),则使用复制算法将这些仍然还存活的对

象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中,然后清理所使用过的 Eden以及 Survivor 区域 ( 即

from 区域 ),并且将这些对象的年龄设置为1,以后对象在 Survivor 区每熬过一次 Minor GC,就将对象的年

龄 + 1,当对象的年龄达到某个值时 ( 默认是 15 岁,可以通过参数 -XX:MaxTenuringThreshold 来设定

 ),这些对象就会成为老年代。

但这也不是一定的,对于一些较大的对象 (即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代

Full GC 是发生在老年代的垃圾收集动作,所采用的是标记-清除算法

现实的生活中,老年代的人通常会比新生代的人"早死"。堆内存中的老年代(Old)不同于这个,老年代里面的对象

几乎个个都是在 Survivor 区域中熬过来的,它们是不会那么容易就 "死掉" 了的。因此,Full GC发生的次数不

会有 Minor GC 那么频繁,并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。


   另外,标记-清除算法收集垃圾的时候会产生许多的内存碎片 (即不连续的内存空间 ),此后需要为较大的对象

分配内存空间时,若无法找到足够的连续的内存空间,就会提前触发一次 GC 的收集动作。

GC 日志                                                                               

publicstaticvoid main(String[] args) {

Object obj= new Object();

System.gc();

System.out.println();

obj= new Object();

obj=new Object();

System.gc();

System.out.println();

}

设置 JVM 参数为 -XX:+PrintGCDetails,使得控制台能够显示 GC 相关的日志信息,执行上面代码,下面是其中

一次执行的结果。

Full GC 信息与 Minor GC的信息是相似的,这里就不一个一个的画出来了。

从 Full GC 信息可知,新生代可用的内存大小约为 18M,则新生代实际分配得到的内存空间约为 20M(为什么是

20M? 请继续看下面...)。老年代分得的内存大小约为 42M,堆的可用内存的大小约为 60M。可以计算出: 18432K

( 新生代可用空间 ) + 42112K ( 老年代空间 ) = 60544K ( 堆的可用空间 )

新生代约占堆大小的 1/3,老年代约占堆大小的 2/3。也可以看出,GC 对新生代的回收比较乐观,而对老年代

以及方法区的回收并不明显或者说不及新生代。

并且在这里 Full GC 耗时是 Minor GC 的 22.89 倍。

JVM 参数选项                                                                        

下面只列举其中的几个常用和容易掌握的配置选项


-Xms


初始堆大小。如:-Xms256m


-Xmx


最大堆大小。如:-Xmx512m


-Xmn


新生代大小。通常为 Xmx 的 1/3 或 1/4。新生代 = Eden + 2 个 Survivor 空间。实际可用空间为 = Eden + 1 个 Survivor,即 90%


-Xss


JDK1.5+ 每个线程堆栈大小为 1M,一般来说如果栈不是很深的话, 1M 是绝对够用了的。


-XX:NewRatio


新生代与老年代的比例,如 –XX:NewRatio=2,则新生代占整个堆空间的1/3,老年代占2/3


-XX:SurvivorRatio


新生代中 Eden 与 Survivor 的比值。默认值为 8。即 Eden 占新生代空间的 8/10,另外两个 Survivor 各占 1/10


-XX:PermSize


永久代(方法区)的初始大小


-XX:MaxPermSize


永久代(方法区)的最大值


-XX:+PrintGCDetails


打印 GC 信息


-XX:+HeapDumpOnOutOfMemoryError


让虚拟机在发生内存溢出时 Dump 出当前的内存堆转储快照,以便分析用

时间: 2024-11-05 14:56:14

jvm GC的相关文章

Java性能优化之JVM GC(垃圾回收机制)

Java的性能优化,整理出一篇文章,供以后温故知新. JVM GC(垃圾回收机制) 在学习Java GC 之前,我们需要记住一个单词:stop-the-world .它会在任何一种GC算法中发生.stop-the-world 意味着JVM因为需要执行GC而停止了应用程序的执行.当stop-the-world 发生时,除GC所需的线程外,所有的线程都进入等待状态,直到GC任务完成.GC优化很多时候就是减少stop-the-world 的发生. JVM GC回收哪个区域内的垃圾? 需要注意的是,JV

JVM GC调优一则--增大Eden Space提高性能

缘起 线上有Tomcat升级到7.0.52版,然后有应用的JVM FullGC变频繁,在高峰期socket连接数,Cpu使用率都暴增. 思路 思路是Tomcat本身的代码应该是没有问题的,有问题的可能是应用代码升级,或者环境改变了,总之Tomcat的优先级排在最后. 先把应用的heap dump下来分析下: jmap -dump:format=b,file=path pid 用IBM的Heap Analyser分析,发现dubbo rpc调用的RpcInvocation对象和taglibs的Si

【甘道夫】HBase随机宕机事件处理 & JVM GC回顾

一.引言 本文记录了困扰团队两周的HBase随机宕机事件的解决方案,并回顾了JVM GC调优基础知识,供各位参考. 欢迎转载,请注明出处: http://blog.csdn.net/u010967382/article/details/42394031 二.实验环境 16台虚拟机,每台4G内存,1核CPU,400G硬盘 Ubuntu 14.04 LTS (GNU/Linux 3.13.0-29-generic x86_64) CDH5.2.0套装(包括相应版本的Hadoop,HIVE,Hbase

【转载】Java性能优化之JVM GC(垃圾回收机制)

章来源:https://zhuanlan.zhihu.com/p/25539690 Java的性能优化,整理出一篇文章,供以后温故知新. JVM GC(垃圾回收机制) 在学习Java GC 之前,我们需要记住一个单词:stop-the-world .它会在任何一种GC算法中发生.stop-the-world 意味着JVM因为需要执行GC而停止了应用程序的执行.当stop-the-world 发生时,除GC所需的线程外,所有的线程都进入等待状态,直到GC任务完成.GC优化很多时候就是减少stop-

深入浅出 JVM GC(3)

# 前言 在 深入浅出 JVM GC(2) 中,我们介绍了一些 GC 算法,GC 名词,同时也留下了一个问题,就是每个 GC 收集器的具体作用.有哪些 GC 收集器呢? Serial 串行收集器(只适用于堆内存 256M 以下的 JVM ) ParNew 并行收集器(Serial 收集器的多线程版本) Parallel Scavenge (PS 收集器,该收集器以吞吐量为主要目的,是1.8的默认 GC) CMS 收集器(该收集器全称 Concurrent Mark Sweep,是一种关注最短停顿

深入浅出 JVM GC(2)

# 前言 在 深入浅出 JVM GC(1) 中,限于上篇文章的篇幅,我们留下了一个问题 : 如何回收? 这篇文章将重点讲述这个问题. 在上篇文章中,我们也列出了一些大纲,今天我们就按照那个大纲来逐个讲解.在此,我将大纲复制过来. 垃圾回收算法 标记清除算法 复制算法 标记整理算法 分代收集算法(堆如何分代) 有哪些垃圾收集器 Serial 串行收集器(只适用于堆内存256m 以下的 JVM ) ParNew 并行收集器(Serial 收集器的多线程版本) Parallel Scavenge (P

JVM GC算法 垃圾回收器

JVM的垃圾回收算法有三种: 1.标记-清除(mark-sweep):啥都不说,直接上图 2.标记-整理(mark-compact) 3.复制(copy) 分代收集算法                                                    目前的垃圾回收都采用分代收集算法.也就衍生了很多垃圾收集器 "分代收集"(Generational Collection)算法,把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法. 在新生

JVM GC总结

一:Java内存区的简单介绍 1.堆(Heap) JVM初始分配的内存由-Xms指定,默认是物理内存的1/64. JVM最大分配的内存由-Xmx指定,默认是物理内存的1/4. 默认空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制,可以由-XX:MinHeapFreeRatio=参数,来指定. 默认空余堆内存小于70%时,JVM会减少堆直到-Xms的最小限制,可以由-XX:MaxHeapFreeRatio=参数,来指定. 注:服务器一般设置-Xms和-Xmx相等以避免每次GC后频繁的

JVM—GC回收机制

JVM垃圾回收机制 JVM分别对新生代和旧生代采用不同的垃圾回收机制. 新生代的GC: 新生代通常存活时间较短,因此基于Copying算法来进行回收,所谓Copying算法就是扫描出存活的对象,并复制到一块新的完全未使用的空间中,对应于新生代,就是在Eden和FromSpace或ToSpace之间copy.新生代采用空闲指针的方式来控制GC触发,指针保持最后一个分配的对象在新生代区间的位置,当有新的对象要分配内存时,用于检查空间是否足够,不够就触发GC.当连续分配对象时,对象会逐渐从eden到

JVM GC之一找出不可达对象并回收

JAVA运行时数据区域 1.程序计数器:当前线程所执行的字节码的行号指示器.一个处理器只会执行一条线程中的指令,为了线程切换后能回复到正确的执行位置,所以每条线程都需要一个独立的计数器.各条线程之间互不影响,独立存储,属于'线程私有'内存. 2.java虚拟机栈:描述的是JAVA方法执行的内存模型:每个方法执行的时候都会创建一个栈帧用于存储局部变量表.操作数栈.动态链接.方法出口等信息.每个方法的被调用直至执行完成的过程,就对应着一个栈帧在虚拟机中从入栈到出栈的过程.所以也是线程私有的. 3.本