一.gc日志查看与分析

  在sever端的run.xml中run和debug中加入如下参数:
  <jvmarg value="-XX:+PrintGCDateStamps"/>
        <jvmarg value="-XX:+PrintGCDetails"/>
   <jvmarg value="-Xloggc:./gclogs"/>
   启动server端后发现server文件夹下多了一个名为gclogs的文件。查看gclogs文件的内容如下:

--29T11::40.703+: 2.456: [Full GC (System) 2.456: [Tenured: 0K->3382K(174784K), 0.0546714 secs] 67363K->3382K(253440K), [Perm : 12488K->12488K(12544K)], 0.0547715 secs] [Times: user=0.06 sys=0.00, real=0.06 secs]
--29T11::48.671+: 10.422: [Full GC 10.422: [Tenured: 3382K->7703K(174784K), 0.0825413 secs] 53274K->7703K(253504K), [Perm : 16639K->16639K(16640K)], 0.0827269 secs] [Times: user=0.09 sys=0.00, real=0.09 secs]
--29T11::52.937+: 14.384: [Full GC 14.384: [Tenured: 7703K->8872K(174784K), 0.0812765 secs] 32672K->8872K(253568K), [Perm : 20735K->20735K(20736K)], 0.0813813 secs] [Times: user=0.08 sys=0.00, real=0.08 secs]
--29T11::53.656+: 130.211: [GC 130.211: [DefNew: 70080K->2097K(78784K), 0.0093047 secs] 78952K->10970K(253568K), 0.0095041 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
…..//全部都是GC
--29T12::53.015+: 3609.469: [Full GC (System) 3609.469: [Tenured: 10304K->9764K(174784K), 0.1250319 secs] 37316K->9764K(253568K), [Perm : 22686K->22551K(22784K)], 0.1251192 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]
--29T12::14.390+: 3810.844: [GC 3810.844: [DefNew: 70208K->1096K(78912K), 0.0057242 secs] 79972K->10861K(253696K), 0.0058007 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
…//全部都是GC
--29T13::53.140+: 7209.486: [Full GC (System) 7209.486: [Tenured: 9766K->10453K(174784K), 0.0993441 secs] 56183K->10453K(253696K), [Perm : 22560K->22560K(22784K)], 0.0994195 secs] [Times: user=0.09 sys=0.00, real=0.09 secs]
--29T13::15.390+: 7411.729: [GC 7411.729: [DefNew: 70208K->1058K(78912K), 0.0049616 secs] 80661K->11512K(253696K), 0.0050321 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
…//全部都是GC
--29T14::53.234+: 10809.475: [Full GC (System) 10809.475: [Tenured: 10468K->11261K(174784K), 0.1007012 secs] 61961K->11261K(253696K), [Perm : 22569K->22569K(22784K)], 0.1007760 secs] [Times: user=0.11 sys=0.00, real=0.11 secs]
--29T14::13.671+: 11009.908: [GC 11009.908: [DefNew: 70201K->1043K(78912K), 0.0050655 secs] 81462K->12304K(253696K), 0.0051476 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
Heap
def new generation total 78912K, used 66339K [0x02a60000, 0x07ff0000, 0x17fb0000)
eden space 70208K, % used [0x02a60000, 0x06a18d30, 0x06ef0000)
from space 8704K, % used [0x06ef0000, 0x07000188, 0x07770000)
to space 8704K, % used [0x07770000, 0x07770000, 0x07ff0000)
tenured generation total 174784K, used 11261K [0x17fb0000, 0x22a60000, 0x42a60000)
the space 174784K, % used [0x17fb0000, 0x18aaf4f0, 0x18aaf600, 0x22a60000)
compacting perm gen total 22784K, used 22591K [0x42a60000, 0x440a0000, 0x46a60000)
the space 22784K, % used [0x42a60000, 0x4406fe28, 0x44070000, 0x440a0000)
No shared spaces configured.

  最直观的信息是server端在启动的时候进行了3次Full GC,然后每一个小时左右会进行一次Full GC。

 
  如果希望得到更为详细的gc日志信息,可以在sever端的run.xml中run和debug中加入如下参数:  

  <jvmarg value="-XX:+PrintGCDateStamps"/>

<jvmarg value="-XX:+PrintGCDetails"/>

<jvmarg value="-Xloggc:./gclogs"/>

<jvmarg value="-XX:+PrintHeapAtGC"/>

和之前的参数相比,多了<jvmarg value="-XX:+PrintHeapAtGC"/>一行。启动server端后发现server文件夹下多了一个名为gclogs的文件。查看gclogs文件的内容如下,相比较之前的日志信息要详细了许多。  

{Heap before GC invocations= (full ):
def new generation total 78656K, used 69952K [0x02a60000, 0x07fb0000, 0x17fb0000)
eden space 69952K, % used [0x02a60000, 0x06eb0000, 0x06eb0000)
from space 8704K, % used [0x06eb0000, 0x06eb0000, 0x07730000)
to space 8704K, % used [0x07730000, 0x07730000, 0x07fb0000)
tenured generation total 174784K, used 0K [0x17fb0000, 0x22a60000, 0x42a60000)
the space 174784K, % used [0x17fb0000, 0x17fb0000, 0x17fb0200, 0x22a60000)
compacting perm gen total 12544K, used 12468K [0x42a60000, 0x436a0000, 0x46a60000)
the space 12544K, % used [0x42a60000, 0x4368d0e0, 0x4368d200, 0x436a0000)
No shared spaces configured.
--04T10::17.234+: 10.983: [GC 10.983: [DefNew: 69952K->3374K(78656K), 0.0179218 secs] 69952K->3374K(253440K), 0.0179821 secs] [Times: user=0.00 sys=0.00, real=0.02 secs]
Heap after GC invocations= (full ):
def new generation total 78656K, used 3374K [0x02a60000, 0x07fb0000, 0x17fb0000)
eden space 69952K, % used [0x02a60000, 0x02a60000, 0x06eb0000)
from space 8704K, % used [0x07730000, 0x07a7bbc8, 0x07fb0000)
to space 8704K, % used [0x06eb0000, 0x06eb0000, 0x07730000)
tenured generation total 174784K, used 0K [0x17fb0000, 0x22a60000, 0x42a60000)
the space 174784K, % used [0x17fb0000, 0x17fb0000, 0x17fb0200, 0x22a60000)
compacting perm gen total 12544K, used 12468K [0x42a60000, 0x436a0000, 0x46a60000)
the space 12544K, % used [0x42a60000, 0x4368d0e0, 0x4368d200, 0x436a0000)
No shared spaces configured.

  上面所述的gc日志文件是覆盖型的,重新启动一次JVM,新的文件将会覆盖旧的文件。

  

  分析日志之前,先大概复习一下Java的内存模型。

  Java堆内存的分代如下图:

  

  • young区域就是新生代,存放新创建对象;
  • tenured是年老代,存放在新生代经历多次垃圾回收后仍存活的对象,年老区又分为from和to两部分;
  • perm是永生代,存放类定义信息、元数据等信息。

  当GC发生在新生代时,称为Minor GC,次收集;当GC发生在年老代时,称为Major GC。一般的,Minor GC的发生频率要比Major GC高很多。

  GC和Full GC是垃圾回收的停顿类型,而不是区分是新生代还是年老代,如果有 Full 说明发生了Stop-The-World 。如果是调用 System.gc() 触发的,那么将显示的是 [Full GC (System)] 。上面的gc日志文件中一小时出现了一次[Full GC (System)],可能是显示地调用了System.gc(),或者是RMI应用所导致的。

  

  下面来分析gc日志中的内容:

  2015-04-29T11:17:40.703+0800: 2.456: [Full GC (System) 2.456: [Tenured: 0K->3382K(174784K), 0.0546714 secs] 67363K->3382K(253440K), [Perm : 12488K->12488K(12544K)], 0.0547715 secs] [Times: user=0.06 sys=0.00, real=0.06 secs]

  Full GC针对的是新生代、年老代和永生代。可以看到由于部分类从新生代进入到了年老代,Tenured所占内存反而会增大,永生代的变化也不会太大。整个堆大小的变化67363K->3382K(253440K)主要是发生在新生代。

  2015-04-29T12:21:14.390+0800: 3810.844: [GC 3810.844: [DefNew: 70208K->1096K(78912K), 0.0057242 secs] 79972K->10861K(253696K), 0.0058007 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

  普通GC回收的是新生代,由70208K变为了1096K,减少了69112k。整个堆的大小由79972K变味了10861K,减少了69111k。也就更说明了普通的GC发生在新生代上。

  应用进行一次GC,新生代可以一般可以回收70%~95%的空间,而永久代的GC效率远小于此。所以新生代和永生代采用了截然不同的内存回收算法。

  永生代的回收主要体现在无用类信息的卸载,在大量使用反射、动态代理、CGLib等bytecode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要JVM具备类卸载的支持以保证永久代不会溢出,使用-XX:+ClassUnloading参数将允许JVM卸载无用的类信息。

 二.常用的垃圾回收算法

  标记-清除算法(Mark-Sweep)

  最基础的搜集算法是“标记-清除算法”(Mark-Sweep)。

  如它的名字一样,算法分成“标记”和“清除”两个阶段,首先标记出所有需要回收的对象,然后回收所有需要回收的对象。说它是最基础的收集算法原因是后续的收集算法都是基于这种思路并优化其缺点得到的。

  它的主要缺点有两个,一是效率问题,标记和清理两个过程效率都不高,二是空间问题,标记清理之后会产生大量不连续的内存碎片,空间碎片太多可能会导致后续使用中无法找到足够的连续内存而提前触发另一次的垃圾搜集动作。  

  复制(Copying)

  为了解决效率问题,一种称为“复制”(Copying)的搜集算法出现。

  它将可用内存划分为两块,每次只使用其中的一块,当半区内存用完了,仅将还存活的对象复制到另外一块上面,然后就把原来整块内存空间一次清理掉。这样使得每次内存回收都是对整个半区的回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存就可以了,实现简单,运行高效。只是这种算法的代价是将内存缩小为原来的一半,未免太高了一点。

  现在的商业虚拟机中都是用了这一种收集算法来回收新生代,IBM有专门研究表明新生代中的对象98%是朝生夕死的,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块较大的eden空间和2块较少的survivor空间,每次使用eden和其中一块survivor,当回收时将eden和 survivor还存活的对象一次过拷贝到另外一块survivor空间上,然后清理掉eden和用过的survivor。

  Sun Hotspot虚拟机默认eden和survivor的大小比例是8:1,也就是每次只有10%的内存是“浪费”的。当然,98%的对象可回收只是一般场景下的数据,我们没有办法保证每次回收都只有10%以内的对象存活,当survivor空间不够用时,需要依赖其他内存(譬如老年代)进行分配担保(Handle Promotion)。

  复制收集算法在对象存活率高的时候,效率有所下降。更关键的是,如果不想浪费50%的空间,就需要有额外的空间进行分配担保用于应付半区内存中所有对象100%存活的极端情况,

  标记-整理(Mark-Compact)  

  在老年代一般不能直接选用复制算法,人们提出另外一种“标记-整理”(Mark-Compact)算法。

  标记过程仍然一样,但后续步骤不是进行直接清理,而是令所有存活的对象一端移动,然后直接清理掉这端边界以外的内存。

 三.垃圾收集器

  下面关于收集器的描述都是基于Sun Hotspot虚拟机1.6版。

    

  两个收集器之间存在连线的话就说明它们可以搭配使用。在介绍着些收集器之前,我们先明确一个观点:没有最好的收集器,也没有万能的收集器,只有最合适的收集器。  

  Serial收集器

  单线程收集器,收集时会暂停所有工作线程(我们将这件事情称之为Stop The World,下称STW),使用复制收集算法,是虚拟机运行在Client模式时的默认新生代收集器。 

  ParNew收集器

  ParNew收集器就是Serial的多线程版本,除了使用多条收集线程外,其余行为包括算法、STW、对象分配规则、回收策略等都与Serial收集器一摸一样。在单CPU的环境中,ParNew收集器并不会比Serial收集器有更好的效果。 

  Parallel Scavenge收集器 

  Parallel Scavenge收集器(下称PS收集器)也是一个多线程收集器,也是使用复制算法,是虚拟机运行在Server模式的默认新生代收集器。但它的对象分配规则与回收策略都与ParNew收集器有所不同,它是以吞吐量最大化(即GC时间占总运行时间最小)为目标的收集器实现,它允许较长时间的STW换取总吞吐量最大化。 

  Serial Old收集器

  Serial Old是单线程收集器,使用标记-整理算法,是老年代的默认的收集器。  

  Parallel Old收集器

  老年代版本吞吐量优先收集器,使用多线程和标记-整理算法,JVM 1.6提供,在此之前,新生代使用了PS收集器的话,老年代除Serial Old外别无选择,因为PS无法与CMS收集器配合工作。

  CMS(Concurrent Mark Sweep)收集器

  CMS是一种以最短停顿时间为目标的收集器,使用CMS并不能达到GC效率最高(总体GC时间最小),但它能尽可能降低GC时服务的停顿时间,这一点对于实时或者高交互性应用(譬如证券交易)来说至关重要,这类应用对于长时间STW一般是不可容忍的。CMS收集器使用的是标记-清除算法,也就是说它在运行期间会产生空间碎片,所以虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。

  四.JVM参数设置

JVM学习(一)的更多相关文章

  1. JVM学习(4)——全面总结Java的GC算法和回收机制

    俗话说,自己写的代码,6个月后也是别人的代码……复习!复习!复习!涉及到的知识点总结如下: 一些JVM的跟踪参数的设置 Java堆的分配参数 -Xmx 和 –Xms 应该保持一个什么关系,可以让系统的 ...

  2. JVM学习(3)——总结Java内存模型

    俗话说,自己写的代码,6个月后也是别人的代码……复习!复习!复习!涉及到的知识点总结如下: 为什么学习Java的内存模式 缓存一致性问题 什么是内存模型 JMM(Java Memory Model)简 ...

  3. Java虚拟机JVM学习07 类的卸载机制

    Java虚拟机JVM学习07 类的卸载机制 类的生命周期 当Sample类被加载.连接和初始化后,它的生命周期就开始了. 当代表Sample类的Class对象不再被引用,即不可触及时,Class对象就 ...

  4. Java虚拟机JVM学习06 自定义类加载器 父委托机制和命名空间的再讨论

    Java虚拟机JVM学习06 自定义类加载器 父委托机制和命名空间的再讨论 创建用户自定义的类加载器 要创建用户自定义的类加载器,只需要扩展java.lang.ClassLoader类,然后覆盖它的f ...

  5. Java虚拟机JVM学习05 类加载器的父委托机制

    Java虚拟机JVM学习05 类加载器的父委托机制 类加载器 类加载器用来把类加载到Java虚拟机中. 类加载器的类型 有两种类型的类加载器: 1.JVM自带的加载器: 根类加载器(Bootstrap ...

  6. Java虚拟机JVM学习04 类的初始化

    Java虚拟机JVM学习04 类的初始化 类的初始化 在初始化阶段,Java虚拟机执行类的初始化语句,为类的静态变量赋予初始值. 在程序中,静态变量的初始化有两种途径: 1.在静态变量的声明处进行初始 ...

  7. Java虚拟机JVM学习03 连接过程:验证、准备、解析

    Java虚拟机JVM学习03 连接过程:验证.准备.解析 类被加载后,就进入连接阶段. 连接就是将已经读入到内存的类的二进制数据合并到虚拟机的运行时环境中去. 连接阶段三个步骤:验证.准备和解析. 类 ...

  8. Java虚拟机JVM学习02 类的加载概述

    Java虚拟机JVM学习02 类的加载概述 类的加载 类的加载指的是将类的.class文件中的二进制数据读入到内存中,将其放在运行时数据区的方法区内,然后在堆区创建一个java.lang.Class对 ...

  9. Java虚拟机JVM学习01 流程概述

    Java虚拟机JVM学习01 流程概述 Java虚拟机与程序的生命周期 一个运行时的Java虚拟机(JVM)负责运行一个Java程序. 当启动一个Java程序时,一个虚拟机实例诞生:当程序关闭退出,这 ...

  10. JVM学习笔记:虚拟机的类加载机制

    JVM类加载机制分两部分来总结: (1)类加载过程 (2)类加载器 一.JVM类加载过程 类的加载过程:加载 →连接(验证 → 准备 → 解析)→ 初始化. 类的生命周期:加载 →连接(验证 → 准备 ...

随机推荐

  1. HDU6235-Permutation-水题-2017中国大学生程序设计竞赛-哈尔滨站-重现赛

    Permutation Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 262144/262144 K (Java/Others)Tot ...

  2. Centos/Rhel7部署Zabbix监控(部署篇之服务器篇)

    Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案. Zabbix能监视各种网络参数,保证服务器系统的安全运营:并提供灵活的通知机制以让系统管理员快速定位/解决 ...

  3. c#简单操作MongoDB_2.4

    一.MongoDB的安装 MongoDb在windows下的安装与以auth方式启用服务 二.下载驱动 使用nuget搜索“mongodb”,下载“MongoDB.Driver”(这是官方推荐的一个驱 ...

  4. css3中的关键帧技术分析应用

    最近在研究网页加载进度效果的时候发现可以使用css3实现这个效果. 使用css3实现完全不需要图片,相比使用loading.gif的实现来说可能更快. 使用css3实现动态加载的效果,主要会涉及到几个 ...

  5. lnmp一键安装的卸载

    http://blog.csdn.net/lansetiankong12/article/details/48130507  如果是lnmp一键安装的 进入安装包目录 [root@www home]# ...

  6. 如何控制input框!

    ENTER键可以让光标移到下一个输入框  只能是中文   屏蔽输入法   只能输入英文和数字   只能是数字 只能显示,不能修改 只能输数字,判断按键的值 function   onlyNum() { ...

  7. ProtoBuf 与 gRPC

    用 Protobuf 很久了,但是一直觉得很简单,所以就没有做一个总结,今天想尝试一下 gRPC,顺带就一起总结一下.ProtoBuf 是个老同志了,应该是 2010 的时候发布的,然后被广泛使用,目 ...

  8. SpringMVC图片上传与显示

    @RestController @Scope("prototype") @RequestMapping("/xxxx/xxx/main") public cla ...

  9. JavaScript总结学习一:js中构造函数与普通函数的区别

    构造函数不仅只出现在JavaScript中,它同样存在于很多主流的程序语言里,比如c++.Java.PHP等等.与这些主流程序语言一样,构造函数在js中的作业一样,也是用来创建对象时初始化对象,并且总 ...

  10. 开地址哈希表(Hash Table)的原理描述与冲突解决

    在开地址哈希表中,元素存放在表本身中.这对于某些依赖固定大小表的应用来说非常有用.因为不像链式哈希表在每个槽位上有一个"桶"来存储冲突的元素,所以开地址哈希表需要通过另一种方法来解 ...