Grabage Collection ? ? ?GC
GC要完毕的三件事情：
哪些内存须要回收？
什么时候回收？
怎样回收？
内存运行时区域的各个部分中：
程序计数器、虚拟机栈、本地方法栈这3个区域随线程而生。随线程而灭。
栈中的栈帧随着方法的进入和退出而有条不紊地运行着出栈和入栈的操作。
每个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此，
这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需过多考虑回收的问题。
由于方法结束或者线程结束时。内存自然就跟着回收了。
而java堆和方法区就不一样了。一个接口中多个实现类须要的内存可能不一样。一个方法中的多个
分支须要的内存也可能不一样，我们仅仅有在程序处于运行期间才知道会创建哪些对象，这部分内存的分配和回收是动态的。
我们的垃圾收集器所关注的就是这部分内存。
堆内存中存放这大量对象实例，垃圾收集器首先要推断这些对象哪些是“活着的”哪些是“死去的”
引用计数器算法
给对象中加入一个引用计数器，每当被引用时，该计数器就加1。失去引用时计算器减一。
不论什么时刻，计算器值为0就代表该对象是不能再被使用的。
存在的问题：非常难解决对象间循环引用的问题
可达性分析算法
基本思想：通过一系列的称为"GC Roots"的对象作为起点。从这些节点開始向下搜索，搜索所走过的路径称为
引用链(Reference Chain)，当一个对象到GC Roots没有不论什么引用链相连时，则证明此对象是不可用的。
java中。可作为GC Roots的对象包含以下几种：
1、虚拟机栈(栈帧中的本地变量表)中引用的对象
2、方法区中类静态属性引用的对象
3、方法区中常量引用的对象
4、本地方法栈中(即一般说的Native方法)引用的对象
不管哪种算法都是和引用有关的，可是引用该怎样理解呢？
什么样的引用算是实用的，什么样的引用又是没用的呢？
在JDK1.2后对引用进行了区分。这四种引用强度依次逐渐递减：
强引用
? ? ?指在程序总普遍存在的，如：Object obj = new Object()，这类引用。仅仅要强引用还在。垃圾收集器永远不会回收掉被引用的对象。
软引用
? ? ?用来描写叙述一些还实用可是非必须的对象。对于软引用关联着的对象。系统会在发生内存溢出异常之前，将会把这些对象列入回收范围之中进行二次回收。假设这次回收后还没有足够的内存才会抛出内存溢出异常
弱引用
? ? ?弱引用也是用来描写叙述一些非必须对象的。它的强度比软引用更弱一些，被弱引用关联的对象。仅仅能存活到下一次垃圾收集发生之前。
不管当前内存是否足够，都会被垃圾收集器回收掉。
虚引用
? ? ?又称为幽灵引用或者幻影引用。
一个对象是否有虚引用的存在。全然不会对其生存时间构成影响，也无法通过一个虚引用来取得一个对象的实例。
为一个对象设置虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
生存还是死亡
在可达性分析算法中。即使不可达的对象。也不一定是死亡的。要真正确定一个对象的死亡，至少要经历俩次标记的过程：
第一次标记：
? ? ?对象在进行可达性分析后发现没有和GC Roots相连接的引用链
? ? ?而且进行了一次筛选。筛选的条件是该对象有没有必要运行finalize()方法
? ? ? ? ? 当该对象没有重写finalize()方法，或者finalize()方法已经被虚拟机运行过，则觉得没有必要运行finalize()方法
? ? ? ? ? 当该对象须要运行finalize()方法，则会被放进一个叫做F-Queue的队列,由虚拟机自己主动运行
第二次标记：
? ? ?finalize()方法是对象逃脱死亡的最后一次机会，GC会对F-Queue队列进行第二次标记。
? ? ?假设对象在finalize()方法中成功解救自己:
? ? ? ? ? 仅仅要与引用链上的不论什么一个对象建立关系就能够。
? ? ?那么第二次标记，它将被移除即将回收的集合。假设该对象这个阶段还没有逃脱，那么它就被回收了。
以下是代码。原书上的内容：
package com.smile.three;
/**
* 此代码演示了两点：
* 1.对象能够在被GC时自我解救。
* 2.这样的自救的机会仅仅有一次。由于一个对象的finalize()方法最多仅仅会被系统自己主动调用一次
* @author 深入理解JVM作者周志明zzm
*/
public class FinalizeEscapeGC {
//定义对象
public static FinalizeEscapeGC SAVE_HOOK = null;
//活着的对象能够调用的方法
public void isAlive() {
System.out.println("yes, i am still alive :)");
}
//重写finalize()方法
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("finalize mehtod executed!finalize方法被运行了");
FinalizeEscapeGC.SAVE_HOOK = this;
}
public static void main(String[] args) throws Throwable {
//创建对象并赋值
SAVE_HOOK = new FinalizeEscapeGC();
//对象第一次成功解救自己
SAVE_HOOK = null;
System.gc();
// 由于Finalizer方法优先级非常低，暂停0.5秒，以等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no, i am dead :(");
}
// 以下这段代码与上面的全然同样，可是这次自救却失败了
SAVE_HOOK = null;
System.gc();
// 由于Finalizer方法优先级非常低，暂停0.5秒，以等待它
Thread.sleep(500);
if (SAVE_HOOK != null) {
SAVE_HOOK.isAlive();
} else {
System.out.println("no, i am dead :(");
}
}
}
注意一点：
不论什么一个对象的finalize()方法都仅仅会被系统运行一次。
所以在第二次回收的时候。它的finalize()方法就失效了。
回收方法区
方法区，在分代算法中被称为永久代，而在永久代进行GC要比新生代的回收"性价比"要低非常多。
永久代垃圾回收的内容：
? ? ?废弃常量：
? ? ? ? ? 没有不论什么引用，进入常量池的常量，甚至常量池中的常量也可能被回收。
? ? ?没用的类：
? ? ? ? ? 没用的类标准：
? ? ? ? ? 1、该类全部的实例都被回收，java堆中不存在不论什么该类的实例。
? ? ? ? ? 2、载入该类的ClassLoader已经被回收
? ? ? ? ? 3、该类相应的java.lang.Class对象没有在不论什么地方被引用，无法在不论什么地方通过反射訪问该类的方法。
GC回收涉及内容较多，我还在学习其中，这个系列博客会持续更新。