Java垃圾收集算法

1.垃圾收集算法的核心思想

Java语言建立了垃圾收集机制,用以跟踪正在使用的对象和发现并回收不再使用(引用)的对象。该机制可以有效防范动态内存分配中可能发生的两个危险:因内存垃圾过多而引发的内存耗尽,以及不恰当的内存释放所造成的内存非法引用。

垃圾收集算法的核心思想是:对虚拟机可用内存空间,即堆空间中的对象进行识别,如果对象正在被引用,那么称其为存活对象,反之,如果对象不再被引用,则为垃圾对象,可以回收其占据的空间,用于再分配。垃圾收集算法的选择和垃圾收集系统参数的合理调节直接影响着系统性能,因此需要开发人员做比较深入的了解。

2.触发主GC(Garbage Collector)的条件

JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,因为它对系统影响很明显。总的来说,有两个条件会触发主GC:

①当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。

②Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要求,则 JVM将报“out of memory”的错误,Java应用将停止。

由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。

3.减少GC开销的措施

根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。具体措施包括以下几个方面:

(1)不要显式调用System.gc()

此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。

(2)尽量减少临时对象的使用

临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。

(3)对象不用时最好显式置为Null

一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。

(4)尽量使用StringBuffer,而不用String来累加字符串(详见blog另一篇文章JAVA中String与StringBuffer)

由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。

(5)能用基本类型如Int,Long,就不用Integer,Long对象

基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。

(6)尽量少用静态对象变量

静态变量属于全局变量,不会被GC回收,它们会一直占用内存。

(7)分散对象创建或删除的时间

集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC,以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主GC的机会。

时间: 2024-11-03 02:43:16

Java垃圾收集算法的相关文章

jvm系列(三):java GC算法 垃圾收集器

GC算法 垃圾收集器 概述 垃圾收集 Garbage Collection 通常被称为"GC",它诞生于1960年 MIT 的 Lisp 语言,经过半个多世纪,目前已经十分成熟了. jvm 中,程序计数器.虚拟机栈.本地方法栈都是随线程而生随线程而灭,栈帧随着方法的进入和退出做入栈和出栈操作,实现了自动的内存清理,因此,我们的内存垃圾回收主要集中于 java 堆和方法区中,在程序运行期间,这部分内存的分配和使用都是动态的.   对象存活判断 判断对象是否存活一般有两种方式: 引用计数:

[JVM]垃圾收集算法

本文"垃圾收集算法"节选自<深入理解Java虚拟机:JVM高级特性与最佳实践>[作者:周志明] 由于垃圾收集算法的实现涉及大量的程序细节,而且各个平台的虚拟机操作内存的方法又各不相同,因此本节不打算过多地讨论算法的实现,只是介绍几种算法的思想及其发展过程. 1 标记-清除算法 最基础的收集算法是"标记-清除"(Mark-Sweep)算法,如它的名字一样,算法分为"标记"和"清除"两个阶段:首先标记出所有需要回收的对

JAVA垃圾收集器与内存分配策略详解_java

引言 垃圾收集技术并不是Java语言首创的,1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言.垃圾收集技术需要考虑的三个问题是: 1.哪些内存需要回收 2.什么时候回收 3.如何回收 java内存运行时区域的分布,其中程序计数器,虚拟机栈,本地方法区都是随着线程而生,随线程而灭,所以这几个区域就不需要过多考虑回收问题.但是堆和方法区就不一样了,只有在程序运行期间我们才知道会创建哪些对象,这部分内存的分配和回收都是动态的.垃圾收集器所关注的就是这部分内存. 一 对象

Java垃圾收集学习笔记

版权声明:本文为博主原创文章,转载注明出处http://blog.csdn.net/u013142781 (1)除了释放不再被引用的对象,垃圾收集器还要处理堆碎块.请求分配新对象时可能不得不增大堆空间的大小,虽然可以使用的空闲空间是足够的,但是堆中没有没有连续的空间放得下新对象.可能会导致虚拟机产生不必要的"内存不足"错误. (2)使用垃圾收集堆,有一个潜在的缺陷就是加大程序的负担,可能影响程序的性能.因为虚拟机需要追踪哪些对象被正在执行的程序引用,还要动态释放垃圾对象. (3)程序可

算法 日期-JAVA日期算法问题????

问题描述 JAVA日期算法问题???? 参数:开始时间.结束时间,时间格式:yyyy-MM-dd,可以考虑用UnixTime转换计算 前置条件: 1.每个月15日是定死的中间比对日期,即结算时间 2.开始时间必须是小于结束时间 需要解决的问题: 按输入的开始时间.结束时间,动态计算从开始时间到结束时间之间每个月与结算时间的相差天数,并且记录最后的结算日期 比如: 开始时间3月1日,结束时间5月10日, 3月1日至3月15日算一次天数,并且记录下3月15日, 然后开始时间变为3月15日,至4月15

java排序算法

Java 1.0和1.1库都缺少的一样东西是算术运算,甚至没有最简单的排序运算方法.因此,我们最好创建一个Vector,利用经典的Quicksort(快速排序)方法对其自身进行排序. 编写通用的排序代码时,面临的一个问题是必须根据对象的实际类型来执行比较运算,从而实现正确的排序.当然,一个办法是为每种不同的类型都写一个不同的排序方法.然而,应认识到假若这样做,以后增加新类型时便不易实现代码的重复利用. 程序设计一个主要的目标就是"将发生变化的东西同保持不变的东西分隔开".在这里,保持不

Java经典算法汇总之冒泡排序_java

原理:比较两个相邻的元素,将值大的元素交换至右端. 思路:依次比较相邻的两个数,将小数放在前面,大数放在后面.即在第一趟:首先比较第1个和第2个数,将小数放前,大数放后.然后比较第2个数和第3个数,将小数放前,大数放后,如此继续,直至比较最后两个数,将小数放前,大数放后.重复第一趟步骤,直至全部排序完成. 举例说明:要排序数组:int[]arr={6,3,8,2,9,1}; 第一趟排序: 第一次排序:6和3比较,6大于3,交换位置:368291 第二次排序:6和8比较,6小于8,不交换位置:36

java-Python sha1算法和Java sha1算法结果为何不同?

问题描述 Python sha1算法和Java sha1算法结果为何不同? 需要计算sha1值,用Java写,但要Python的sha1结果. 解决方案 散列算法是否一样,有些算法不同也会导致结果不同. 解决方案二: 编码格式等.曾经碰到一个现象是C中用BTTE数组来存放数据计算SHA1,而Python用字符串格式存放数据,计算SHA1结果会相同

java抽奖算法,高人请指点一二

问题描述 java抽奖算法,高人请指点一二 一共有3分,一天可以进行无数次抽奖,最高获得3分,可以是1+1+1也可以是2+1也可以是1+2,分别是每次抽奖获得的奖励数,这个怎么做呢? 解决方案 这个简单,第一次抽奖产生一个1~3的随机数第二次产生1~(N-已经抽奖的总分)的随机数当已经抽奖的随机数总和达到3,就不许抽奖了. 解决方案二: "几"=(抽奖人数/奖品数)*N.这是一种最简单抽奖算法 http://www.cnblogs.com/younggun/p/3249772.html