虚拟机学习系列 - 三 - 垃圾收集算法
目录
虚拟机学习系列 - 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%的安全保障啊