java GC笔记

以hbase为例：在hbase的配置文件路径下，设置了GC log输出路径/app/hbase-config/hbase-env.sh

export HBASE_OPTS="-Xmx16384m -Xms16384m -Xmn8192m -XX:PermSize=160M -XX:MaxPermSize=160M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3  -XX:+CMSParallelRemarkEnabled -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:PrintFLSStatistics=1 -Xloggc:/app/hbase/logs/hbase_gc.log $HBASE_OPTS"

可以查询到log的相关信息

#jstat -gccause 79751 1000 1000 //获取GC相关指标，表示每1000毫秒查询一次79751垃圾收集状况。
Usage: jstat -help|-options
?????? jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]
?参数解释：
Options — 选项，我们一般使用 -gcutil 查看gc情况
vmid??? — VM的进程号，即当前运行的java进程号
interval– 间隔时间，单位为秒或者毫秒
count?? — 打印次数，如果缺省则打印无数次

    S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC
  0.00   8.98  11.16  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  12.79  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  14.94  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  16.04  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  17.98  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  20.34  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  21.83  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC
  0.00   8.98  22.64  69.83  12.33    156   50.788    16  280.103  330.891 unknown GCCause      No GC

E列代表
O E-->O 新生代转移到老代，Ｏ积累到80%就会触发full gc

具体意思如下：
E（表示，Eden），代表这台服务器的新生代Eden区使用了11.16的空间，
S0 S1 两个Survivor区(S0,S1表示Survivor0、Survivor1),Survivor0里面是空的，Survivor1占了8.98%

老年代（O，表示old) 和永久带（P，表示Permanent）分别使用了69.83% 和12.33%的空间。
程序运行以来共发生Minor GC(YGC ,表示young gc)156次，总耗时50.788秒；
发生Fulle GC （FGC，表示full GC ）16次，full GC总耗时（FGCT，表示full gc time）为330.891秒，总的GC总耗时（GCT，表示GC Time）为330.891秒
LGCC Cause of last Garbage Collection.
GCC Cause of current Garbage Collection.

Java 6 JDK输出如下：
[[email protected] logs]$ jmap -heap 29877

Attaching to process ID 29877, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.45-b01

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 21474836480 (20480.0MB)
   NewSize          = 4294967296 (4096.0MB)
   MaxNewSize       = 4294967296 (4096.0MB)
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 67108864 (64.0MB)
   MaxPermSize      = 67108864 (64.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 3865509888 (3686.4375MB)
   used     = 481048576 (458.763671875MB)
   free     = 3384461312 (3227.673828125MB)
   12.444634470949257% used
Eden Space:
   capacity = 3436052480 (3276.875MB)
   used     = 481048576 (458.763671875MB)
   free     = 2955003904 (2818.111328125MB)
   14.00003576196834% used
From Space:
   capacity = 429457408 (409.5625MB)
   used     = 0 (0.0MB)
   free     = 429457408 (409.5625MB)
   0.0% used
To Space:
   capacity = 429457408 (409.5625MB)
   used     = 0 (0.0MB)
   free     = 429457408 (409.5625MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 12884901888 (12288.0MB)
   used     = 0 (0.0MB)
   free     = 12884901888 (12288.0MB)
   0.0% used
Perm Generation:
   capacity = 67108864 (64.0MB)
   used     = 21153816 (20.173851013183594MB)
   free     = 45955048 (43.826148986816406MB)
   31.521642208099365% used
  • Eden from to 3个加起来为Young 区

[[email protected] ~]$ jps
10424 Jps
8229 HRegionServer

[[email protected] ~]$ jmap -heap 8229
Attaching to process ID 8229, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01

using thread-local object allocation.
Garbage-First (G1) GC with 6 thread(s)

Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 25769803776 (24576.0MB)
NewSize = 1363144 (1.2999954223632812MB)
MaxNewSize = 17592186044415 MB
OldSize = 5452592 (5.1999969482421875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 16777216 (16.0MB)
MaxPermSize = 83886080 (80.0MB)
G1HeapRegionSize = 8388608 (8.0MB)

Heap Usage:
G1 Heap:
regions = 3072
capacity = 25769803776 (24576.0MB)
used = 20409483264 (19464.0MB)
free = 5360320512 (5112.0MB)
79.19921875% used
G1 Young Generation:
Eden Space:
regions = 89
capacity = 1182793728 (1128.0MB)
used = 746586112 (712.0MB)
free = 436207616 (416.0MB)
63.12056737588652% used
Survivor Space:
regions = 20
capacity = 167772160 (160.0MB)
used = 167772160 (160.0MB)
free = 0 (0.0MB)
100.0% used
G1 Old Generation:
regions = 2324
capacity = 24419237888 (23288.0MB)
used = 19495124992 (18592.0MB)
free = 4924112896 (4696.0MB)
79.83510821023704% used
Perm Generation:
capacity = 50331648 (48.0MB)
used = 42303832 (40.344078063964844MB)
free = 8027816 (7.655921936035156MB)
84.05016263326009% used

G1 GC笔记：

关于最大gc停顿时间
在做minor gc和mixed gc时，收集器会在内存中维系一个remembered set，这个set包含了heap中所有对象的引用，用以确定哪些可以被回收。
每次gc时，g1会通过一个预测模型来计算每个region进行回收的时间，从而从中选出停顿时间在MaxGCPauseMillis之内的region进行垃圾回收
?

关于mixed gc

mixed gc是一种既回收young区，也回收old区的垃圾回收方式，它触发的条件是-XX:InitiatingHeapOccupancyPercent，mixed gc的目的就是为了延迟full gc的产生

同理YGC指的是回收young的垃圾回收方式

Full GC 指的是回收Old去的垃圾回收方式，因为old区比较大，导致GC时间比较长，并且在GC期间java进程停止对外相应，并且自身也不对外响应，导致regionserver无法向zookeeper注册心跳信息，超过zookeeper （ <name>zookeeper.session.timeout</name>） session时间，就会被zookeeper置为dead。

Hbase G1参数调整：

待修改的参数，修改GC的参数需要重启集群，安排在下次重启。

-XX:ConcGCThreads=12并发标记的执行线程数 =================== 测试数据ConcGCThreads 不能大于-XX:ParallelGCThreads，否则会报错
-XX:InitiatingHeapOccupancyPercent=60? 堆占用了多少的时候就触发GC，默认为45
-XX:ParallelGCThreads=12 30

[[email protected] ~]$ jstat -gccapacity 61540
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
0.0 52428800.0 2490368.0 0.0 294912.0 2195456.0 0.0 52428800.0 44695552.0 44695552.0 16384.0 81920.0 49152.0 49152.0 2 0

GC 常见命令：

[[email protected] 0321 ~]$ jmap -heap 61540

Attaching to process ID 61540, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.71-b01

using thread-local object allocation.
Garbage-First (G1) GC with 30 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 53687091200 (51200.0MB)
   NewSize          = 1363144 (1.2999954223632812MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5452592 (5.1999969482421875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 16777216 (16.0MB)
   MaxPermSize      = 83886080 (80.0MB)
   G1HeapRegionSize = 16777216 (16.0MB)

Heap Usage:
G1 Heap:
   regions  = 2880
   capacity = 48318382080 (46080.0MB)
   used     = 2519304864 (2402.5963439941406MB)
   free     = 45799077216 (43677.40365600586MB)
   5.213967760403951% used
G1 Young Generation:
Eden Space:
   regions  = 7
   capacity = 2248146944 (2144.0MB)
   used     = 117440512 (112.0MB)
   free     = 2130706432 (2032.0MB)
   5.223880597014926% used
Survivor Space:
   regions  = 18
   capacity = 301989888 (288.0MB)
   used     = 301989888 (288.0MB)
   free     = 0 (0.0MB)
   100.0% used
G1 Old Generation:
   regions  = 126
   capacity = 45768245248 (43648.0MB)
   used     = 2099874464 (2002.5963439941406MB)
   free     = 43668370784 (41645.40365600586MB)
   4.588059805705051% used
Perm Generation:
   capacity = 50331648 (48.0MB)
   used     = 42610464 (40.636505126953125MB)
   free     = 7721184 (7.363494873046875MB)
   84.65938568115234% used

13018 interned Strings occupying 1388240 bytes.

[[email protected] ~]$ jstat -gccause -h 10 61540 1000 1000

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC
  0.00 100.00  92.54  20.26  85.06     16    1.794     0    0.000    1.794 G1 Evacuation Pause  No GC
  0.00 100.00  92.54  20.26  85.06     16    1.794     0    0.000    1.794 G1 Evacuation Pause  No GC
  0.00 100.00  92.54  20.26  85.06     16    1.794     0    0.000    1.794 G1 Evacuation Pause  No GC
  0.00 100.00  93.28  20.26  85.06     16    1.794     0    0.000    1.794 G1 Evacuation Pause  No GC
  0.00 100.00  93.28  20.26  85.06     16    1.794     0    0.000    1.794 G1 Evacuation Pause  No GC
  0.00 100.00  93.28  20.26  85.06     16    1.794     0    0.000    1.794 G1 Evacuation Pause  No GC
  0.00 100.00   1.42  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   1.42  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   3.55  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT    LGCC                 GCC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC
  0.00 100.00   4.26  21.24  85.06     17    1.877     0    0.000    1.877 G1 Evacuation Pause  No GC

#jstat -gcutil 27912 1s 50

原文地址：http://blog.51cto.com/lmjshe/2065404

时间： 2024-11-13 10:04:27

java GC笔记的相关文章

Java GC回收机制

优秀Java程序员必须了解的GC工作原理 一个优秀的Java程序员必须了解GC的工作原理.如何优化GC的性能.如何与GC进行有限的交互,因为有一些应用程序对性能要求较高,例如嵌入式系统.实时系统等,只有全面提升内存的管理效率 ,才能提高整个应用程序的性能. 一个优秀的Java程序员必须了解GC的工作原理.如何优化GC的性能.如何与GC进行有限的交互,因为有一些应用程序对性能要求较高,例如嵌入式系统.实时系统等,只有全面提升内存的管理效率 ,才能提高整个应用程序的性能.本篇文章首先简单介绍GC的工

Java系列笔记(6) - 并发（上）

目录 1,基本概念 2,volatile 3,atom 4,ThreadLocal 5,CountDownLatch和CyclicBarrier 6,信号量 7,Condition 8,Exchanger 在Java中,JVM.并发.容器.IO/NIO是我认为最重要的知识点,本章将介绍其中的并发,这也是从“会Java”到精通Java所必须经历的一步.本章承接上一张<Java系列笔记(5) - 线程>,其中介绍了Java线程的相关知识,是本章介绍内容的基础,如果对于线程不熟悉的,可以先阅读以下这

Java系列笔记 - JVM监控与调优

光说不练假把式,学习Java GC机制的目的是为了实用,也就是为了在JVM出现问题时分析原因并解决之.通过学习,我觉得JVM监控与调优主要的着眼点在于如何配置.如何监控.如何优化3点上.下面就将针对这3点进行学习. (如果您对Java的内存区域划分和内存回收机制尚不明确,那在阅读本文前,请先阅读我的前一篇博客<Java系列笔记(3) - Java 内存区域和GC机制>,在该博客中,详细叙述了Java HotSpot虚拟机(Sun/Oracle JDK系列默认的虚拟机)的内存分配和垃圾回收机制.

Java系列笔记 - 线程

1,线程原理和概念 当代操作系统,大多数都支持多任务处理.对于多任务的处理,有两个常见的概念:进程和线程.      进程是操作系统分配资源的单位,这里的资源包括CPU.内存.IO.磁盘等等设备,进程之间切换时,操作系统需要分配和回收这些资源,所以其开销相对较大(远大于线程切换):      线程是CPU分配时间的单位,理论上,每个进程至少包含一个线程,每个线程都寄托在一个进程中.一个线程相当于是一个进程在内存中的某个代码段,多个线程在切换时,CPU会根据其优先级和相互关系分配时间片.除时间切换

Java GC（垃圾回收）机制知识总结

目录 Java GC系列 Java系列笔记(3) - Java 内存区域和GC机制 面试题:"你能不能谈谈,java GC是在什么时候,对什么东西,做了什么事情?" Java GC系列 本部分来自Java GC系列(1):Java垃圾回收简介 Java的内存分配与回收全部由JVM垃圾回收进程自动完成.与C语言不同,Java开发者不需要自己编写代码实现垃圾回收.这是Java深受大家欢迎的众多特性之一,能够帮助程序员更好地编写Java程序. 下面四篇教程是了解Java 垃圾回收(GC)的基

Java系列笔记(1) - Java 类加载与初始化

目录 类加载器 动态加载 链接 初始化 示例 类加载器 在了解Java的机制之前,需要先了解类在JVM(Java虚拟机)中是如何加载的,这对后面理解java其它机制将有重要作用. 每个类编译后产生一个Class对象,存储在.class文件中,JVM使用类加载器(Class Loader)来加载类的字节码文件(.class),类加载器实质上是一条类加载器链,一般的,我们只会用到一个原生的类加载器,它只加载Java API等可信类,通常只是在本地磁盘中加载,这些类一般就够我们使用了.如果我们需要从远

jvm系列:Java GC 分析

Java GC就是JVM记录仪,书画了JVM各个分区的表演. 什么是 Java GC Java GC(Garbage Collection,垃圾收集,垃圾回收)机制,是Java与C++/C的主要区别之一,作为Java开发者,一般不需要专门编写内存回收和垃圾清理代码,对内存泄露和溢出的问题,也不需要像C程序员那样战战兢兢.这是因为在Java虚拟机中,存在自动内存管理和垃圾清扫机制.概括地说,该机制对JVM(Java Virtual Machine)中的内存进行标记,并确定哪些内存需要回收,根据一定

Java学习笔记3-操作符

Java基本操作符:+.-.*./.%.=.==.!=.+=.-=. 优先级:先乘除后加减,如果是连接符+号会优先往前匹配,比如 a+++++b,会被解释称 a++ ++ +b,所以会报错,需要自行使用括号隔离为 (a++) + (++b). 对象的引用如果赋值给了对象的引用后,2 个对象将指向同一个引用,有一个对象的引用重新赋值后将同时影响到另一个对象,比如 ClassName classA = new ClassName(); ClassName classB = new ClassName

［Java基础笔记］数组

Java基础笔记 定义数组: int[] numbers = new int[100]; //方法一 double[] num = new double[10]; int[][] a = new int[2][5]; 通过new创建的数组,元素默认值为0(0.0) int[] scores = {5,4,33,12,46}; //方法二 int[][] a = { //位数不足,自动补0 {5,3,2,1,6}, {10,12,14,15}, }; 数组特性:存储的都是同类型数据:长度定义后不可