GC回收相关

java中存在的四种引用

（1）强引用：

只要引用存在，垃圾回收器永远不会回收。

（2）软引用

非必须引用，内存溢出之前进行回收

软引用主要用于用户实现类似缓存的功能，在内存不足的情况下直接通过软引用取值，无需从繁忙的真实来源查

询数据，提升速度；当内存不足时，自动删除这部分缓存数据，从真实的来源查询这些数据。

（3）弱引用

第二次垃圾回收时回收，可以通过如下代码实现

弱引用是在第二次垃圾回收时回收，短时间内通过弱引用取对应的数据，可以取到，当执行过第二次垃圾回收时，

将返回null。弱引用主要用于监控对象是否已经被标记为即将回收的垃圾，可以通过弱引用的isEnQueues方法

返回对象是否被垃圾回收器标记。

（4）虚引用

垃圾回收时回收，无法通过引用取到对象值，可以通过如下代码实现

虚引用是每次垃圾回收的时候都会被回收，通过虚引用的get方法永远获取到的数据为null。

GC收集方式

标记-清除算法

从根节点开始标记所有可达对象，其余没有标记的即为垃圾对象，执行清除。但回收后的空间是不连续的。

标记-清除算法不需要进行对象的移动，并且仅对不存活的对象进行处理，在存活对象比较多的情况下极为高效，

但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。

复制算法

复制算法采用从根集合扫描，并将存活对象复制到一块新的，没有使用过的空间中，这种算法当控件存活的对象

比较少时，极为高效，但是带来的成本是需要一块内存交换空间进行对象的移动。也就是s0，s1等空间。

标记-整理法

标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时，在回收不存活的对象占用的空间后，

会将所有的存活对象网左端空闲空间移动，并更新相应的指针。标记-整理算法是在标记-清除算法的基础上，

又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。

GC收集器

串行垃圾回收器（Serial Garbage Collector）

并行垃圾回收器（Parallel Garbage Collector）

并发标记扫描垃圾回收器（CMS Garbage Collector

G1垃圾回收器（G1 GarbageCollector）

 

Minor GC与Full GC

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：

 

当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。

内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。

执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。

质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。

所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。

 

大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：

 

Major GC 是清理永久代。

Full GC 是清理整个堆空间—包括年轻代和永久代。

很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。

 

这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。

 

双亲委派模型：Bootstrap ClassLoader、ExtensionClassLoader、ApplicationClassLoader。

类加载器按照层次，从顶层到底层，分为以下三种：

 （1）启动类加载器（BootstrapClassLoader）

  这个类加载器负责将存放在JAVA_HOME/lib下的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。

 （2）扩展类加载器（ExtensionClassLoader）

  这个加载器负责加载JAVA_HOME/lib/ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器

 （3）应用程序类加载器（ApplicationClassLoader）

  这个加载器是ClassLoader中getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（Classpath）上所指定的类库，可直接使用这个加载器，如果应用程序没有自定义自己的类加载器，一般情况下这个就是程序中默认的类加载器

 

 类加载的双亲委派模型

  双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承关系来实现，而是都使用组合关系来复用父加载器的代码

  工作过程：

   如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传递到顶层的启动类加载器中，

   只有当父类加载器反馈自己无法完成这个请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载

  好处：

  Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类Object，它放在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类

   判断两个类是否相同是通过classloader.class这种方式进行的，所以哪怕是同一个class文件如果被两个classloader加载，那么他们也是不同的类

 

 实现自己的加载器

  只需要继承ClassLoader，并覆盖findClass方法。

  在调用loadClass方法时，会先根据委派模型在父加载器中加载，如果加载失败，则会调用自己的findClass方法来完成加载。