为什么要去了解GC和内存分配？
当需要排查各种内存溢出、内存泄漏时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些自动化的技术实施必要的监控和调节。
程序计数器、虚拟机栈、本地方法栈三个区域随线程而生，随线程而灭。
如何判断对象存活状态
-
引用计数法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器值为0的对象就是不可能再被使用的。
java语言中没有选引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间的循环引用的问题。 -
根搜索算法
通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。在java语言里可作为GC roots的对象包括以下几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象
- 方法区中的类静态属性的对象
- 方法区中的常量引用 的对象
- 本地方法栈中JNI（即一般说的Native方法）的引用的对象
关于引用
在JDK1.2之后，java引用的概念进行和扩充，将引用分为强引用、软引用、弱引用、虚拟用四种，这四种引用强度依次减弱。
- 强引用
类似Object o = new Object()，只要强引用还在，垃圾收集器永远不会回收掉被引用的对象
- 软引用
还有用但非必要的对象，软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK1.2之后，提供了SoftReference类来实现软引用。
- 弱引用
强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾发生之前。当垃圾收集器工作时，无论当前存存是否足够，都会回收掉只被弱引用关联的对象。在JDK1.2之后，提供了WeakReference来实现弱引用。
- 虚引用
也称为幽灵引用或幻影引用，是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到 个系统通知。JDK1.2之后提供了PhantomReference实现弱引用。
生存还是死亡
在根索算法中不可达的对象，也并非是“非列不可”的，这个时候暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行根搜索后发现没有与“GC Roots”相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要招待finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都被为“没有必要执行”。
如果这个对象被判定为有必要执行finalize方法，那么这个对象将会被放置在一个名为F-Queue的列队之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进地二次小规模的标记，如果对象要在finalize()中成功拯救自已——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己(this关键字)赋值给某个变量或对象的成员变量，那在第二次标记时它将被移出“即将回收”的集合；如果对象这时候还没有逃脱，那它就真的离死不远了。
特别说明：建议大家尽量避免使用它，因为它不是C/C++中的析构函数，而是java刚诞生时为了使C/C++程序员更容易接受它所做出的一个妥协。
有些教材中提到它适合做“关闭外部资源”之类的工作，这完全是对这种方法用途的一种自我安慰。finalize()能做的所有工作，使用try-finally或其它方式都可以做得更好、更及时，大家完全可以忘掉java语言中还有这个方法的存在。
回收方法区
永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。例如：假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用这个字面量，如果这个时候发生内存回收，而且必要的话，这个abc常量将被系统请出常量池。
类需要同时满足下面3个条件才算是“无用的类”：
- 该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例。
- 加载该类的ClassLoader已经被回收
- 该类对象的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反向访问该类的方法。
是否对象进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类的加载和卸载信息。-verbose:class和-XX:+TraceClassLoading可以在Product版的虚拟机中使用，但在-XX:+TraceClassLoading参数需要fastdebug版的虚拟机支持。
垃圾收集算法
标记-清除算法
首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高，另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
复制算法
它将可用内存按容量分为大小相等的两块，每次只使用其中的一块，当这一块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已经使用过的内存空间一次性清理掉。这样使得每次都是对其中的一块内存进行回收，内存分配时也就不用考虑内存碎片等复杂情总路咀镇 ，只需要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一片，未免太高了一点。
标记-整理算法
复制收集算法在对象存活率较高时就需要执行较多的复制操作，效率将会变低。标记-整理算法标记过程仍然和标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法
当前商业虚拟机的垃圾收集都采用“分代收集”算法，一般是把java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大指对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象复制成本就可以完成收集。而老年代中因为对象存活率高，没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法进行回收。
垃圾收集器
HotSpot JVM1.6的垃圾收集器：
- Serial
- ParNew
- Parallel Scavenge
-XX:+UseAdptiveSizePoicy值得关注，这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的呑吐量，这种调节方式称为GC自适应的调节策略。
- G1
- CMS
它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。
CMS收集器是一种以获得最短回收停顿时间为目标的收集器。
它有以下3个显示的缺点：
- CMS收集器对CPU资源非常敏感。
- CMS收集器无法处理浮动垃圾，可能出现"cuncurrent mode failure"失败而导致另一次full gc的产生。
- 收集结束时会产生大量空间碎片，空间碎片太多时，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次full gc。
- Parallel Old
- Serial Od(MSC)
并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处理等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时招待（但不一定是并行的，可能会交替招待），用户程序继续运行，而垃圾收集程序运行于另一个Cpu上。
虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前存存区域的分配情况。
进晋升老年代的年龄阈值可以通过参数-XX:MaxTenuringThreshold来设置。