gc roots 垃圾回收

gc roots包括以下几个：

　　虚拟机栈（栈桢中的本地变量表）中的引用对象

　　方法区中的类静态属性引用的对象

　　方法区中的常量引用的对象

　　本地方法栈中JNI(即native方法)的引用的对象

　　java,c#对内存的回收的算法是根搜索算法，基本思路是通过一系统的名为"gc roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（reference chain），从一个对象到gc roots没有任何引用链相连(用图论的话来说就是从gc roots到这个对象不可达时),则证明对象是不可用的

而不是采用的引用计数算法，引用计数算法就是给对象添加一个引用计数器，每当有一个地方引用它时，计数算加1，当引用失效时，计数器减1，任何时刻计数器都为0的对象就是不可能再被使用的。

但是这解决不了图中根路径到不了，但是到不了的图节点之间有关联的问题，所以采用根搜索算法

　　在根搜索算法中有可达的对象，不会"非死不可"，这时处于缓刑阶段;如果对象在进行根搜索后发现没有与gc roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finailze()方法。当对象没有覆盖finalize()方法，或者这个方法已经被虚拟机调用过。虚拟机将这两种情况都视为没有必要执行，值得一提的是，Object类里面有一个finalize()方法，所以一般来说有用担心没有finalize()方法。

　　如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列中，并在稍后由一条由虚拟机自动建立的。低优先级的finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果 一个对象在finalize()方法中执行缓慢，或者发生了循环，将会很可能导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后gc将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，比如把自己（this）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时还没逃脱，就被回收了

　　方法区也是有垃圾回收的，只是“性价比”一般比较低;在堆中，常规应用进行一次垃圾收集一般可以回收70-95%的空间，而方法区的垃圾收集效率远低于此。

　　永久代，即方法区主要回收两部分内容：废弃常量和无用的类。回收废弃学量与回收java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc"的，换句话说是没有任何String对象引用常量池中的”abc“常量，也没有其他地方引用这个字面量，如果在这时发生内存回收，而且必要的话，这个”abc“常量就会被系统请出常量池，常量池中的其他类，接口，方法，字段的答题引用也与此类似。

　　判断一个常量是否是废弃常量比较简单，而要判定一个类是否是无用的类的条件则相对苛刻很多，类需要同时满足下面3个条件才能算是无用的类：

　　1.该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例

　　2.加载该类的classLoader已经被回收

　　3.该类对应的java.lang.class对象没有在任何地主被引用，无法在任何地方通过反射访问该类的方法

　　这里说的仅仅是可以，不是和对象一样，不使用就必然会回收。是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceCalssLoading、-XX:+TraceClassUnLoading查看类的加载和卸载信息。-verbose:class和-XX:+TraceClassLoading可以在Product版的虚拟机中使用，但是-XX:+TraceClassLoading参数需要fastdebug版的虚拟机支持

　　在大量的使用反射，动态代理，cglib等bytecode框架的场景，以及动态生成jsp和osgi这类频繁自定义classLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出

此博内容来自深入理解java虚拟机-周志明，具体参数未做实验