- 浏览: 322814 次
- 性别:
- 来自: 福建
文章分类
最新评论
-
wangyonglin1123:
完美解决 谢谢您
BufferedReader中文乱码解决 -
wangyonglin1123:
StringBuilder result = new Stri ...
BufferedReader中文乱码解决 -
u011110982:
楼主,代码呢?
PKI体系简易JAVA实现(一):时间戳服务器TSA -
WangSongYuan:
我也遇到楼主一样的问题 果然在<body>后面填一 ...
Extjs IE8 对象不支持此属性或方法的bug -
ocaicai:
https://gist.github.com/wendal/ ...
JAVA获取方法参数名的分析(二)
一篇还不错的分析。网上可查到很多转载,原文系谁所作已不可考,现只能列出我看到的发布时间最早的链接:
转载自: http://dinghaoliang.blog.163.com/blog/static/12654071420098711273543/
一、GC概要:
JVM堆相关知识
为什么先说JVM堆?
JVM的堆是Java对象的活动空间,程序中的类的对象从中分配空间,其存储着正在运行着的应用程序用到的所有对象。这些对象的建立方式就是那些new一类的操作,当对象无用后,是GC来负责这个无用的对象(地球人都知道)。
JVM堆
(1) 新域:存储所有新成生的对象
(2) 旧域:新域中的对象,经过了一定次数的GC循环后,被移入旧域
(3)永久域:存储类和方法对象,从配置的角度看,这个域是独立的,不包括在JVM堆内。默认为4M(这个应该是Perm Space吧)。
新域会被分为3个部分:1.第一个部分叫Eden。(伊甸园??可能是因为亚当和夏娃是人类最早的活动对象?)2.另两个部分称为辅助生存空间(幼儿园),我这里一个称为A空间(From sqace),一个称为B空间(To Space)。
GC的工作目的很明确:在堆中,找到已经无用的对象,并把这些对象占用的空间收回使其可以重新利用.大多数垃圾回收的算法思路都是一致的:把所有对象组成一个集合,或可以理解为树状结构,从树根开始找,只要可以找到的都是活动对象,如果找不到,这个对象就是凋零的昨日黄花,应该被回收了。
在sun 的文档说明中,对JVM堆的新域,是采用coping算法,该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。它开始时把堆分成一个对象面和多个空闲面,程序从对象面为对象分配空间,当对象满了,基于 coping算法的垃圾收集就从根集中扫描活动对象,并将每个活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞),这样空闲面变成了对象面,原来的对象面变成了空闲面,程序会在新的对象面中分配内存。
对于新生成的对象,都放在Eden中;当Eden充满时(小孩太多了),GC将开始工作,首先停止应用程序的运行,开始收集垃圾,把所有可找到的对象都复制到A空间中,一旦当A空间充满,GC就把在A空间中可找到的对象都复制到B空间中(会覆盖原有的存储对象),当B空间满的时间,GC就把在B空间中可找到的对象都复制到A空间中,AB在这个过程中互换角色,那位客官说了:拷来拷去,烦不烦啊?什么时候是头?您别急,在活动对象经过一定次数的GC操作后,这些活动对象就会被放到旧域中。对于这些活动对象,新域的幼儿园生活结束了。
新域为什么要这么折腾?
起初在这块我也很迷糊,又查了些资料,原来是这样:应用程序生成的绝大部分对象都是短命的,copying算法最理想的状态是,所有移出Eden的对象都会被收集,因为这些都是短命鬼,经过一定次数的GC后应该被收集,那么移入到旧域的对象都是长命的,这样可以防止AB空间的来回复制影响应用程序。
实际上这种理想状态是很难达到的,应用程序中不可避免地存在长命的对象,copying算法的发明者要这些对象都尽量放在新域中,以保证小范围的复制,压缩旧域的开销可比新域中的复制大得多(旧域在下面说)。
对于旧域,采用的是tracing算法的一种,称为标记-清除-压缩收集器,注意,这有一个压缩,这是个开销挺大的操作。
垃圾回收主要是对Young Generation块和Old Generation块内存进行回收,YG用来放新产生的对象,经过几次回收还没回收掉的对象往OG中移动,对YG进行垃圾回收又叫做MinorGC,对OG垃圾回收又叫MajorGC,两块内存回收互不干涉。
二、Gc 流程:
[older generation][survivor 1][survivor 2][eden]
*young generation=eden + survivor
1.当eden满了,触发young GC;
2.young GC做2件事:一,去掉一部分没用的object;二,把老的还被引用的object发到survior里面,等下几次GC以后,survivor再放到old里面。
3.当old满了,触发full GC。full GC很消耗内存,把old,young里面大部分垃圾回收掉。这个时候用户线程都会被block。
三、young generation比例越大,不一定最好。
将young的大小设置为大于总堆大小的一半时会造成效率低下。如果设置得过小,又会因为young generation收集程序不得不频繁运行而造成瓶颈。
四、总结
从上面的推导可以得出很多结论,下面是前辈的经验总结与自已的认识
1.JVM堆的大小决定了GC的运行时间。如果JVM堆的大小超过一定的限度,那么GC的运行时间会很长。
2.对象生存的时间越长,GC需要的回收时间也越长,影响了回收速度。
3.大多数对象都是短命的,所以,如果能让这些对象的生存期在GC的一次运行周期内,wonderful!
4.应用程序中,建立与释放对象的速度决定了垃圾收集的频率。
5.如果GC一次运行周期超过3-5秒,这会很影响应用程序的运行,如果可以,应该减少JVM堆的大小了。
6.前辈经验之谈:通常情况下,JVM堆的大小应为物理内存的80%。
五、看案例:
jmap -heap 2343
Attaching to process ID 2343, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.0-b16
using thread-local object allocation.
Parallel GC with 8 thread(s)
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 4294967296 (4096.0MB)
NewSize = 2686976 (2.5625MB)
MaxNewSize = -65536 (-0.0625MB)
OldSize = 5439488 (5.1875MB)
NewRatio = 2 (YG,OG 大小比为1:2)
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 268435456 (256.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 1260060672 (1201.6875MB)
used = 64868288 (61.86322021484375MB)
free = 1195192384 (1139.8242797851562MB)
5.148028935546367% used
From Space:
capacity = 85524480 (81.5625MB)
used = 59457648 (56.70323181152344MB)
free = 26066832 (24.859268188476562MB)
69.52120375359195% used
To Space:
capacity = 85852160 (81.875MB)
used = 0 (0.0MB)
free = 85852160 (81.875MB)
0.0% used
~~~~~~~~~~~~~~~~~~~~~~~~~~这三块为上面所说的YG大小和使用情况
PS Old Generation
capacity = 2291138560 (2185.0MB)
used = 1747845928 (1666.8757705688477MB)
free = 543292632 (518.1242294311523MB)
76.28722062099989% used
~~~~~~~~~~~~~~~~~~~~~~~~~~OG大小和使用情况
PS Perm Generation
capacity = 108265472 (103.25MB)
used = 107650712 (102.6637191772461MB)
free = 614760 (0.5862808227539062MB)
99.43217353728436% used
这台机器简单说YG内存1G,OG内存2G,总内存4G
在这样的配置下,GC运行情况:
jstat -gcutil -h5 2343 4s 100
S0 S1 E O P YGC YGCT FGC FGCT GCT
79.82 0.00 75.34 78.55 99.44 7646 1221.668 398 2052.993 3274.661
0.00 79.52 0.62 78.63 99.44 7647 1221.782 398 2052.993 3274.775 这里发生了一次YG GC,也就是MinorGC,耗时0.12s
0.00 79.52 28.95 78.63 99.44 7647 1221.782 398 2052.993 3274.775
0.00 79.52 46.34 78.63 99.44 7647 1221.782 398 2052.993 3274.775
同时可以看到总共进行了398次Major GC 总耗时2052.993 所以每次Major GC时间为:2052.993/398=5.16秒
这是个很严重的问题,进行Major GC的时候程序会暂停,无法响应,居然会暂停5秒多,这谁都无法接受吧 :)
同样Minor GC进行了7647次,总用时1221.782 平均时间为0.16秒,算是可以接受
再来看看修改配置后:
jmap -heap 14103
Attaching to process ID 14103, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.0-b16
using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 4294967296 (4096.0MB)
NewSize = 536870912 (512.0MB)
MaxNewSize = 536870912 (512.0MB)
OldSize = 5439488 (5.1875MB)
NewRatio =4 YG:OG 1:4
SurvivorRatio = 8
PermSize = 268435456 (256.0MB)
MaxPermSize = 268435456 (256.0MB)
Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 483196928 (460.8125MB)
used = 428284392 (408.4438247680664MB)
free = 54912536 (52.368675231933594MB)
88.63557841162434% used
Eden Space:
capacity = 429522944 (409.625MB)
used = 404788608 (386.0364990234375MB)
free = 24734336 (23.5885009765625MB)
94.24144010337199% used
From Space:
capacity = 53673984 (51.1875MB)
used = 23495784 (22.407325744628906MB)
free = 30178200 (28.780174255371094MB)
43.77499534970238% used
To Space:
capacity = 53673984 (51.1875MB)
used = 0 (0.0MB)
free = 53673984 (51.1875MB)
0.0% used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~YG 大小和使用状态
concurrent mark-sweep generation:
capacity = 3758096384 (3584.0MB)
used = 1680041600 (1602.2125244140625MB)
free = 2078054784 (1981.7874755859375MB)
44.70459052494594% used
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~OG 大小和使用状态
Perm Generation:
capacity = 268435456 (256.0MB)
used = 128012184 (122.0819320678711MB)
free = 140423272 (133.9180679321289MB)
47.688254714012146% used
在这个配置下,GC运行情况:
jstat -gcutil -h5 14103 4s 100
S0 S1 E O P YGC YGCT FGC FGCT GCT
47.49 0.00 64.82 46.08 47.69 20822 2058.631 68 22.734 2081.365
0.00 37.91 38.57 46.13 47.69 20823 2058.691 68 22.734 2081.425 这里发生了一次YG GC,也就是MinorGC,耗时0.06s
46.69 0.00 15.19 46.18 47.69 20824 2058.776 68 22.734 2081.510
46.69 0.00 74.59 46.18 47.69 20824 2058.776 68 22.734 2081.510
0.00 40.29 19.95 46.24 47.69 20825 2058.848 68 22.734 2081.582
MajorGC平均时间:22.734/68=0.334秒(上面是5秒多吧)
MinorGC平均时间:2058.691/20823=0.099秒(比上面略少)
发表评论
-
事务相关总结记录
2011-09-21 16:35 1275查问题过程中,仅对一些东西做下记载。 在总体事务结束前 ... -
JAVA远程调试tomcat、WebSphere
2011-08-04 11:35 5913习惯于直接在eclipse里对 ... -
Ubuntu11.04Server64安装websphere mq 64位
2011-07-18 15:07 2754环境: Ubuntu-11.04-Server-64位 ... -
《Java Collections Framework》文摘及总结
2011-07-11 18:32 01. * The Collection interfa ... -
Maven eclipse debug
2011-04-12 15:24 1083mvn -Dwtpversion=2.0 eclipse:ec ... -
for和Iterator比较
2011-01-21 13:05 1811小记: 2种方式的速度和被操作数据集的类型有关系。 ... -
Appfuse所加载的jar包的作用
2010-06-30 10:50 0最近想深入学习下Appfuse框架。从官网上下了一个Sprin ... -
Ant propertyregex无返回值的问题
2010-05-31 15:58 4273<propertyregex property=&quo ... -
JAVA获取方法参数名的分析(二)
2010-05-13 14:29 80072010年5月13日 魏超 上一节:JAVA获取方法参 ... -
JAVA获取方法参数名的分析(一)
2010-05-13 10:09 138632010-5-12 魏超 关于题目 首先解 ... -
spring配置文件中对bean的id和name设置的区别
2010-05-11 10:32 1970我一直认为spirng的bean只能配置一个Id. 事实上,b ... -
关于子类和父类实现同一个接口
2010-05-04 11:20 5268这个问题是由下面的代码引出的: public c ... -
轻量级缓存 EhCache 简介
2010-04-26 10:29 1649转载自:http://blog.csdn.net/teed ... -
使用statCVS
2010-01-12 16:04 1526现在的项目里用CVS做版 ... -
Collection和Collections的区别
2009-10-19 16:37 1433Collection是个java.util下的接口,它是各种集 ... -
sleep和wait的区别
2009-10-19 16:34 61541、这两个方法来自不同的类分别是Thread和Object ... -
Apache、Tomcat、JBoss、WebLogic的区别与关系
2009-10-19 16:20 10963Apache全球应用最广泛的http服务器,免费,出自ap ... -
BufferedReader中文乱码解决
2009-10-15 11:00 70458做一个从windows cmd截获命令返回值的java程序,结 ... -
Swing Synth外观定制UI
2009-10-14 13:44 1808本文将深入透视 Synth 外 ... -
Eclipse 中警告:不能读取 AppletViewer 的属性文件解决
2009-10-14 10:18 2478警告:不能读取 AppletViewer 的属性文件: C:\ ...
相关推荐
Java虚拟机(JVM)的垃圾回收(GC)机制是Java程序高效运行的关键部分,它自动管理内存,释放不再使用的对象以避免内存泄漏。本文主要探讨JVM堆内存的结构和GC的工作原理,以及如何进行性能调优。 JVM堆是Java应用...
本文将深入探讨JVM的垃圾回收机制,并分享一些优化GC性能的有效策略。 首先,理解JVM内存模型至关重要。JVM内存分为堆(Heap)、栈(Stack)、方法区(Method Area)等几个区域。其中,堆是GC的主要工作区域,用于...
JVM 的垃圾回收机制是 Java GC 与性能调优的核心内容。JVM 的垃圾回收机制可以分为以下几个步骤: * 标记阶段:标记出所有活动对象。 * 清除阶段:清除所有不可达对象。 * 压缩阶段:压缩内存,减少碎片。 五、 ...
除了参数配置之外,调优还涉及对垃圾回收机制的优化。JVM提供了多种垃圾回收器供选择,如Serial GC、Parallel GC、CMS GC等。开发者可以根据应用的特点选择合适的垃圾回收器,并通过JVM参数进行配置,以达到提升性能...
弱引用与软引用类似,也是用来描述非必须对象的,但它比软引用更弱一些,只要垃圾回收机制运行,无论当前内存是否足够,弱引用的对象都会被回收。虚引用是最弱的一种引用关系,它不会对对象的生存时间构成影响,也...
5. **GC调优**:包括如何分析GC日志,理解GC停顿(Stop-the-World)事件,以及如何通过调整JVM参数来改善系统性能,如设置堆大小、新生代与老年代的比例、存活代的晋升策略等。 6. **性能监控与诊断工具**:如...
GC调优主要包括以下几个方面: 1. **内存配置**:调整新生代、老年代的大小,以平衡GC频率和暂停时间。 2. **GC日志分析**:通过分析GC日志,了解GC行为,找出性能瓶颈。 3. **并行与并发设置**:调整并行GC线程数...
- **案例二:大数据处理平台调优**:大数据处理平台往往需要处理海量数据,通过对JVM内存配置、垃圾回收机制等方面的优化,提升数据处理速度。 - **案例三:分布式系统调优**:分布式系统面临着网络延迟、节点通信等...
通过深入学习JVM体系结构和GC调优,开发者可以更好地理解和控制Java应用的内存使用,减少垃圾收集的开销,提升系统性能。这份PPT将帮助我们系统地掌握这些关键点,使我们能够应对实际开发中的各种挑战。
JVM 的性能调优主要涉及到 JVM 内存整理、垃圾回收(GC)机制等方面。 Java 中的值传递和引用传递 在 Java 中,函数参数传递可以分为两种方式:值传递和引用传递。值传递是指函数参数是基本类型时,传递的值是...
GC调优是JVM性能优化的关键环节,涉及GC参数的调整,如新生代与老年代的比例、存活对象的阈值、并发比等。通过合理设置这些参数,可以实现更高效的内存回收,降低应用暂停时间,提高整体性能。同时,理解GC日志,...
本文将深入探讨JVM的四个关键领域:类的加载机制、内存结构、垃圾回收(GC)算法以及GC分析和命令调优。 首先,我们来看类的加载机制。类的加载始于加载阶段,它将类的.class文件中的二进制数据读入内存,并在方法...
通过对JVM_GC调优的深入探讨,我们可以看出JVM内存管理和垃圾回收机制的复杂性。合理的GC策略和参数调整对于提高Java应用的性能至关重要。理解不同GC算法的特点和适用场景,可以帮助开发者选择最适合特定应用场景的...
2. **内存管理**:JVM提供了自动内存管理机制,包括垃圾收集器,可以自动回收不再使用的对象所占用的内存空间。 3. **安全性**:JVM提供了沙箱安全模型,确保运行中的Java程序不会对操作系统造成损害。 #### 二、...
总结来说,理解JVM的内存分配策略和垃圾回收机制对于优化Java应用的性能至关重要。开发者需要根据应用的特性调整JVM参数,确保内存的有效利用,减少不必要的垃圾收集开销,从而提高系统的响应速度和稳定性。
本教程详细介绍了JVM(Java虚拟机)的结构、类型和编译器模式、参数分类、即时编译器(JIT)诊断工具、垃圾回收机制、内存调优方法,以及并行和CMS垃圾回收器的优化策略。重点内容包括: JVM类型和编译器模式:...