JVM 1.6 GC
2016-05-22 15:16
387 查看
JVM调优是一门艺术。
JVM调优的重点是减少Major GC的次数,因为Major GC会暂停程序比较长的时间。如果Major GC的次数比较多,意味着应用程序的JVM内存参数需要调整。
2 大对象直接进入年老代
jstat -gcutil [pid] 1000 每隔1s输出java进程的gc情况
输入示例:
表示发生一次minor GC,ParNew是新生代的gc算法,11450951K表示eden区的存活对象的内存总和,1014116K表示回收后的存活对象的内存总和,11673600K是整个eden区的内存总和。0.8699520 secs表示minor gc花费的时间。
27569972K表示整个heap区的存活对象总和,17943420K表示回收后整个heap区的存活对象总和,37614976K表示整个heap区的内存总和。
表示发生了一次Full GC,整个JVM都停顿了180多秒,输出说明同上。只是Tenured: 27569972K->16569972K(27569972K)表示的是old区,而上面是eden区。
-XX:NewRatio
设置Young与Old的大小比例,-server时默认为1:2,如果太小,会使大对象直接分配到old去,增大major collections的执行次数。
-XX:SurvivorRatio
设置Eden与Survivor的比例,默认为8:1,Survivio大了会浪费,如果小了的话,会使一些大对象在做minor gc时,直接从eden区到达old区,让old区的gc频繁,这个参数保持默认就好了,一般情况下,对性能影响不大。
随便写个代码oom下,就都了解了。
强引用,不进行垃圾回收。
软引用,在内存紧张的时候回收。
弱引用,只能生存到下次垃圾收集时候。
虚引用,垃圾收集时候会收到系统通知。
JVM调优的重点是减少Major GC的次数,因为Major GC会暂停程序比较长的时间。如果Major GC的次数比较多,意味着应用程序的JVM内存参数需要调整。
JVM内存分配策略
1 对象优先分配在Eden区2 大对象直接进入年老代
如何监视GC
1.概览监视gc。
jmap -heap [pid] 查看内存分布jstat -gcutil [pid] 1000 每隔1s输出java进程的gc情况
2.详细监视gc。
在jvm启动参数,加入-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:./gc.log。输入示例:
[GC [ParNew: 11450951K->1014116K(11673600K), 0.8698830 secs] 27569972K->17943420K(37614976K), 0.8699520 secs] [Times: user=11.28 sys=0.82, real=0.86 secs]
表示发生一次minor GC,ParNew是新生代的gc算法,11450951K表示eden区的存活对象的内存总和,1014116K表示回收后的存活对象的内存总和,11673600K是整个eden区的内存总和。0.8699520 secs表示minor gc花费的时间。
27569972K表示整个heap区的存活对象总和,17943420K表示回收后整个heap区的存活对象总和,37614976K表示整个heap区的内存总和。
[Full GC [Tenured: 27569972K->16569972K(27569972K), 180.2368177 secs] 36614976K->27569972K(37614976K), [Perm : 28671K->28635K(28672K)], 0.2371537 secs]
表示发生了一次Full GC,整个JVM都停顿了180多秒,输出说明同上。只是Tenured: 27569972K->16569972K(27569972K)表示的是old区,而上面是eden区。
-XX:NewRatio
设置Young与Old的大小比例,-server时默认为1:2,如果太小,会使大对象直接分配到old去,增大major collections的执行次数。
-XX:SurvivorRatio
设置Eden与Survivor的比例,默认为8:1,Survivio大了会浪费,如果小了的话,会使一些大对象在做minor gc时,直接从eden区到达old区,让old区的gc频繁,这个参数保持默认就好了,一般情况下,对性能影响不大。
随便写个代码oom下,就都了解了。
Java HotSpot(TM) Client VM (25.45-b02) for windows-x86 JRE (1.8.0_45-b14), built on Apr 10 2015 10:46:40 by "java_re" with MS VC++ 10.0 (VS2010) Memory: 4k page, physical 8294668k(3869072k free), swap 9605388k(1961212k free) CommandLine flags: -XX:InitialHeapSize=16777216 -XX:MaxHeapSize=62914560 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:-UseLargePagesIndividualAllocation 0.157: [GC (Allocation Failure) 0.157: [DefNew: 1431K->512K(4928K), 0.0023910 secs]0.159: [Tenured: 176K->687K(10944K), 0.0024891 secs] 1431K->687K(15872K), [Metaspace: 118K->118K(4480K)], 0.0051050 secs] [Times: user=0.03 sys=0.00, real=0.00 secs] 0.162: [Full GC (Allocation Failure) 0.162: [Tenured: 687K->666K(40960K), 0.0023773 secs] 687K->666K(45952K), [Metaspace: 118K->118K(4480K)], 0.0026923 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Heap def new generation total 18432K, used 765K [0x04e00000, 0x06200000, 0x06200000) eden space 16384K, 4% used [0x04e00000, 0x04ebf450, 0x05e00000) from space 2048K, 0% used [0x05e00000, 0x05e00000, 0x06000000) to space 2048K, 0% used [0x06000000, 0x06000000, 0x06200000) tenured generation total 40960K, used 666K [0x06200000, 0x08a00000, 0x08a00000) the space 40960K, 1% used [0x06200000, 0x062a68e8, 0x062a6a00, 0x08a00000) Metaspace used 120K, capacity 2248K, committed 2368K, reserved 4480K
强引用,不进行垃圾回收。
软引用,在内存紧张的时候回收。
弱引用,只能生存到下次垃圾收集时候。
虚引用,垃圾收集时候会收到系统通知。
参考
http://www.cnblogs.com/ggjucheng/p/3977384.html相关文章推荐
- SSD的TRIM功能有什么作用
- System.getProperties()
- vector容器部分源码实现
- 软考总结篇
- 从服务器下载文件,读内容到buffer中
- android中对json解析(上传数据以及解析返回值)
- 机器人传感器的分类
- 多核CPU、多进程、多线程之间的联系
- 一步步学spark之一scala常用类型1.2
- google找后台用法
- XML的3种解析方式
- leetcode.350. Intersection of Two Arrays II
- ”无法启动此程序,因为计算机中丢失LIBEAY32.DLL“ 问题解决办法
- 在小米工作是怎样一番体验?
- 学习进度12
- 深度强化学习初探
- springmvc整合thymeleaf中文乱码
- POJ2389大数相乘
- Java中HashMap详解
- 微信摇红包H5应用开发技术分享及源代码(80万微信红包实战)