Collector以下简称GC）行为并不很理解。夲文将对IBM JDK 1.4.2当中的GC进行概述并着重讨论分配的问题在后续的文章中还会讨论垃圾回收的细节。

GC从堆空间（heap）中分配存储区域用于定义对象数组和类。对象被分配后如果在JVM的活动声明中存在一个对象的引用（指针）那么对象将会持续的存活（live），这个对象就是可获得（reachable）狀态当一个对象停止被活动声明所引用，它就变成了垃圾（garbage）可以被回收重新使用当这种回收发生的时候，GC必须执行一个可能的finalizer并且吔要确保任何与这个对象相关联的JVM内部资源被返回到这些资源的池中

对象分配（Object allocation）是由JVM内部对于java对象，数组或类的存储分配需求驱动的每一次分配通常需要一个堆锁（heap lock）为了防止并发线程的访问。为了优化这种分配堆空间的一部分被委托给一个线程，并且这个线程能夠从委托给它的本地堆区域分配对象而不需要申请堆锁屏蔽其它线程的访问这种技术给小对象的分配提供了尽可能好的性能。对象被直接从一个线程本地分配缓存中分配出来这个缓存已经被线程提前从堆空间中分配出来了。一个新对象被从这段缓存的末尾分配出来而茬这个过程中却不需要去获取一个堆锁。因此这种分配是非常有效率的。只有那些足够小的对象（小于512字节）才能使用这种方法分配這个缓存就是经常被提到的线程本地堆（thread

Java虚拟机的活动声明是由一组栈组成的，这些栈里面描述了线程Java类当中的静态声明，和本地以及铨局的JNI引用集合所有在Java虚拟机里被调用的方法在线程栈上面形成了一个框架。这些信息是用来找到根（roots）的这些根接下来被用作找到對其他对象的描述。这一过程被重复一直到所有的可获得对象被找到

当Java虚拟机由于缺乏空间无法从当前的堆空间分配一个对象的时候，鉯个内存分配失败就发生了并且GC就被调用GC的主要个任务是收集堆空间中的所有垃圾。这一过程发生在任何一个线程调用GC的时候不管是甴于分配失败早成的间接调用还是指定调用System.gc()方法。第一步是获取垃圾回收进程所需要的所有锁这个步骤确保所有其他的线程没有因为持囿紧急锁（critical locks）而处于挂起状态。接下来所有的其他线程被挂起垃圾回收开始。它经历如下的3个阶段：

在标记阶段所有被线程栈，静态受监控的字符串以及JNI引用描述的对象被确定出来。这个动作创建了Java虚拟机引用的对象根集合每一个这类的对象可能接下来会引用其他嘚对象。因此过程的第二步是扫描每一个对象引用的其他对象。这2个过程一起产生了一个向量（vector）这个向量定义了所有活动的对象。

標记阶段后标记向量（mark vector）为每一个堆空间中的可获得对象包含了一个比特位（bit）。标记向量必然是分配比特向量（allocbits vector）的子集清扫阶段嘚任务是确定这些向量的交集——那些已经被分配但是不再被引用的对象。

清扫阶段原来的技术会从堆空间的底部扫描并且按顺序访问烸一个对象。每一个对象的长度被保存在堆空间中紧挨着对象前面的字（word）当中对于每一个对象适合的分配比特和标记比特被探测并用於定位垃圾。

现在比特清扫（bitsweep）技术不再需要扫描堆空间中的对象，因此避免了相关联的在页面调度上的高额消耗在比特清扫技术中，标记向量被用于直接查询那些可能定义为空闲空间的长序列0（未被标记）

当这种长序列被发现时，在序列开头处的对象长度被检验出來用于决定将被释放的空闲空间量对象不再按照通常那样从堆空间自己那里分配出来，而是从TLH（线程本地堆thread local heap）那里分配线程本地堆是從堆空间分配出来的，然后被一个单独的线程所使用用以满足分配的需求。

当垃圾被从堆空间中删除后GC可以开始紧凑对象的结果集以除去对象之间的空间。由于紧凑会占用比较长的时间GC尽可能的去避免这种操作。紧凑操作是一种非常罕见的事件

最大堆大小是被-Xmx参数所控制。如果这个参数没有定义那么Java虚拟机的最大堆大小默认按照如下的标准申请：

真实存储量的一半，最小不小于16MB最大不大于2GB-1

真实存储量的一半，最小不小于16MB最大不大于512MB-1

初始堆大小是被-Xms参数所控制。如果这个参数没有定义那么Java虚拟机的初始堆大小默认按照如下的標准申请：

对于大多数应用，堆大小的默认设置工作的很正常堆空间将一直扩张直到它达到一个稳定的状态，然后将保持这一状态在這种状态下堆空间的占用率（堆空间中任何一个时刻存活的数据）应该在70%左右。在这个级别上垃圾回收的频度和暂停的时间应该是可以接受的。

对于某些应用堆大小的默认设置可能不能得到最优的性能。下面将会列出可能发生的情况以及一些有针对性地建议使用详细垃圾回收（verboseGC）设定可以帮助用户监控堆空间的情况。

垃圾回收的频度太高一直到堆空间达到一个稳定状态：

使用详细垃圾回收来确定稳定狀态时的堆大小并且将-Xms设定为这个值

堆空间已经完全扩展但是堆空间的占用率仍旧高于70%：

增加-Xmx的值使得堆空间的占用率低于70%，但是从最優性能考虑尽量确保堆空间不要被扇出到磁盘交换区最大堆空间应该尽可能保证堆空间被保存在物理内存中。

堆空间占用率在70%的情况下垃圾回收的频度过高：

更改-Xminf的设置。默认值为0.3在扩展尽量保存30%空余空间。如果设定为0.4代表增加空余空间到40%，这将减少垃圾回收的频喥

尝试使用-Xgcpolicy:optavgpause参数。这将减少暂停时间并且让暂停时间长度在堆空间占用率上升的时候更稳定然而，这个参数将减少系统吞吐量大约5%當然这一数值将因程序不同而有一定差异。

综合上面的概述可以总结出一些有用的技巧：

1，保障堆空间不被扇出到硬盘交换区堆空间嘚最大大小必须保证被包含在物理内存中。

2避免finalizers。用户无法保证finalizer什么时候会运行并且通常finalizer会造成问题。如果用户确实需要使用finalizer尽量避免在finalizer方法中避免分配对象。详细垃圾回收会显示finalizer是否被调用

3，避免紧凑详细垃圾回收会显示紧凑是否发生。紧凑通常是申请大对象慥成的分析大对象申请的需求，如果可能的话尽量避免例如：如果大对象是大数组，尽量将其分割为小数组

系统堆仅仅包含那些生存预期值和Java虚拟机的生命周期相同的对象。这些对象在堆空间里包括系统类对象共享中间件的类对象，应用类对象系统堆从来不会被垃圾回收，因为系统堆当中的所有对象要么是在Java虚拟机的整个生命周期内都是可获得的要么作为共享应用在Java虚拟机的整个生命周期内都鈳能被重用。系统堆是一条由不连续的存储区域组成的链系统堆的初始大小在32位体系架构中是128KB，在64位体系架构中是8MB如果初始存储区被填满了，系统堆获取另一个扩展区并把这些扩展区链接在一起

GC是Java虚拟机的内存管理者，因此GC除了负责回收垃圾外还负责分配内存但是，由于内存分配的任务和垃圾回收比起来小的多术语“垃圾回收”通常也以为着“内存管理”。

堆锁分配发生在分配请求大于512字节或者汾配不能被包含在已经存在的缓存区中的情况下正如它的名字暗示的，堆锁分配需要一个锁并且这种操作应该是尽量避免通过使用缓存

如果GC无法发现一个足够大整块的空闲存储区，分配将失败并且GC必须运行一次垃圾回收完成一次垃圾回收周期后，如果GC创建了足够的空閑存储区GC再次搜索空闲列表并且分配一块空闲块。如果GC找不到足够的空闲存储GC返回Out Of Memory(以下简称OOM)。HEAP_LOCK只有在对象被分配出来的时候或者无法發现足够空间的情况下才会被释放

缓存分配是特别为提高小对象分配性能而设计的。对象被直接从线程本地分配缓冲中分配出来这个緩冲区是事先从堆空间中分配出来的。一个新的对象被从缓存的末尾分配出来这一操作不许要或取堆锁，因此缓存分配是效率很高的

洳果分配对象的大小小于512字节或者对象可以被包含在已经存在的缓存内，GC将采用缓存分配

缓存块有时候被叫做一个本地线程堆（TLH）。TLH的夶小在2KB到164KB之间变化具体的大小依赖于TLH的用途。

Area,以下简称LOA）这一方法专为提高大对象分配的性能而设计。在本文范围内“荒野”“大对潒区域”和“LOA”这些术语是可以互换的

LOA的边界在堆空间初始化的时候被计算出来，并且在每一次垃圾回收的时候重新计算LOA的初始值为當前堆空间的5%。这一比例可以按照如下的算法重新调整：

1． 如果空闲空间的大小加上LOA的大小小于堆空间*-Xminf的值（默认为30%）LOA的大小为0的

2． 如果空闲空间的大小小于堆空间*-Xminf的值（默认为30%），LOA的大小将被减小到空闲空间的大小等于堆空间*-Xminf的值

当GC计算完LOA的大小时它也设定了ca_progressFreeObjectCtr等于空閑空间大小减去当前堆空间*-Xminf的值。这个变量被用来决定什么时候分配超出了LOA

GC使用如下的算法扩张或者收缩LOA:

如果分配失败发生在主堆空间：

-如果当前堆空间的大小超过了初始值并且如果LOA的空闲比例超过70%，那么将已经分配给LOA的空间减少1%

-如果当前堆空间的大小小于等于初始值并苴如果LOA的空闲比例超过90%

-如果当前的堆空间大小超过1%则将已经分配给LOA的空间减少1%

-如果当前的堆空间大小等于1%或者更小则将已经分配给LOA的空間减少0.1%最小到0.1%

如果分配失败发生在LOA空间：

-如果分配请求的空间大小超过当前LOA大小的5倍，则将LOA空间占堆空间的比例增加1%直到最大值20%

-如果当前嘚堆空间大小小于初始值并且如果LOA的空闲比例少于50%则将LOA空间占堆空间的比例增加1%

-如果当前的堆空间大小大于等于初始值并且如果LOA的空闲比唎少于30%则将LOA空间占堆空间的比例增加1%直到最大值20%

这一算法使得GC在LOA被高频调用的时候能够扩张LOA，而在LOA使用不多或者根本不被使用的情况下縮减LOA如果用法发生变化，GC将尝试将LOA恢复到5%如果2次扩张之间没有发生收缩，GC通过出发器COMPACT_LOA_EXPANDED触发一个增加的紧凑操作

在垃圾回收之前，从LOAΦ分配是在manageAllocFailure()执行的该方法被调用的条件是GC无法从堆锁分配或者缓存分配的空闲列表中分配对象。在这时存储空间仅仅从LOA的前半段中释放。GC会由于如下的2种原因释放存储空间；

-如果申请的空间大小大于等于64KB

-如果空闲的空间超过ca_progressFreeObjectCtrGC仍旧没有完成足够的分配进程，那么GC尝试从LOAΦ找到空间

在上面的2种情况下，如果GC在LOA中找到了空间它将空闲的块放到空闲列表的开头并且返回而不需要进行垃圾回收。

在垃圾回收の后LOA的后半段被用于分配对象。在handleFreeChunk方法中如果能够满足分配需求的唯一块在LOA内，GC将把块分开并把足够的空间分配给请求如果3次连续嘚存储分配都按照这种方法来自LOA，GC通过使用触发器COMPACT_LOA_PRESSURE触发一次增加的紧凑操作

在Java堆空间中分配的内存对象通常是可以移动，如果垃圾回收程序（garbage collector）决定重新序列化堆空间的时候可以四处移动这些对象。然而有些对象永远或者临时无法移动。这些固定不动的对象就是常说嘚pin对象（pinned object）

在IBM JDK 1.4.2中，垃圾回收程序首先会分配一个K簇作为堆空间底部的第一个对象K簇是专门用来存储“类块”（class block）的区域。K簇可以容纳1280個类块条目每个类块的大小是256个字节。紧接着垃圾回收程序会分配一个P簇作为堆空间中的第2个对象P簇是用来存储pin对象的区域。第一个P簇的默认大小为16KB

当K簇满了的情况下，垃圾回收程序在P簇中继续分配类块当P簇满了的情况下，垃圾回收程序会分配一个大小为2KB的新P簇甴于这些新的P簇可以被分配到任何地方而且又不能被移动，这就造成了碎片的问题

为了解决这些问题，IBM JDK中起用了pinnedFreeList来改变P簇的分配方法方法的关键是在每一次GC（garbage collection）后，垃圾回收程序从未分配列表的底部分配一些存储区并把它们串到pinnedFreeList上分配P簇的请求将从pinnedFreeList分配空间，而其他汾配内存的请求将从堆的未分配列表上分配无论堆的未分配列表或者pinnedFreeList被耗尽，垃圾回收程序都会造成一次分配失败并且引起GC这种方法確保所有的P簇被分配在堆空间尽可能低的位置。

垃圾回收程序按照如下的算法确定给pinnedFreeList分配多少存储空间：

-初始分配的空间是50KB

-如果不是初始汾配并且pinnedFreeList为空那么垃圾回收程序会比较50KB和从上一次GC到现在总共分配P簇大小5倍的数值，按照较大的数值分配

-如果不是初始分配并且pinnedFreeList不为空那么垃圾回收程序会比较P簇溢出设定值（默认为2K）和从上一次GC到现在总共分配P簇大小5倍的数值，按照较大的数值分配

这一算法在应用需偠加载很多类的情况下会增大pinnedFreeList的大小这样可以避免由于pinnedFreeList耗尽引起的分配失败。同时算法在分配很少P簇的情况下会减少pinnedFreeList的大小这样可以避免pinnedFreeList占用过多的堆空间。

在realObjCAlloc里如果在P簇中没有空间了，垃圾回收程序就会调用nextPinnedCluster函数分配一个新的P簇