jvm总结

haoningabc

浏览: 1476482 次
性别:
来自: 北京

最近访客更多访客>>

zfyq124

bartontang

dlzdy

cnnlush0605

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

java

jvm

分代
年轻代:

所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代分三个区。一个Eden区，两个Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

老年代:

在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到老年代中。因此，可以认为老年代中存放的都是一些生命周期较长的对象。

持久代:

用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设置。

何时GC
由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC(Monitor GC)和Full GC。

Scavenge GC

一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

Full GC

对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：

Java 工具

jstat

jstat -gcutil [pid] [internal]

监视VM内存内的各种堆和非堆的大小及其内存使用量
[pid]: java进程id
[internal]: 打印内存使用量间隔, 单位毫秒

[@hostname ~]# jstat -gcutil 22792 1000
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 11.10   0.00   9.01   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  13.78   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  14.20   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  15.64   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  16.91   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  18.26   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  18.28   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  19.20   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  20.14   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  20.20   3.33  99.98     96    1.045     1    0.094    1.138
 11.10   0.00  21.36   3.33  99.98     96    1.045     1    0.094    1.138

S0: Survivor space 0 区已使用空间的百分比
S1: Survivor space 1 区已使用空间的百分比
E: Eden space 区已使用空间的百分比
O: Old space 区已使用空间的百分比
P: Perm space 区已使用空间的百分比
YGC: Young GC 的次数
YGCT: Young GC 所用的时间单位秒
FGC: Full GC 的次数
FGCT: Full GC 所用的时间单位秒
GCT: 用于垃圾回收的总时间单位秒
jmap

jmap -heap [pid]
查看java进程VM已分配空间及使用情况
[pid]: java进程id
[@zjm_106_154 ~]# jmap -heap 22792     
Attaching to process ID 22792, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 19.0-b09

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40                            # 对应jvm启动参数 -XX:MinHeapFreeRatio 设置JVM堆最小空闲比率 (默认40)
   MaxHeapFreeRatio = 70                            # 对应jvm启动参数 -XX:MaxHeapFreeRatio 设置JVM堆最大空闲比率 (默认70)
   MaxHeapSize      = 10737418240 (10240.0MB)       # 对应jvm启动参数 -XX:MaxHeapSize 设置JVM堆的最大大小
   NewSize          = 5368709120 (5120.0MB)         # 对应jvm启动参数 -XX:NewSize 设置JVM堆的年轻代的默认大小
   MaxNewSize       = 5368709120 (5120.0MB)         # 对应jvm启动参数 -XX:MaxNewSize 设置JVM堆的年轻带的最大大小
   OldSize          = 5439488 (5.1875MB)            # 对应jvm启动参数 -XX:OldSize 设置JVM堆的老年代的大小
   NewRatio         = 2                             # 对应jvm启动参数 -XX:NewRatio 老年代与年轻代的大小比率 
   SurvivorRatio    = 8                             # 对应jvm启动参数 -XX:SurvivorRatio 设置年轻代中Eden区与Survivor区的大小比值 
   PermSize         = 21757952 (20.75MB)            # 对应jvm启动参数 -XX:PermSize 设置JVM堆的持久带的初始大小
   MaxPermSize      = 1073741824 (1024.0MB)         # 对应jvm启动参数 -XX:MaxPermSize 设置JVM堆的永生代的最大大小

Heap Usage:
PS Young Generation
Eden Space:                                         # Eden区内存分布 总量 已使用 空闲 使用比率
   capacity = 5357305856 (5109.125MB)
   used     = 1647437208 (1571.118553161621MB)
   free     = 3709868648 (3538.006446838379MB)
   30.751225565270396% used
From Space:                                         # 其中一个Survivor区内存分布 总量 已使用 空闲 使用比率
   capacity = 5898240 (5.625MB)
   used     = 2375696 (2.2656402587890625MB)
   free     = 3522544 (3.3593597412109375MB)
   40.278049045138886% used
To Space:                                           # 另一个Survivor区内存分布 总量 已使用 空闲 使用比率
   capacity = 5505024 (5.25MB)
   used     = 0 (0.0MB)
   free     = 5505024 (5.25MB)
   0.0% used
PS Old Generation                                   # 当前老年代内存分布 总量 已使用 空闲 使用比率
   capacity = 5368709120 (5120.0MB)
   used     = 181392168 (172.98905181884766MB)
   free     = 5187316952 (4947.010948181152MB)
   3.3786924183368683% used
PS Perm Generation                                  # 当前持久代内存分布 总量 已使用 空闲 使用比率
   capacity = 72286208 (68.9375MB)
   used     = 72213176 (68.86785125732422MB)
   free     = 73032 (0.06964874267578125MB)
   99.89896827898346% used

VisualVM

remote jvm args
无认证连接（适合测试环境）

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

密码认证连接（用于生产环境）需配置连接用户和权限（[jre]/lib/management/jmxremote.access & jmxremote.password文件）参考 http://download.oracle.com/javase/1.5.0/docs/guide/management/agent.html

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=/usr/local/jdk/jre/lib/management/jmxremote.password

远程主机上启动jstatd进程

jstatd -J-Djava.security.policy=permissions.txt
permissions.txt内容
grant {
  permission java.security.AllPermission;
};

VisualVM里添加远程主机，并为其添加JMX连接和jstatd连接

调优总结

尽量减少Full GC的次数, 因为Full GC的消耗要比Monitor GC要大
年轻代大小: 尽可能设大, 降低年轻代GC次数, 同时也减少达到老年代的对象
分配堆栈的最小值最好等于最大值, 因为动态分配也是需要耗费时间的. 如年轻代, 老年代, 持久代的最小最大值可设为一致
参考

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html