Java垃圾回收与回收机制Word格式.docx
- 文档编号:20732198
- 上传时间:2023-01-25
- 格式:DOCX
- 页数:13
- 大小:27.86KB
Java垃圾回收与回收机制Word格式.docx
《Java垃圾回收与回收机制Word格式.docx》由会员分享,可在线阅读,更多相关《Java垃圾回收与回收机制Word格式.docx(13页珍藏版)》请在冰豆网上搜索。
这一个过程需要花费处理器的时间。
其次垃圾收集算法的不完备性,早先采用的某些垃圾收集算法就不能保证100%收集到所有的废弃内存。
当然随着垃圾收集算法的不断改进以及软硬件运行效率的不断提升,这些问题都可以迎刃而解。
垃圾收集的算法分析
Java语言规范没有明确地说明JVM使用哪种垃圾回收算法,但是任何一种垃圾收集算法一般要做2件基本的事情:
(1)发现无用信息对象;
(2)回收被无用对象占用的内存空间,使该空间可被程序再次使用。
大多数垃圾回收算法使用了根集(rootset)这个概念;
所谓根集就量正在执行的Java程序可以访问的引用变量的集合(包括局部变量、参数、类变量),程序可以使用引用变量访问对象的属性和调用对象的方法。
垃圾收集首选需要确定从根开始哪些是可达的和哪些是不可达的,从根集可达的对象都是活动对象,它们不能作为垃圾被回收,这也包括从根集间接可达的对象。
而根集通过任意路径不可达的对象符合垃圾收集的条件,应该被回收。
下面介绍几个常用的算法。
1、引用计数法(ReferenceCountingCollector)
引用计数法是唯一没有使用根集的垃圾回收的法,该算法使用引用计数器来区分存活对象和不再使用的对象。
一般来说,堆中的每个对象对应一个引用计数器。
当每一次创建一个对象并赋给一个变量时,引用计数器置为1。
当对象被赋给任意变量时,引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用),引用计数器减1,一旦引用计数器为0,对象就满足了垃圾收集的条件。
基于引用计数器的垃圾收集器运行较快,不会长时间中断程序执行,适宜地必须实时运行的程序。
但引用计数器增加了程序执行的开销,因为每次对象赋给新的变量,计数器加1,而每次现有对象出了作用域生,计数器减1。
2、tracing算法(TracingCollector)
tracing算法是为了解决引用计数法的问题而提出,它使用了根集的概念。
基于tracing算法的垃圾收集器从根集开始扫描,识别出哪些对象可达,哪些对象不可达,并用某种方式标记可达对象,例如对每个可达对象设置一个或多个位。
在扫描识别过程中,基于tracing算法的垃圾收集也称为标记和清除(mark-and-sweep)垃圾收集器.
3、compacting算法(CompactingCollector)
为了解决堆碎片问题,基于tracing的垃圾回收吸收了Compacting算法的思想,在清除的过程中,算法将所有的对象移到堆的一端,堆的另一端就变成了一个相邻的空闲内存区,收集器会对它移动的所有对象的所有引用进行更新,使得这些引用在新的位置能识别原来的对象。
在基于Compacting算法的收集器的实现中,一般增加句柄和句柄表。
4、copying算法(CopingCollector)
该算法的提出是为了克服句柄的开销和解决堆碎片的垃圾回收。
它开始时把堆分成一个对象面和多个空闲面,程序从对象面为对象分配空间,当对象满了,基于coping算法的垃圾收集就从根集中扫描活动对象,并将每个活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞),这样空闲面变成了对象面,原来的对象面变成了空闲面,程序会在新的对象面中分配内存。
一种典型的基于coping算法的垃圾回收是stop-and-copy算法,它将堆分成对象面和空闲区域面,在对象面与空闲区域面的切换过程中,程序暂停执行。
5、generation算法(GenerationalCollector)
stop-and-copy垃圾收集器的一个缺陷是收集器必须复制所有的活动对象,这增加了程序等待时间,这是coping算法低效的原因。
在程序设计中有这样的规律:
多数对象存在的时间比较短,少数的存在时间比较长。
因此,generation算法将堆分成两个或多个,每个子堆作为对象的一代(generation)。
由于多数对象存在的时间比较短,随着程序丢弃不使用的对象,垃圾收集器将从最年轻的子堆中收集这些对象。
在分代式的垃圾收集器运行后,上次运行存活下来的对象移到下一最高代的子堆中,由于老一代的子堆不会经常被回收,因而节省了时间。
6、adaptive算法(AdaptiveCollector)
在特定的情况下,一些垃圾收集算法会优于其它算法。
基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况,并将选择适当算法的垃圾收集器。
透视Java垃圾回收
1、命令行参数透视垃圾收集器的运行
2、使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法,都可以请求Java的垃圾回收。
在命令行中有一个参数-verbosegc可以查看Java使用的堆内存的情况,它的格式如下:
java-verbosegcclassfile
可以看个例子:
classTestGC{
publicstaticvoidmain(String[]args){
newTestGC();
System.gc();
System.runFinalization();
}
在这个例子中,一个新的对象被创建,由于它没有使用,所以该对象迅速地变为可达,程序编译后,执行命令:
java-verbosegcTestGC后结果为:
[FullGC168K->
97K(1984K),0.0253873secs]
机器的环境为,Windows2000+JDK1.3.1,箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量,说明有168K-97K=71K的对象容量被回收,括号内的数据1984K为堆内存的总容量,收集所需要的时间是0.0253873秒(这个时间在每次执行的时候会有所不同)。
2、finalize方法透视垃圾收集器的运行
在JVM垃圾收集器收集一个对象之前,一般要求程序调用适当的方法释放资源,但在没有明确释放资源的情况下,Java提供了缺省机制来终止化该对象心释放资源,这个方法就是finalize()。
它的原型为:
protectedvoidfinalize()throwsThrowable
在finalize()方法返回之后,对象消失,垃圾收集开始执行。
原型中的throwsThrowable表示它可以抛出任何类型的异常。
之所以要使用finalize(),是由于有时需要采取与Java的普通方法不同的一种方法,通过分配内存来做一些具有C风格的事情。
这主要可以通过"
固有方法"
来进行,它是从Java里调用非Java方法的一种方式。
C和C++是目前唯一获得固有方法支持的语言。
但由于它们能调用通过其他语言编写的子程序,所以能够有效地调用任何东西。
在非Java代码内部,也许能调用C的malloc()系列函数,用它分配存储空间。
而且除非调用了free(),否则存储空间不会得到释放,从而造成内存"
漏洞"
的出现。
当然,free()是一个C和C++函数,所以我们需要在finalize()内部的一个固有方法中调用它。
也就是说我们不能过多地使用finalize(),它并不是进行普通清除工作的理想场所。
在普通的清除工作中,为清除一个对象,那个对象的用户必须在希望进行清除的地点调用一个清除方法。
这与C++"
破坏器"
的概念稍有抵触。
在C++中,所有对象都会破坏(清除)。
或者换句话说,所有对象都"
应该"
破坏。
若将C++对象创建成一个本地对象,比如在堆栈中创建(在Java中是不可能的),那么清除或破坏工作就会在"
结束花括号"
所代表的、创建这个对象的作用域的末尾进行。
若对象是用new创建的(类似于Java),那么当程序员调用C++的delete命令时(Java没有这个命令),就会调用相应的破坏器。
若程序员忘记了,那么永远不会调用破坏器,我们最终得到的将是一个内存"
,另外还包括对象的其他部分永远不会得到清除。
相反,Java不允许我们创建本地(局部)对象--无论如何都要使用new。
但在Java中,没有"
delete"
命令来释放对象,因为垃圾收集器会帮助我们自动释放存储空间。
所以如果站在比较简化的立场,我们可以说正是由于存在垃圾收集机制,所以Java没有破坏器。
然而,随着以后学习的深入,就会知道垃圾收集器的存在并不能完全消除对破坏器的需要,或者说不能消除对破坏器代表的那种机制的需要(而且绝对不能直接调用finalize(),所以应尽量避免用它)。
若希望执行除释放存储空间之外的其他某种形式的清除工作,仍然必须调用Java中的一个方法。
它等价于C++的破坏器,只是没后者方便。
下面这个例子向大家展示了垃圾收集所经历的过程,并对前面的陈述进行了总结。
classChair{
staticbooleangcrun=false;
staticbooleanf=false;
staticintcreated=0;
staticintfinalized=0;
inti;
Chair(){
i=++created;
if(created==47)
System.out.println("
Created47"
);
protectedvoidfinalize(){
if(!
gcrun){
gcrun=true;
Beginningtofinalizeafter"
+created+"
Chairshavebeencreated"
if(i==47){
FinalizingChair#47,"
+"
SettingflagtostopChaircreation"
f=true;
finalized++;
if(finalized>
=created)
All"
+finalized+"
finalized"
publicclassGarbage{
if(args.length==0){
System.err.println("
Usage:
\n"
+"
javaGarbagebefore\nor:
\n"
javaGarbageafter"
return;
while(!
Chair.f){
newChair();
newString("
Totakeupspace"
AfterallChairshavebeencreated:
totalcreated="
+Chair.created+"
,totalfinalized="
+Chair.finalized);
if(args[0].equals("
before"
)){
gc():
"
runFinalization():
bye!
after"
))
System.runFinalizersOnExit(true);
上面这个程序创建了许多Chair对象,而且在垃圾收集器开始运行后的某些时候,程序会停止创建Chair。
由于垃圾收集器可能在任何时间运行,所以我们不能准确知道它在何时启动。
因此,程序用一个名为gcrun的标记来指出垃圾收集器是否已经开始运行。
利用第二个标记f,Chair可告诉main()它应停止对象的生成。
这两个标记都是在finalize()内部设置的,它调用于垃圾收集期间。
另两个static变量--created以及finalized--分别用于跟踪已创建的对象数量以及垃圾收集器已进行完收尾工作的对象数量。
最后,每个Chair都有它自己的(非static)inti,所以能跟踪了解它具体的编号是多少。
编号为47的Chair进行完收尾工作后,标记会设为true,最终结束Chair对象的创建过程。
关于垃圾收集的几点补充
经过上述的说明,可以发现垃圾回收有以下的几个特点:
(1)垃圾收集发生的不可预知性:
由于实现了不同的垃圾收集算法和采用了不同的收集机制,所以它有可能是定时发生,有可能是当出现系统空闲CPU资源时发生,也有可能是和原始的垃圾收集一样,等到内存消耗出现极限时发生,这与垃圾收集器的选择和具体的设置都有关系。
(2)垃圾收集的精确性:
主要包括2个方面:
(a)垃圾收集器能够精确标记活着的对象;
(b)垃圾收集器能够精确地定位对象之间的引用关系。
前者是完全地回收所有废弃对象的前提,否则就可能造成内存泄漏。
而后者则是实现归并和复制等算法的必要条件。
所有不可达对象都能够可靠地得到回收,所有对象都能够重新分配,允许对象的复制和对象内存的缩并,这样就有效地防止内存的支离破碎。
(3)现在有许多种不同的垃圾收集器,每种有其算法且其表现各异,既有当垃圾收集开始时就停止应用程序的运行,又有当垃圾收集开始时也允许应用程序的线程运行,还有在同一时间垃圾收集多线程运行。
(4)垃圾收集的实现和具体的JVM以及JVM的内存模型有非常紧密的关系。
不同的JVM可能采用不同的垃圾收集,而JVM的内存模型决定着该JVM可以采用哪些类型垃圾收集。
现在,HotSpot系列JVM中的内存系统都采用先进的面向对象的框架设计,这使得该系列JVM都可以采用最先进的垃圾收集。
(5)随着技术的发展,现代垃圾收集技术提供许多可选的垃圾收集器,而且在配置每种收集器的时候又可以设置不同的参数,这就使得根据不同的应用环境获得最优的应用性能成为可能。
针对以上特点,我们在使用的时候要注意:
(1)不要试图去假定垃圾收集发生的时间,这一切都是未知的。
比如,方法中的一个临时对象在方法调用完毕后就变成了无用对象,这个时候它的内存就可以被释放。
(2)Java中提供了一些和垃圾收集打交道的类,而且提供了一种强行执行垃圾收集的方法--调用System.gc(),但这同样是个不确定的方法。
Java中并不保证每次调用该方法就一定能够启动垃圾收集,它只不过会向JVM发出这样一个申请,到底是否真正执行垃圾收集,一切都是个未知数。
(3)挑选适合自己的垃圾收集器。
一般来说,如果系统没有特殊和苛刻的性能要求,可以采用JVM的缺省选项。
否则可以考虑使用有针对性的垃圾收集器,比如增量收集器就比较适合实时性要求较高的系统之中。
系统具有较高的配置,有比较多的闲置资源,可以考虑使用并行标记/清除收集器。
(4)关键的也是难把握的问题是内存泄漏。
良好的编程习惯和严谨的编程态度永远是最重要的,不要让自己的一个小错误导致内存出现大漏洞。
(5)尽早释放无用对象的引用。
大多数程序员在使用临时变量的时候,都是让引用变量在退出活动域(scope)后,自动设置为null,暗示垃圾收集器来收集该对象,还必须注意该引用的对象是否被监听,如果有,则要去掉监听器,然后再赋空值。
结束语
一般来说,Java开发人员可以不重视JVM中堆内存的分配和垃圾处理收集,但是,充分理解Java的这一特性可以让我们更有效地利用资源。
同时要注意finalize()方法是Java的缺省机制,有时为确保对象资源的明确释放,可以编写自己的finalize方法。
JVM详解之Java垃圾回收机制详解和调优
1.JVM的gc概述
gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。
java语言并不要求jvm有gc,也没有规定gc如何工作。
不过常用的jvm都有gc,而且大多数gc都使用类似的算法管理内存和执行收集操作。
在充分理解了垃圾收集算法和执行过程后,才能有效的优化它的性能。
有些垃圾收集专用于特殊的应用程序。
比如,实时应用程序主要是为了避免垃圾收集中断,而大多数OLTP应用程序则注重整体效率。
理解了应用程序的工作负荷和jvm支持的垃圾收集算法,便可以进行优化配置垃圾收集器。
垃圾收集的目的在于清除不再使用的对象。
gc通过确定对象是否被活动对象引用来确定是否收集该对象。
gc首先要判断该对象是否是时候可以收集。
两种常用的方法是引用计数和对象引用遍历。
1.1.引用计数
引用计数存储对特定对象的所有引用数,也就是说,当应用程序创建引用以及引用超出范围时,jvm必须适当增减引用数。
当某对象的引用数为0时,便可以进行垃圾收集。
1.2.对象引用遍历
早期的jvm使用引用计数,现在大多数jvm采用对象引用遍历。
对象引用遍历从一组对象开始,沿着整个对象图上的每条链接,递归确定可到达(reachable)的对象。
如果某对象不能从这些根对象的一个(至少一个)到达,则将它作为垃圾收集。
在对象遍历阶段,gc必须记住哪些对象可以到达,以便删除不可到达的对象,这称为标记(marking)对象。
下一步,gc要删除不可到达的对象。
删除时,有些gc只是简单的扫描堆栈,删除未标记的未标记的对象,并释放它们的内存以生成新的对象,这叫做清除(sweeping)。
这种方法的问题在于内存会分成好多小段,而它们不足以用于新的对象,但是组合起来却很大。
因此,许多gc可以重新组织内存中的对象,并进行压缩(compact),形成可利用的空间。
为此,gc需要停止其他的活动活动。
这种方法意味着所有与应用程序相关的工作停止,只有gc运行。
结果,在响应期间增减了许多混杂请求。
另外,更复杂的gc不断增加或同时运行以减少或者清除应用程序的中断。
有的gc使用单线程完成这项工作,有的则采用多线程以增加效率。
2.几种垃圾回收机制
2.1.标记-清除收集器
这种收集器首先遍历对象图并标记可到达的对象,然后扫描堆栈以寻找未标记对象并释放它们的内存。
这种收集器一般使用单线程工作并停止其他操作。
2.2.标记-压缩收集器
有时也叫标记-清除-压缩收集器,与标记-清除收集器有相同的标记阶段。
在第二阶段,则把标记对象复制到堆栈的新域中以便压缩堆栈。
这种收集器也停止其他操作。
2.3.复制收集器
这种收集器将堆栈分为两个域,常称为半空间。
每次仅使用一半的空间,jvm生成的新对象则放在另一半空间中。
gc运行时,它把可到达对象复制到另一半空间,从而压缩了堆栈。
这种方法适用于短生存期的对象,持续复制长生存期的对象则导致效率降低。
2.4.增量收集器
增量收集器把堆栈分为多个域,每次仅从一个域收集垃圾。
这会造成较小的应用
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 垃圾 回收 机制
![提示](https://static.bdocx.com/images/bang_tan.gif)