JVM GC一个对象的朝生夕死

 一,假如活在一个没有分代的连续内存中

   假设程序占用的内存是从0000~FFFF这个地址,现在程序执行到给一个对象分配内存的那部分代码,给这个对象分配了2345~2346这段内存,程序继续执行,到了某一个时刻,程序分配的内存地址用完了,这时候,程序要回收这段地址里面,已经无用的对象,那么,它首先要从头到尾扫描一遍,然后把其中没用的地址空间找到,之后将对象占用地址的起始位置和终止位置进行一个向上或者向下的移动,将不连续的地址变成连续的地址空间,打扫房间结束,程序继续分配内存执行程序;在一整块连续的内存中,进行所有对象的分配,方式是比较简单的,但是就是每次都要从头到尾的扫描一遍,如果程序占用的内存非常大,或者程序需要对外部响应非常及时,这时候,就会出现很大的问题了。

二,two part

     将可用内存分为:常回收内存部分+不常回收部分。按照对象是否经常被回收进行分配内存。对象创建之后,先放入常常进行垃圾回收的内存空间中,如果好久不释放,再放入不常回收的部分。需要制定一个标准或者规则,来定义多久对象从常回收部分移动到不常被回收的部分。

    这部分主要是为了说明为什么要分代回收。

三,s0,s1 Eden部分

   这三部分都属于新生代,对象被创建之后,首先放入Eden中,经过一次Minor GC,被放入From Survivor,再次Minor GC,想象你此时身处From Survivor中,你身边有着经历过16此Minor GC还活着的老对象,它们被移动到了老年代中,还有像你似的,只经历过一两次的,你们一起被复制到了To Survivor中,最后,From Survivor空了,Eden也空了,之后,To Survivor连续整齐的排列着熬下来还属于青年的新生代对象,From Survivor与To进行交换,此时,你又回到了From survivor中,静静地等着下一个时钟周期的到来。。

四,s部分作用

   如果没有s部分,每次新创建的对象,先被放到Eden,满了之后,放到老年代,老年代满了,full gc,你会发现,full gc其实是很频繁的,为了不经常对老年代进行回收,就要把年轻代里面对象的回收,做的过程久一点,放入到老年代的条件严格一点儿,所以加入一个中间缓冲带S。

五,s0与s1

     试想如果仅有s,在某个对新生代回收的时刻,这时候,在Eden与S部分,都有不连续的内存空间,合并之后,空间还是不连续的,有时候可能会出现这种情况,给一个对象分配空间,总的剩余容量是足够的,但是没有连续的空间可以达到对象的大小,这就尴尬了。所以,为了减少这种碎碎念的出现,s拆分为s0,s1,两部分采用复制算法进行对象交换,保证了在某个时刻,一个s是空的,另一个空间是连续的。

  

时间: 2024-08-21 10:52:58

JVM GC一个对象的朝生夕死的相关文章

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

jvm GC日志解读

0.产生日志 0.1 IDE 运行下面代码会得到gc日志. 0.2 server -Xloggc:../gclogdir/logc.txt   指定gc日志的打印位置,注意必须指定到文件,不能为目录. 当应用重启时,会产生新的gc.log,旧的gc.log自动被重命名为形如 "gc.log.20161103103532"这样的格式. 1.Parallel Scavenge 这是一款年轻代GC器. 293.271: [GC [PSYoungGen: 300865K->6577K(3

JVM GC算法 CMS 详解(转)

前言 CMS,全称Concurrent Low Pause Collector,是jdk1.4后期版本开始引入的新gc算法,在jdk5和jdk6中得到了进一步改进,它的主要适合场景是对响应时间的重要性需求 大于对吞吐量的要求,能够承受垃圾回收线程和应用线程共享处理器资源,并且应用中存在比较多的长生命周期的对象的应用.CMS是用于对tenured generation的回收,也就是年老代的回收,目标是尽量减少应用的暂停时间,减少full gc发生的几率,利用和应用程序线程并发的垃圾回收线程来标记清

jvm gc相关

1. 杂类 http://www.oracle.com/technetwork/java/faq-140837.html  *    -XX:+UseParallelGC : 和传统的新生代GC一样,只是可以进行并行标记处理. 可通过-XX:ParallelGCThreads指定并发线程数,默认值:-XX:ParallelGCThreads =<#cpus < 8 ? #cpus : 3 + ((5 * #cpus) / 8) > 1.The new parallel garbage c

从JVM的内存管理角度分析Java的GC垃圾回收机制_java

一个优秀的Java程序员必须了解GC的工作原理.如何优化GC的性能.如何与GC进行有限的交互,因为有一些应用程序对性能要求较高,例如嵌入式系统.实时系统等,只有全面提升内存的管理效率 ,才能提高整个应用程序的性能.本篇文章首先简单介绍GC的工作原理之后,然后再对GC的几个关键问题进行深入探讨,最后提出一些Java程序设计建议,从GC角度提高Java程序的性能.    GC的基本原理    Java的内存管理实际上就是对象的管理,其中包括对象的分配和释放.     对于程序员来说,分配对象使用ne

jvm系列(六):Java服务GC参数调优案例

本文介绍了一次生产环境的JVM GC相关参数的调优过程,通过参数的调整避免了GC卡顿对JAVA服务成功率的影响. 这段时间在整理jvm系列的文章,无意中发现本文,作者思路清晰通过步步分析最终解决问题.我个人特别喜欢这种实战类的内容,经原作者的授权同意,将文章分享于此.备注部分为本人添加,主要起到说明的作用. 原文出处:https://segmentfault.com/a/1190000005174819 背景以及遇到的问题 我们的Java HTTP服务属于OLTP类型,对成功率和响应时间的要求比

JVM的内存分配与垃圾回收策略

自动内存管理机制主要解决了两个问题: 给对象分配内存以及回收分配给对象的内存. 垃圾回收的区域 前面的笔记中整理过虚拟机运行数据区,再看一下这个区域: 注意在这个Runtime Data Area中: 程序计数器.Java栈.本地方法栈3个区域随线程而生,随线程而灭: 每一个栈帧中分配多少内存基本上在类结构确定下来的时候就已知, 因此这几个区域的内存分配和回收都具有确定性,不需过多考虑回收问题,方法结束或者线程结束时,内存自然就随之回收了. Java堆和方法区Method Area则不一样, 一

JVM 内部运行线程介绍

感谢同事[觉梦]投递此稿. hi,all 最近抽时间把JVM运行过程中产生的一些线程进行了整理,主要是围绕着我们系统jstack生成的文件为参照依据.  前段时间因为系统代码问题,造成性能瓶颈,于是就dump了一份stack出来进行分析.  stack 里面线程非常多,排查起来需要一定的经验,所以,对它们有一定了解,可以提高排查问题的效率.  现在网上资料也不是特别全,所以,导致很多新人在拿到一个stack文件之后,也不知知道从何看起. 下面我把这次整理的一些个人认为比较常见的线程列出来. 线程

JVM调优

在了解JVM调优之前,我们先了解下java的内存管理:http://blog.csdn.net/cymm_liu/article/details/7759696 基于Java的应用最大的问题莫过于出现Out Of Memory Error(内存溢出错误),通常出现OOME问题的应用都会有以下一些表现: l         Jvm crash l         性能奇差 l         Jvm似乎在不断的进行垃圾回收收集,这通常致使程序停止运行甚至服务崩溃   而且一旦出现这种情况,一般都需