虚拟机学习系列 - 3 - 垃圾收集算法

目录
虚拟机学习系列 - 1 - 运行时数据区域
虚拟机学习系列 - 2 - 垃圾收集概述
虚拟机学习系列 - 3 - 垃圾收集算法
虚拟机学习系列 - 4 - 垃圾收集器
虚拟机学习系列 - 5 - 内存分配与回收策略

虚拟机学习系列 - 6 - JDK工具

虚拟机学习系列 - 附 - 虚拟机参数

虚拟机学习系列 - 附 - OQL(对象查询语言)

 

 

这节内容较少,也比较简单,所以就贴上笔记好了

下一节的垃圾收集器作为重点

 

 

我们常见的算法有以下几种

1.标记-清除(Mark-Sweep)算法

2.复制(Copying)算法

3.标记-整理(Mark-Compact)算法

4.分代收集(Generational Collection)算法

 

java虚拟机中基本都是1、2、3与4结合,在新生代和老年代根据需要使用不同的回收算法

大概过程见笔记

 

 

ps:这里说一下我前几天遇到的一个问题

大概是这样的,在我们的系统里面,给每个应用分配的最大内存设置为32mb

由于内存小,又要加载很多图片,所以就更要注意内存的使用问题

我们很不幸,遇到了OOM(其实在android出现OOM是很常见的事情,稍微不注意便会内存溢出)

问题出在一张特殊的图片上,图片本身不大,大小只有3mb,有很多图片比这个大,但是加载压缩之后会变的比较小

但是这张图片加载完之后大概占了不到5mb内存

使用的时候反复操作,多浏览些图片,在DDMS中查看内存使用情况

当Heap Size超过27mb的时候再来加载那张图片,基本上就会100%出现OOM了

我很奇怪,Allocated的值大概26mb多一点,现在剩余的空间+可申请的空间是大于这张图片加载所需要的空间的,我不认为存在内存不足的问题,难道是内存碎片太多没有进行整理吗,虽然我不太清楚DVM垃圾回收具体算法,但是我觉得不进行碎片整理的可能性很小

后来一个经验丰富的同事告诉我,原话记不清了,大概是说:

内存整理只能保证内存空间的连续性,但是能不能拿出5mb分给一个对象还不一定

内存可能被分成了N1个1k,N2个2K,N3个4k……,并没有5mb这么大的内存能提供给我

看来内存整理似乎也不能给你100%的安全保障啊

 


虚拟机学习系列 - 3 - 垃圾收集算法_第1张图片

 

 

转贴请保留以下链接

本人blog地址

http://su1216.iteye.com/

http://blog.csdn.net/su1216/

你可能感兴趣的:(java,jvm)