http://www.cnblogs.com/balaamwe/archive/2011/12/7.html
http://www.iteye.com/topic/976522
目录
内存管理简介
GC简介
好的Collector的特性
设计或选择Collector
GC性能指标
分代GC
Java Collector
快速内存分配
GC根集合
Serial Collector
Parallel Collector/Throughput Collector
Parallel Compacting Collector
Concurrent Mark Sweep Collector (CMS)
4种Collector的对比和适用场景。
Ergonomics
GC调优
OutOfMemoryError
freeMemory(),totalMemory(),maxMemory()
jmap工具的使用
内存管理简介
内存管理的职责为分配内存，回收内存。
没有自动内存管理的语言/平台容易发生错误。
典型的问题包括悬挂指针问题，一个指针引用了一个已经被回收的内存地址，导致程序的运行完全不可知。
另一个典型问题为内存泄露，内存已经分配，但是已经没有了指向该内存的指针，导致内存泄露。
程序员要花费大量时间在调试该类问题上。
GC简介
因此引入了Garbage Collector机制，由运行时环境来自动管理内存。
Garbage Collector解决了悬挂指针和内存泄露大部分的问题(不是全部)。
注意Garbage Collector(简称Collector)和Garbage Collection(简称GC)的区别。
Collector的职责：
分配内存。
保证有引用的内存不被释放。
回收没有指针引用的内存。
对象被引用称为活对象，对象没有被引用称为垃圾对象/垃圾/垃圾内存，找到垃圾对象并回收是Collector的一个主要工作，该过程称为GC。
Collector一般使用一个称为堆的内存池来进行内存的分配和回收。
一般的，当堆内存满或者达到一个阀值时，堆内存或者部分堆内存被GC。
好的Collector的特性
保证有引用的对象不被GC。
快速的回收内存垃圾。
在程序运行期间GC要高效，尽量少的影响程序运行。和大部分的计算机问题一样，这是一个关于空间，时间，效率平衡的问题。
避免内存碎片，内存碎片导致占用大量内存的大对象内存申请难以满足。可以采用Compaction技术避免内存碎片。Compaction技术：把活对象移向连续内存区的一端，回收其余的内存以便以后的分配。
良好的扩展性，内存分配和GC在多核机器上不应该成为性能瓶颈。
设计或选择Collector
串行或并行。
串行Collector在多核上也只有一个线程在运行，并行Collector可以同时有多个线程执行GC，但是其算法更复杂。
并发或Stop the World。
Stop the World Collection执行GC时，需要冻住所有内存，因此更简单一些，但是，在GC时，程序是被挂起的。并发GC时，程序和GC同时执行，当然，一般的并发GC算法还是需要一些Stop the World时间。
Compacting or Non-compacting or Copying
Compacting: 去除内存碎片，回收内存慢，分配内存快。
Non-compacting: 容易产生内存碎片，回收内存快，分配内存慢，对大对象内存分配支持不好。
Copying: 复制活对象到新的内存区域，原有内存直接回收，需要额外的时间来做复制，额外的空间来做存储。
GC性能指标
Throughput: 程序时间(不包含GC时间)/总时间。
GC overhead: GC时间/总时间。
Pause time: GC运行时程序挂起时间。
Frequency of GC: GC频率。
Footprint: a measure of size, such as heap size。
Promptness:对象变为垃圾到该垃圾被回收后内存可用的时间。
依赖于不同的场景，对于GC的性能指标的关注点也不一样。
分代GC
分代GC把内存划分为多个代(内存区域)，每个代存储不同年龄的对象。 常见的分为2代，young和old。
分配内存时，先从young代分配，如果young代已满，可以执行GC(可能导致对象提升)，如果有空间，则分配，如果young代还是没有空间，可以对整个内存堆GC。
young代GC后还存活的对象可以提升到old代。
该机制基于以下观察事实：
１ 大部分新分配的对象很快就没有引用了，变成垃圾。
２ 很少有old代对象引用young代对象。
基于代内存存储对象的特性，对不同代的内存可以使用不同的GC算法。
Young代GC需要高效，快速，频繁的执行，关注点主要在速度上。
Old代由于增长缓慢，因此GC不频繁，但是其内存空间比较大，因此，需要更长时间才能执行完GC。关注点在内存空间利用率上。
Java Collector
Jvm的内存分为3代。Young, Old, Permanent。
大部分对象存储在Young代。
在Young代中经历数次GC存活的对象可以提升到Old代，大对象也可以直接分配到Old代。
Permanent代保存虚拟机自己的静态(refective)数据，例如类(class)和方法(method)对象。
Young代由一个Eden和2个survivor组成。大部分的对象的内存分配和回收在这里完成。
Survivor存储至少经过一次GC存活下来的对象，以增大该对象在提升至old代前被回收的机会。2个survivor中有一个为空。分别为From和to survivor。
当young代内存满，执行young代GC(minor GC)。
当old或permanent代内存满，执行full GC(major GC)，所有代都被GC。一般先执行young GC，再执行old, permanent GC。
有时old代太满，以至于如果young GC先运行，则无法存储提升的对象。这时，Young GC不运行，old GC算法在整个堆上运行(CMS collector是个例外，该collector不能运行在young 代上)。
快速内存分配
大部分的内存分配请求发生时，Collector都有一块大的连续内存块，简单的内存大小计算和指针移动就可以分配内存了。因此非常快速。该技术称为bump –the-pointer技术。
对于多线程的内存分配，每个线程使用Thread Local Allocation Buffer(TLAB)进行分配，因此还是很高效。TLAB可以看作一个线程的特殊代。只有TLAB满的时候才需要进行同步操作。
GC根集合
GC运行时当前程序可以直接访问的对象。如线程中当前调用栈的方法参数，局部变量，静态变量，当前线程对象等等。
Collector根据GC根集合来寻找所有活对象。GC根集合不可达对象自然就是垃圾了。
Serial Collector
单线程，Young and old GC是串行,stop the world GC的。
Young GC。
Eden中活对象copy到to survivor中，大对象直接进old代。
From survivor中相对老的活对象进入old代，相对年轻的对象进入to survivor中。
如果to survivor放不下活对象，则这些活对象直接进入old。
经历过young GC，Eden和from survivor都变成空的内存区域，to survivor存储有活的对象。To survivor和from survivor角色互换。
Old permanent GC。
Mark-sweep-compact算法。
S1 标识哪些对象是活的对象。
S2 标识哪些对象是垃圾。
S3 把活的对象压缩到内存的一端，以便可以使用bump –the-pointer处理以后的内存分配请求。
非server-class machine 的默认GC。
也可以使用命令行参数来设定。
-XX:+UseSerialGC
Parallel Collector/Throughput Collector
利用了现代计算机大部分都是多核的事实。
Young GC。
和Serial Collector一样，是一个stop the world和copying Collector。只不过是多线程并行扫描和做copy，提高速度，减少了stop the world的时间，增大了throughput。
Old permanent GC。
和serial collector一样。Mark-sweep-compact算法。单线程。
Server-class machine的默认GC。
也可以使用命令行参数来设定。
-XX:+UseParallelGC
Parallel Compacting Collector
Young GC。
和Parallel Collector一样。
Old Permanent GC。
Stop the world，并且多线程并发GC。
每一代被划分为一些长度固定的区域。
第1步(mark phase)，GC根集合划分后分发给多个GC线程，每个GC线程更新可达活对象所在区域的信息(活对象的内存位置，大小)。
第2步(summary phase)，操作在区域上，而不是对象上。由于以前GC的影响，内存的一端活对象的密度比较高，在该阶段找到一个临界点，该临界点以前的区域由于活对象内存密度高，不参与GC，不做compact。该临界点之后的区域参与GC，做compact。该阶段为单线程执行。
第3步(compact phase)。GC多线程使用summary info做回收和compact工作。
可以设置GC线程数，防止GC线程长时间占有整台机器的资源。
-XX:ParallelGCThreads=n
使用命令行参数来设定。
-XX:+UseParallelOldGC
Concurrent Mark Sweep Collector (CMS)
Young GC。
和Parallel Collector一样。
Old permanent GC。
GC和程序并发执行。
Initial Phase:短暂停，标记GC根集合。单线程执行。
Concurrent marking phase: GC多线程标记从根集合可达的所有活对象。程序和GC并发运行。由于是并发运行，有可能有活对象没有被标记上。
concurrent pre-clean：单线程，并发执行。
Remark phase: 短暂停，多线程标记在Concurrent marking phase中有变化的相关对象。
Concurrent sweep phase:和程序并发执行。单线程执行。不做compacting。
concurrent reset：单线程，并发执行。
CMS不做compacting，不能使用bump-the-pointer技术，只能使用传统的内存空闲链表技术。
导致内存分配变慢，影响了Young代的GC速度，因为Young的GC如果有对象提升的话依赖于Old的内存分配。
CMS需要更多的内存空间，因为mark phase时程序还是在运行，程序可以申请更多的old空间。在mark phase中，CMS保证标识活对象，但是该过程中，活对象可能转变为垃圾，只能等待下一次GC才能回收。
和其他Collector不同，CMS不是等到old满时才GC，基于以前的统计数据(GC时间，Old空间消耗速度)来决定何时GC。CMS GC也可以基于old空间的占用率。
命令行参数：
-XX:CMSInitiatingOccupancyFraction=n,n为百分比，默认68。
可以设置
-XX:+UseCMSInitiatingOccupancyOnly 来使vm只使用old内存占用比来触发CMS GC。
Incremental Mode。
CMS的concurrent phase可以是渐进式执行。以减少程序的一次暂停时间。
命令行参数：
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
4种Collector的对比和适用场景。
直到jdk1.3.1,java只提供Serial Collector，Serial Collector在多核的机器上表现比较差。主要是throughput比较差。
大型应用(大内存，多核)应该选用并行Collector。
Serial Collector:大多数client-style机器。对于低程序暂停时间没有需求的程序。
Parallel Collector:多核机器，对于低程序暂停时间没有需求的程序。
Parallel Compacting Collector:多核机器，对于低程序暂停时间有需求的程序。
CMS Collector:和Parallel Compacting Collector相比，降低了程序暂停时间，但是young GC程序暂停时间变长，需要更大的堆空间，降低了程序的throughput。
Ergonomics
J2SE 5.0后，Collector的选择，堆大小的选择，VM(client还是server)的选择，都可以依赖平台和OS来做自动选择。
JVM会自动选择使用server mode还是client mode。但是我们一样可以手工设置。
java -server -client
Server-class machine的选择：
2个或更多的处理器
And
2G或更多的物理内存
And
不是32bits,windows OS。
Client-class
The client JVM
The serial collector
Initial heap size = 4M
Max heap size=64M
Server-class
The server JVM
The parallel collector
Initial heap size= 1/64物理内存(>=32M)，最大1G。
Max heap size=1/4物理内存，最大1G。
基于行为的调优。
可以基于最大暂停时间或throughput。
-XX:MaxGCPauseMillis=n
指示vm调整堆大小和其他参数来满足这个时间需求。如果vm不满足该目标，则减小堆大小来满足该目标。该目标没有默认值。
-XX:GCTimeRatio=n
GC time/APP time=1/(1+n)
如n=99表示GC时间占整个运行时间的1%。
如果该目标不能满足，则增大堆大小来满足该目标。默认值n=99。
Footprint Goal
如果最大暂停时间和Throughput目标都满足了，则减少堆大小直到有一个目标不满足，然后又回调。
目标优先级：
最大暂停时间>Throughput>footprint。
GC调优
由于有了Ergonomics，第一个建议就是不要手工去配置各种参数。让系统自己去根据平台和OS来选择。然后观测性能，如果OK的话，呵呵，不用搞了。
但是Ergonomics也不是万能的。因此还是需要程序员来手工搞。
注意性能问题一定要测量/调优/测量/调优不停的循环下去。
Vm mode 选择。
Java -server server mode.
Java -client client mode.
观测性能主要使用gc的统计信息。
-XX:+PrintGC 输出GC信息。
-XX:+PrintGCDetails输出GC详细信息。
-XX:+PrintGCTimeStamps 输出时间戳，和–XX:+PrintGC 或–XX:+PrintGCDetails一起使用。
-Xloggc: gc.log 输出到指定文件。
1 决定堆内存大小。
决定整个堆内存的大小。内存的大小对于Collector的性能影响是最大的。
使用以下参数来决定堆内存的大小。
可以决定堆空间的起始值和最大值，大型程序可以考虑把起始值调大，避免程序启动时频繁GC和内存扩展申请。
以及堆空间中可用内存的比例范围，vm会动态管理堆内存来满足该比例范围。
-XX:MinHeapFreeRatio=n
-XX:MaxHeapFreeRatio=n
-Xmsn Young和Old的起始内存
-Xmxn Young和Old的最大内存
2 决定代空间大小。
Young代空间越大，则minor GC的频率越小。但是，给定堆内存大小，Young代空间大，则major GC频率变大。
如果没有过多的Full GC或者过长的暂停时间问题，给young代尽量大的空间。
Young Generation Guarantee。
对于serial collector，当执行minor GC时，必须保证old代中有可用的空间来处理最坏情况(即eden和survivor空间中的对象都是活对象，需要提升至old空间)，如果不满足，则该minor GC触发major GC。所以对于serial collector，设置eden+survivor的内存不要大过old代内存。
其他collector不做该保证，只有old代无法存储提升对象时才触发major GC。
对于其他collector，由于多线程做minor GC时，考虑到最坏情况，每个线程要在old代内存预留一定空间做对象提升，因此可能导致内存碎片。因此old代内存应该调整的更大一些。
-XX:NewSize=n young代空间下限。
-XX:MaxNewSize=n young代空间上限。
-XX:NewRatio=n young和old代的比例。
-XX:SurvivorRatio=n Eden和单个survivor的比例。
-XX:PermSize=n Permanent起始值。
-XX:MaxPermSize=n Permanent最大值。
3 决定使用Collector
可以考虑是否需要换一个Collector。
Collector选择
-XX:+UseSerialGC Serial
-XX:+UseParallelGC Parallel
-XX:+UseParallelOldGC Parallel compacting
-XX:+UseConcMarkSweepGC Concurrent mark–sweep (CMS)
Parallel和Parallel Compacting Collector.
-XX:ParallelGCThreads=n
-XX:MaxGCPauseMillis=n
-XX:GCTimeRatio=n
设定目标好于明确设定参数值。
为了增大Throughput，堆大小需要变大。可以把堆大小设为物理内存允许的最大值(同时程序不swapping)来检测该环境可以支持的最大throughput。
为了减小最大暂停时间和footprint，堆大小需要变小。
2个目标有一定的矛盾，因此要视具体应用场景，做平衡。
CMS Collector
-XX:+CMSIncrementalMode 和CMS同时使用。
-XX:+CMSIncrementalPacing 和CMS同时使用。
-XX:ParallelGCThreads=n
-XX:CMSInitiatingOccupancyFraction=n,n为百分比，默认68。
OutOfMemoryError
可以指定
-XX:+HeapDumpOnOutOfMemoryError
当发生OutOfMemoryError时dump出堆内存。
发生OutOfMemoryError时可以观测该Error的详细信息。
Java heap space：
调整堆大小。
程序中含有大量带有finalize方法的对象。执行finalize方法的线程顶不住了。
PermGen space:
Permanent代内存不够用了。
Requested array size exceeds VM limit。
堆内存不够用。
程序bug，一次分配太多内存。
freeMemory(),totalMemory(),maxMemory()
java.lang.Runtime类中的 freeMemory(), totalMemory(), maxMemory()这几个方法的反映的都是 java这个进程的内存情况，跟操作系统的内存根本没有关系。
maxMemory()这个方法返回的是java虚拟机(这个进程)能构从操作系统那里挖到的最大的内存，以字节为单位，如果在运行java程序的时 候，没有添加-Xmx参数，那么就是jvm默认的可以使用内存大小，client为64M，server为1G。如果添加了-Xmx参数，将以这个参数后面的值为准。
totalMemory()这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小，也就是java虚拟机这个进程当时所占用的所有内存。如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，直 到挖到maxMemory()为止，所以totalMemory()是慢慢增大的。如果用了-Xms参数，程序在启动的时候就会无条件的从操作系统中挖 -Xms后面定义的内存数，然后在这些内存用的差不多的时候，再去挖。
freeMemory()是什么呢，刚才讲到如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操 作系统那里挖的，基本上是用多少挖多少，但是java虚拟机100％的情况下是会稍微多挖一点的，这些挖过来而又没有用上的内存，实际上就是 freeMemory()，所以freeMemory()的值一般情况下都是很小的，但是如果你在运行java程序的时候使用了-Xms，这个时候因为程 序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数，这个时候，挖过来的内存可能大部分没用上，所以这个时候freeMemory()可能会有些大。
jmap工具的使用
jmap pid 查看共享对象。
jmap -heap pid 查看java进程堆的相关信息。
- $ jmap -heap 5695
- Attaching to process ID 5695, please wait...
- Debugger attached successfully.
- Server compiler detected.
- JVM version is 17.0-b16
-
- using parallel threads in the new generation.
- using thread-local object allocation.
- Concurrent Mark-Sweep GC
-
- Heap Configuration:
- MinHeapFreeRatio = 40
- MaxHeapFreeRatio = 70
- MaxHeapSize = 1342177280 (1280.0MB)
- NewSize = 134217728 (128.0MB)
- MaxNewSize = 134217728 (128.0MB)
- OldSize = 4194304 (4.0MB)
- NewRatio = 2
- SurvivorRatio = 20000
- PermSize = 100663296 (96.0MB)
- MaxPermSize = 134217728 (128.0MB)
-
- Heap Usage:
- New Generation (Eden + 1 Survivor Space):
- capacity = 134152192 (127.9375MB)
- used = 34518744 (32.919639587402344MB)
- free = 99633448 (95.01786041259766MB)
- 25.731032408326207% used
- Eden Space:
- capacity = 134086656 (127.875MB)
- used = 34518744 (32.919639587402344MB)
- free = 99567912 (94.95536041259766MB)
- 25.743608670500368% used
- From Space:
- capacity = 65536 (0.0625MB)
- used = 0 (0.0MB)
- free = 65536 (0.0625MB)
- 0.0% used
- To Space:
- capacity = 65536 (0.0625MB)
- used = 0 (0.0MB)
- free = 65536 (0.0625MB)
- 0.0% used
- concurrent mark-sweep generation:
- capacity = 671088640 (640.0MB)
- used = 287118912 (273.81793212890625MB)
- free = 383969728 (366.18206787109375MB)
- 42.7840518951416% used
- Perm Generation:
- capacity = 100663296 (96.0MB)
- used = 41864504 (39.92510223388672MB)
- free = 58798792 (56.07489776611328MB)
- 41.58864816029867% used
jmap –histo pid 查询各种对象占用的内存大小。
- $ jmap -histo 5695 | less
-
- num #instances #bytes class name
- ----------------------------------------------
- 1: 320290 63305456 [C
- 2: 1457010 46624320 java.util.concurrent.ConcurrentHashMap$Segment
- 3: 1502500 36060000 java.util.concurrent.locks.ReentrantLock$NonfairSync
- 4: 87785 29987632 [I
- 5: 1457010 23638928 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
- 6: 285668 15240784 [Ljava.lang.Object;
- 7: 87239 10680160 <constMethodKlass>
- 8: 399482 9587568 java.lang.String
- 9: 16533 7466624 [B
- 10: 91065 7285072 [Ljava.util.concurrent.ConcurrentHashMap$Segment;
- 11: 87239 6983288 <methodKlass>
- 12: 125750 5868720 <symbolKlass>
- 13: 45409 5449080 java.net.SocksSocketImpl
- 14: 63574 4936176 [S
- 15: 45294 4710576 sun.nio.ch.SocketChannelImpl
jmap –permstat pid 查看Class Loader。
jmap –dump:file=filename,format=b pid dump内存到文件。
可以使用MAT工具分析java dump文件。
http://www.open-open.com/lib/view/open1322743689780.html
Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙，墙外面的人想进去，墙里面的人却想出来。
概述：
说起垃圾收集（Garbage Collection，下文简称GC），大部分人都把这项技术当做Java语言的伴生产物。事实上GC的历史远远比Java来得久远，在1960年诞生于 MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期，人们就在思考GC需要完成的3件事情：哪些内存需要回收？什么时候回收？怎么样回收？
经过半个世纪的发展，目前的内存分配策略与垃圾回收技术已经相当成熟，一切看起来都进入“自动化”的时代，那为什么我们还要去了解GC和内存分配？答案很简单：当需要排查各种内存溢出、泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术有必要的监控、调节手段。
把时间从1960年拨回现在，回到我们熟悉的Java语言。本文第一章中介绍了Java内存运行时区域的各个部分，其中程序计数器、VM栈、本地方法栈三个区域随线程而生，随线程而灭；栈中的帧随着方法进入、退出而有条不紊的进行着出栈入栈操作；每一个帧中分配多少内存基本上是在Class文件生成时就已知的（可能会由JIT动态晚期编译进行一些优化，但大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收具备很高的确定性，因此在这几个区域不需要过多考虑回收的问题。而Java堆和方法区（包括运行时常量池）则不一样，我们必须等到程序实际运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，我们本文后续讨论中的“内存”分配与回收仅仅指这一部分内存。
对象已死？
在堆里面存放着Java世界中几乎所有的对象，在回收前首先要确定这些对象之中哪些还在存活，哪些已经“死去”了，即不可能再被任何途径使用的对象。
引用计数算法（Reference Counting）
最初的想法，也是很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，当有一个地方引用它，计数器加1，当引用失效，计数器减1，任何时刻计数器为0的对象就是不可能再被使用的。
客观的说，引用计数算法实现简单，判定效率很高，在大部分情况下它都是一个不错的算法，但引用计数算法无法解决对象循环引用的问题。举个简单的例子：对象 A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对象已经不可能再被访问，但是引用计数算法却无法回收他们。
根搜索算法（GC Roots Tracing）
在实际生产的语言中（Java、C#、甚至包括前面提到的Lisp），都是使用根搜索算法判定对象是否存活。算法基本思路就是通过一系列的称为“GC Roots”的点作为起始进行向下搜索，当一个对象到GC Roots没有任何引用链（Reference Chain）相连，则证明此对象是不可用的。在Java语言中，GC Roots包括：
1.在VM栈（帧中的本地变量）中的引用
2.方法区中的静态引用
3.JNI（即一般说的Native方法）中的引用
生存还是死亡？
判定一个对象死亡，至少经历两次标记过程：如果对象在进行根搜索后，发现没有与GC Roots相连接的引用链，那它将会被第一次标记，并在稍后执行他的finalize()方法（如果它有的话）。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这点是必须的，否则一个对象在finalize()方法执行缓慢，甚至有死循环什么的将会很容易导致整个系统崩溃。 finalize()方法是对象最后一次逃脱死亡命运的机会，稍后GC将进行第二次规模稍小的标记，如果在finalize()中对象成功拯救自己（只要重新建立到GC Roots的连接即可，譬如把自己赋值到某个引用上），那在第二次标记时它将被移除出“即将回收”的集合，如果对象这时候还没有逃脱，那基本上它就真的离死不远了。
需要特别说明的是，这里对finalize()方法的描述可能带点悲情的艺术加工，并不代表笔者鼓励大家去使用这个方法来拯救对象。相反，笔者建议大家尽量避免使用它，这个不是C/C++里面的析构函数，它运行代价高昂，不确定性大，无法保证各个对象的调用顺序。需要关闭外部资源之类的事情，基本上它能做的使用try-finally可以做的更好。
关于方法区
方法区即后文提到的永久代，很多人认为永久代是没有GC的，《Java虚拟机规范》中确实说过可以不要求虚拟机在这区实现GC，而且这区GC的“性价比” 一般比较低：在堆中，尤其是在新生代，常规应用进行一次GC可以一般可以回收70%~95%的空间，而永久代的GC效率远小于此。虽然VM Spec不要求，但当前生产中的商业JVM都有实现永久代的GC，主要回收两部分内容：废弃常量与无用类。这两点回收思想与Java堆中的对象回收很类似，都是搜索是否存在引用，常量的相对很简单，与对象类似的判定即可。而类的回收则比较苛刻，需要满足下面3个条件：
1.该类所有的实例都已经被GC，也就是JVM中不存在该Class的任何实例。
2.加载该类的ClassLoader已经被GC。
3.该类对应的java.lang.Class 对象没有在任何地方被引用，如不能在任何地方通过反射访问该类的方法。
是否对类进行回收可使用-XX:+ClassUnloading参数进行控制，还可以使用-verbose:class或者-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载、卸载信息。
在大量使用反射、动态代理、CGLib等bytecode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要JVM具备类卸载的支持以保证永久代不会溢出。
垃圾收集算法
在这节里不打算大量讨论算法实现，只是简单的介绍一下基本思想以及发展过程。最基础的搜集算法是“标记－清除算法”（Mark-Sweep），如它的名字一样，算法分层“标记”和“清除”两个阶段，首先标记出所有需要回收的对象，然后回收所有需要回收的对象，整个过程其实前一节讲对象标记判定的时候已经基本介绍完了。说它是最基础的收集算法原因是后续的收集算法都是基于这种思路并优化其缺点得到的。它的主要缺点有两个，一是效率问题，标记和清理两个过程效率都不高，二是空间问题，标记清理之后会产生大量不连续的内存碎片，空间碎片太多可能会导致后续使用中无法找到足够的连续内存而提前触发另一次的垃圾搜集动作。
为了解决效率问题，一种称为“复制”（Copying）的搜集算法出现，它将可用内存划分为两块，每次只使用其中的一块，当半区内存用完了，仅将还存活的对象复制到另外一块上面，然后就把原来整块内存空间一次过清理掉。这样使得每次内存回收都是对整个半区的回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存就可以了，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。
现在的商业虚拟机中都是用了这一种收集算法来回收新生代，IBM有专门研究表明新生代中的对象98%是朝生夕死的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的eden空间和2块较少的survivor空间，每次使用eden和其中一块survivor，当回收时将eden和 survivor还存活的对象一次过拷贝到另外一块survivor空间上，然后清理掉eden和用过的survivor。Sun Hotspot虚拟机默认eden和survivor的大小比例是8:1，也就是每次只有10%的内存是“浪费”的。当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有10%以内的对象存活，当survivor空间不够用时，需要依赖其他内存（譬如老年代）进行分配担保（Handle Promotion）。
复制收集算法在对象存活率高的时候，效率有所下降。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保用于应付半区内存中所有对象都 100%存活的极端情况，所以在老年代一般不能直接选用这种算法。因此人们提出另外一种“标记－整理”（Mark-Compact）算法，标记过程仍然一样，但后续步骤不是进行直接清理，而是令所有存活的对象一端移动，然后直接清理掉这端边界以外的内存。
当前商业虚拟机的垃圾收集都是采用“分代收集”（Generational Collecting）算法，这种算法并没有什么新的思想出现，只是根据对象不同的存活周期将内存划分为几块。一般是把Java堆分作新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法，譬如新生代每次GC都有大批对象死去，只有少量存活，那就选用复制算法只需要付出少量存活对象的复制成本就可以完成收集。
垃圾收集器
垃圾收集器就是收集算法的具体实现，不同的虚拟机会提供不同的垃圾收集器。并且提供参数供用户根据自己的应用特点和要求组合各个年代所使用的收集器。本文讨论的收集器基于Sun Hotspot虚拟机1.6版。
图1.Sun JVM1.6的垃圾收集器
图1展示了1.6中提供的6种作用于不同年代的收集器，两个收集器之间存在连线的话就说明它们可以搭配使用。在介绍着些收集器之前，我们先明确一个观点：没有最好的收集器，也没有万能的收集器，只有最合适的收集器。
1.Serial收集器
单线程收集器，收集时会暂停所有工作线程（我们将这件事情称之为Stop The World，下称STW），使用复制收集算法，虚拟机运行在Client模式时的默认新生代收集器。
2.ParNew收集器
ParNew收集器就是Serial的多线程版本，除了使用多条收集线程外，其余行为包括算法、STW、对象分配规则、回收策略等都与Serial收集器一摸一样。对应的这种收集器是虚拟机运行在Server模式的默认新生代收集器，在单CPU的环境中，ParNew收集器并不会比Serial收集器有更好的效果。
3.Parallel Scavenge收集器
Parallel Scavenge收集器（下称PS收集器）也是一个多线程收集器，也是使用复制算法，但它的对象分配规则与回收策略都与ParNew收集器有所不同，它是以吞吐量最大化（即GC时间占总运行时间最小）为目标的收集器实现，它允许较长时间的STW换取总吞吐量最大化。
4.Serial Old收集器
Serial Old是单线程收集器，使用标记－整理算法，是老年代的收集器，上面三种都是使用在新生代收集器。
5.Parallel Old收集器
老年代版本吞吐量优先收集器，使用多线程和标记－整理算法，JVM 1.6提供，在此之前，新生代使用了PS收集器的话，老年代除Serial Old外别无选择，因为PS无法与CMS收集器配合工作。
6.CMS（Concurrent Mark Sweep）收集器
CMS是一种以最短停顿时间为目标的收集器，使用CMS并不能达到GC效率最高（总体GC时间最小），但它能尽可能降低GC时服务的停顿时间，这一点对于实时或者高交互性应用（譬如证券交易）来说至关重要，这类应用对于长时间STW一般是不可容忍的。CMS收集器使用的是标记－清除算法，也就是说它在运行期间会产生空间碎片，所以虚拟机提供了参数开启CMS收集结束后再进行一次内存压缩。
内存分配与回收策略
了解GC其中很重要一点就是了解JVM的内存分配策略：即对象在哪里分配和对象什么时候回收。
关于对象在哪里分配，往大方向讲，主要就在堆上分配，但也可能经过JIT进行逃逸分析后进行标量替换拆散为原子类型在栈上分配，也可能分配在 DirectMemory中（详见本文第一章）。往细节处讲，对象主要分配在新生代eden上，也可能会直接老年代中，分配的细节决定于当前使用的垃圾收集器类型与VM相关参数设置。我们可以通过下面代码来验证一下Serial收集器（ParNew收集器的规则与之完全一致）的内存分配和回收的策略。读者看完Serial收集器的分析后，不妨自己根据JVM参数文档写一些程序去实践一下其它几种收集器的分配策略。
清单1：内存分配测试代码
- public class YoungGenGC {
-
- private static final int _1MB = 1024 * 1024;
-
- public static void main(String[] args) {
- // testAllocation();
- testHandlePromotion();
- // testPretenureSizeThreshold();
- // testTenuringThreshold();
- // testTenuringThreshold2();
- }
-
- /**
- * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
- */
- @SuppressWarnings("unused")
- public static void testAllocation() {
- byte[] allocation1, allocation2, allocation3, allocation4;
- allocation1 = new byte[2 * _1MB];
- allocation2 = new byte[2 * _1MB];
- allocation3 = new byte[2 * _1MB];
- allocation4 = new byte[4 * _1MB]; // 出现一次Minor GC
- }
-
- /**
- * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
- * -XX:PretenureSizeThreshold=3145728
- */
- @SuppressWarnings("unused")
- public static void testPretenureSizeThreshold() {
- byte[] allocation;
- allocation = new byte[4 * _1MB]; //直接分配在老年代中
- }
-
- /**
- * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
- * -XX:+PrintTenuringDistribution
- */
- @SuppressWarnings("unused")
- public static void testTenuringThreshold() {
- byte[] allocation1, allocation2, allocation3;
- allocation1 = new byte[_1MB / 4]; // 什么时候进入老年代决定于XX:MaxTenuringThreshold设置
- allocation2 = new byte[4 * _1MB];
- allocation3 = new byte[4 * _1MB];
- allocation3 = null;
- allocation3 = new byte[4 * _1MB];
- }
-
- /**
- * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15
- * -XX:+PrintTenuringDistribution
- */
- @SuppressWarnings("unused")
- public static void testTenuringThreshold2() {
- byte[] allocation1, allocation2, allocation3, allocation4;
- allocation1 = new byte[_1MB / 4]; // allocation1+allocation2大于survivo空间一半
- allocation2 = new byte[_1MB / 4];
- allocation3 = new byte[4 * _1MB];
- allocation4 = new byte[4 * _1MB];
- allocation4 = null;
- allocation4 = new byte[4 * _1MB];
- }
-
- /**
- * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:-HandlePromotionFailure
- */
- @SuppressWarnings("unused")
- public static void testHandlePromotion() {
- byte[] allocation1, allocation2, allocation3, allocation4, allocation5, allocation6, allocation7;
- allocation1 = new byte[2 * _1MB];
- allocation2 = new byte[2 * _1MB];
- allocation3 = new byte[2 * _1MB];
- allocation1 = null;
- allocation4 = new byte[2 * _1MB];
- allocation5 = new byte[2 * _1MB];
- allocation6 = new byte[2 * _1MB];
- allocation4 = null;
- allocation5 = null;
- allocation6 = null;
- allocation7 = new byte[2 * _1MB];
- }
- }
规则一：通常情况下，对象在eden中分配。当eden无法分配时，触发一次Minor GC。
执行testAllocation()方法后输出了GC日志以及内存分配状况。-Xms20M -Xmx20M -Xmn10M这3个参数确定了Java堆大小为20M，不可扩展，其中10M分配给新生代，剩下的10M即为老年代。 -XX:SurvivorRatio=8决定了新生代中eden与survivor的空间比例是1：8，从输出的结果也清晰的看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216K（eden+1个survivor）。
我们也注意到在执行testAllocation()时出现了一次Minor GC，GC的结果是新生代6651K变为148K，而总占用内存则几乎没有减少（因为几乎没有可回收的对象）。这次GC是发生的原因是为 allocation4分配内存的时候，eden已经被占用了6M，剩余空间已不足分配allocation4所需的4M内存，因此发生Minor GC。GC期间虚拟机发现已有的3个2M大小的对象全部无法放入survivor空间（survivor空间只有1M大小），所以直接转移到老年代去。 GC后4M的allocation4对象分配在eden中。
清单2：testAllocation()方法输出结果
[GC [DefNew: 6651K->148K(9216K), 0.0070106 secs] 6651K->6292K(19456K), 0.0070426 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4326K [0x029d0000, 0x033d0000, 0x033d0000)
eden space 8192K, 51% used [0x029d0000, 0x02de4828, 0x031d0000)
from space 1024K, 14% used [0x032d0000, 0x032f5370, 0x033d0000)
to space 1024K, 0% used [0x031d0000, 0x031d0000, 0x032d0000)
tenured generation total 10240K, used 6144K [0x033d0000, 0x03dd0000, 0x03dd0000)
the space 10240K, 60% used [0x033d0000, 0x039d0030, 0x039d0200, 0x03dd0000)
compacting perm gen total 12288K, used 2114K [0x03dd0000, 0x049d0000, 0x07dd0000)
the space 12288K, 17% used [0x03dd0000, 0x03fe0998, 0x03fe0a00, 0x049d0000)
No shared spaces configured.
规则二：配置了PretenureSizeThreshold的情况下，对象大于设置值将直接在老年代分配。
执行testPretenureSizeThreshold()方法后，我们看到eden空间几乎没有被使用，而老年代的10M控件被使用了40%，也就是4M的allocation对象直接就分配在老年代中，则是因为PretenureSizeThreshold被设置为3M，因此超过3M的对象都会直接从老年代分配。
清单3：
Heap
def new generation total 9216K, used 671K [0x029d0000, 0x033d0000, 0x033d0000)
eden space 8192K, 8% used [0x029d0000, 0x02a77e98, 0x031d0000)
from space 1024K, 0% used [0x031d0000, 0x031d0000, 0x032d0000)
to space 1024K, 0% used [0x032d0000, 0x032d0000, 0x033d0000)
tenured generation total 10240K, used 4096K [0x033d0000, 0x03dd0000, 0x03dd0000)
the space 10240K, 40% used [0x033d0000, 0x037d0010, 0x037d0200, 0x03dd0000)
compacting perm gen total 12288K, used 2107K [0x03dd0000, 0x049d0000, 0x07dd0000)
the space 12288K, 17% used [0x03dd0000, 0x03fdefd0, 0x03fdf000, 0x049d0000)
No shared spaces configured.
规则三：在eden经过GC后存活，并且survivor能容纳的对象，将移动到survivor空间内，如果对象在survivor中继续熬过若干次回收（默认为15次）将会被移动到老年代中。回收次数由MaxTenuringThreshold设置。
分别以-XX:MaxTenuringThreshold=1和-XX:MaxTenuringThreshold=15两种设置来执行 testTenuringThreshold()，方法中allocation1对象需要256K内存，survivor空间可以容纳。当 MaxTenuringThreshold=1时，allocation1对象在第二次GC发生时进入老年代，新生代已使用的内存GC后非常干净的变成 0KB。而MaxTenuringThreshold=15时，第二次GC发生后，allocation1对象则还留在新生代survivor空间，这时候新生代仍然有404KB被占用。
清单4：
MaxTenuringThreshold=1
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age 1: 414664 bytes, 414664 total
: 4859K->404K(9216K), 0.0065012 secs] 4859K->4500K(19456K), 0.0065283 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
: 4500K->0K(9216K), 0.0009253 secs] 8596K->4500K(19456K), 0.0009458 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4178K [0x029d0000, 0x033d0000, 0x033d0000)
eden space 8192K, 51% used [0x029d0000, 0x02de4828, 0x031d0000)
from space 1024K, 0% used [0x031d0000, 0x031d0000, 0x032d0000)
to space 1024K, 0% used [0x032d0000, 0x032d0000, 0x033d0000)
tenured generation total 10240K, used 4500K [0x033d0000, 0x03dd0000, 0x03dd0000)
the space 10240K, 43% used [0x033d0000, 0x03835348, 0x03835400, 0x03dd0000)
compacting perm gen total 12288K, used 2114K [0x03dd0000, 0x049d0000, 0x07dd0000)
the space 12288K, 17% used [0x03dd0000, 0x03fe0998, 0x03fe0a00, 0x049d0000)
No shared spaces configured.
MaxTenuringThreshold=15
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 1: 414664 bytes, 414664 total
: 4859K->404K(9216K), 0.0049637 secs] 4859K->4500K(19456K), 0.0049932 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 2: 414520 bytes, 414520 total
: 4500K->404K(9216K), 0.0008091 secs] 8596K->4500K(19456K), 0.0008305 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4582K [0x029d0000, 0x033d0000, 0x033d0000)
eden space 8192K, 51% used [0x029d0000, 0x02de4828, 0x031d0000)
from space 1024K, 39% used [0x031d0000, 0x03235338, 0x032d0000)
to space 1024K, 0% used [0x032d0000, 0x032d0000, 0x033d0000)
tenured generation total 10240K, used 4096K [0x033d0000, 0x03dd0000, 0x03dd0000)
the space 10240K, 40% used [0x033d0000, 0x037d0010, 0x037d0200, 0x03dd0000)
compacting perm gen total 12288K, used 2114K [0x03dd0000, 0x049d0000, 0x07dd0000)
the space 12288K, 17% used [0x03dd0000, 0x03fe0998, 0x03fe0a00, 0x049d0000)
No shared spaces configured.
规则四：如果在survivor空间中相同年龄所有对象大小的累计值大于survivor空间的一半，大于或等于个年龄的对象就可以直接进入老年代，无需达到MaxTenuringThreshold中要求的年龄。
执行testTenuringThreshold2()方法，并将设置-XX:MaxTenuringThreshold=15，发现运行结果中 survivor占用仍然为0%，而老年代比预期增加了6%，也就是说allocation1、allocation2对象都直接进入了老年代，而没有等待到15岁的临界年龄。因为这2个对象加起来已经到达了512K，并且它们是同年的，满足同年对象达到survivor空间的一半规则。我们只要注释掉其中一个对象new操作，就会发现另外一个就不会晋升到老年代中去了。
清单5：
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age 1: 676824 bytes, 676824 total
: 5115K->660K(9216K), 0.0050136 secs] 5115K->4756K(19456K), 0.0050443 secs] [Times: user=0.00 sys=0.01, real=0.01 secs]
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
: 4756K->0K(9216K), 0.0010571 secs] 8852K->4756K(19456K), 0.0011009 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4178K [0x029d0000, 0x033d0000, 0x033d0000)
eden space 8192K, 51% used [0x029d0000, 0x02de4828, 0x031d0000)
from space 1024K, 0% used [0x031d0000, 0x031d0000, 0x032d0000)
to space 1024K, 0% used [0x032d0000, 0x032d0000, 0x033d0000)
tenured generation total 10240K, used 4756K [0x033d0000, 0x03dd0000, 0x03dd0000)
the space 10240K, 46% used [0x033d0000, 0x038753e8, 0x03875400, 0x03dd0000)
compacting perm gen total 12288K, used 2114K [0x03dd0000, 0x049d0000, 0x07dd0000)
the space 12288K, 17% used [0x03dd0000, 0x03fe09a0, 0x03fe0a00, 0x049d0000)
No shared spaces configured.
规则五：在Minor GC触发时，会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间，如果大于，改为直接进行一次Full GC，如果小于则查看HandlePromotionFailure设置看看是否允许担保失败，如果允许，那仍然进行Minor GC，如果不允许，则也要改为进行一次Full GC。
前面提到过，新生代才有复制收集算法，但为了内存利用率，只使用其中一个survivor空间来作为轮换备份，因此当出现大量对象在GC后仍然存活的情况（最极端就是GC后所有对象都存活），就需要老年代进行分配担保，把survivor无法容纳的对象直接放入老年代。与生活中贷款担保类似，老年代要进行这样的担保，前提就是老年代本身还有容纳这些对象的剩余空间，一共有多少对象在GC之前是无法明确知道的，所以取之前每一次GC晋升到老年代对象容量的平均值与老年代的剩余空间进行比较决定是否进行Full GC来让老年代腾出更多空间。
取平均值进行比较其实仍然是一种动态概率的手段，也就是说如果某次Minor GC存活后的对象突增，大大高于平均值的话，依然会导致担保失败，这样就只好在失败后重新进行一次Full GC。虽然担保失败时做的绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure打开，避免Full GC过于频繁。
清单6：
HandlePromotionFailure = false
[GC [DefNew: 6651K->148K(9216K), 0.0078936 secs] 6651K->4244K(19456K), 0.0079192 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
[GC [DefNew: 6378K->6378K(9216K), 0.0000206 secs][Tenured: 4096K->4244K(10240K), 0.0042901 secs] 10474K->4244K(19456K), [Perm : 2104K->2104K(12288K)], 0.0043613 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
HandlePromotionFailure = true
[GC [DefNew: 6651K->148K(9216K), 0.0054913 secs] 6651K->4244K(19456K), 0.0055327 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC [DefNew: 6378K->148K(9216K), 0.0006584 secs] 10474K->4244K(19456K), 0.0006857 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
总结
本章介绍了垃圾收集的算法、6款主要的垃圾收集器，以及通过代码实例具体介绍了新生代串行收集器对内存分配及回收的影响。
GC在很多时候都是系统并发度的决定性因素，虚拟机之所以提供多种不同的收集器，提供大量的调节参数，是因为只有根据实际应用需求、实现方式选择最优的收集方式才能获取最好的性能。没有固定收集器、参数组合，也没有最优的调优方法，虚拟机也没有什么必然的行为。笔者看过一些文章，撇开具体场景去谈论老年代达到92%会触发Full GC（92%应当来自CMS收集器触发的默认临界点）、98%时间在进行垃圾收集系统会抛出OOM异常（98%应该来自parallel收集器收集时间比率的默认临界点）其实意义并不太大。因此学习GC如果要到实践调优阶段，必须了解每个具体收集器的行为、优势劣势、调节参数。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
