GC垃圾回收
- 引用又分为强引用、软引用、弱引用、虚引用四种：

GC垃圾回收

垃圾回收（GC）是Java虚拟机（JVM）垃圾回收器提供的一种用于在空闲时间不定时回收无任何对象引用的对象所占据的内存空间的一种机制。GC在执行时会进行可达性分析, 如果内存的对象不可达, 则会被回收.

首先以一个问题引入:Java中的对象什么时候被回收?被谁回收?如何确定此对象被回收了?

创建一个类:Ponit类

/**
 * 定义一个点对象类型
 */
public class Point{
	int x;
	int y;
	public Point(int x,int y) {
		this.x=x;
		this.y=y;
	}
	@Override
	protected void finalize() throws Throwable {
		System.out.println("finalize()");
	}
}

finalize()方法的作用:

/**
 finalize方法会在对象被回收(GC)之前执行，可以对对象的回收进行监控，
也可以在对象回收之前进行一些资源释放操作。
*/

进行以下测试:

//通过JVM参数检测是否触发了GC操作：-XX:+PrintGCDetails
public class TestGC01 {
	static Map<String,Object> objectPool=new HashMap<>();
	public static void main(String[] args) throws InterruptedException {
    	//构建一个实例对象，并通过P1引用指向这个对象
		 Point p1=new Point(10,20);//p1为一个强引用
		 objectPool.put("point", p1);//Spring中的singleton作用域
		 p1=null; //Spring中prototype作用域对象的销毁
		 objectPool.clear();//Spring中Singleton作用域的销毁
		//请问对于p1引用的这个对象何时会被标识垃圾对象，何时会被回收，如何确定此对象被回收了
		//1)当p1引用不再指向构建的Point对象时，此对象会被GC系统认为是垃圾对象。
		//2)当JVM系统触发了GC操作时，对象可能会被回收。
		//3)此对象会被JVM中的垃圾回收系统(GC系统)进行回收。(释放内存)
		//触发GC操作？(GC系统触发时会对内存中的对象进行可达性分析，就是检测是否还可以通过引用
		//访问到此对象，假如不能通过任何引用访问此对象，这个对象就会被标识垃圾)
		//1.手动GC
		//System.gc();
		//2.自动GC(满足了GC条件时或者说内存使用达到一定的GC启动标准)
		 List<byte[]> list=new ArrayList<>();
		 for(int i=0;i<100000;i++) {
			 list.add(new byte[1024*1024]);
		 }
	}
}

引用：如果Reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。

这里提到了引用的类型:有强引用,软引用,弱引用,虚引用

引用又分为强引用、软引用、弱引用、虚引用四种：

强引用（Strong Reference）：如“Object obj = new Object（）”，这类引用是java中最普遍的，只要强引用还存在，垃圾收集器就永远不会回收掉被引用的对象，不管内存是否够用。
软引用（Soft Reference）：它用来描述一种可能有用，但不是必须的对象，在系统内存不够用时，这类引用会在垃圾收集器下一次回收垃圾时被回收。
弱引用（Weak Reference）：它是用来描述非必须的对象，但它的强度比软引用更弱些，被弱引用关联的对象只能生存到下一次垃圾收集器回收垃圾之前，不论系统内存是否够用，都会回收掉只被弱引用关联的对象。
虚引用（Phantom Reference）：最弱的一种引用关系，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。

1.引用计数器算法

解释

系统给每个对象添加一个du引用计数器,每当有一个地方引用这个zhi对象的时候,计数器就加1,当引用失效的时候,计数器就减1,在任何一个时刻计数器为0的对象就是不可能被使用的对象,因为没有任何地方持有这个引用,这时这个对象就被视为内存垃圾,等待被虚拟机回收

优点

客观的说,引用计数器算法,他的实现很简单,判定的效率很高,在大部分情况下这都是相当不错的算法
其实,很多案例中都使用了这种算法,比如 IOS 的Object-C , 微软的COM技术(用于给window开发驱动,.net里面的技术几乎都是建立在COM上的),Python语言等.

缺陷

无法解决循环引用的问题.
这就好像是悬崖边的人采集草药的人, 想要活下去就必须要有一根绳子绑在悬崖上. 如果有两个人, 甲的手拉着悬崖, 乙的手拉着甲, 那么这两个人都能活, 但是, 如果甲的手拉着乙, 乙的手也拉着甲, 虽然这两个人都认为自己被别人拉着, 但是一样会掉下悬崖.
比如说 A对象的一个属性引用B,B对象的一个属性同时引用A A.b = B() B.a = A(); 这个A,B对象的计数器都是1,可是,如果没有其他任何地方引用A,B对象的时候,A,B对象其实在系统中是无法发挥任何作用的,既然无法发挥作用,那就应该被视作内存垃圾予以清理掉,可是因为此时A,B的计数器的值都是1,虚拟机就无法回收A,B对象,这样就会造成内存浪费,这在计算机系统中是不可容忍的.

解决办法

在语言层面处理, 例如Object-C 就使用强弱引用类型来解决问题.强引用计数器加1 ,弱引用不增加
Java中也有强弱引用

2.可达性分析算法

解释

这种算法通过一系列成为 "GC Roots " 的对象作为起始点,从这些节点开始向下搜索所有走过的路径成为引用链(Reference Chain) , 当一个对象GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达),则证明此对象是不可用的

JVM是通过可达性分析算法判断对象是否存活的，这个算法的基本思想是：通过一系列被称为”GC Roots”的对象作为起点，向下搜索，搜索所走过的所有路径称为对象的引用链，当一个对象通过引用链无法到达“GC Roots”时，说明该对象是不可用的，是可以回收的（不一定回收）。

优点

这个算法可以轻松的解决循环引用的问题
大部分的主流java虚拟机使用的都是这种算法

在可达性分析之后，如果判断对象通过引用链无法到达“GC Roots”，则认为该对象是可回收的，但是不保证一定会回收这个对象。对象的回收至少需要经过两次标记过程：

判断对象通过引用链不可达之后，进行第一次标记并且进行一次筛选，筛选的条件是判断对象是否有必要执行finalized()方法。如果对象没有覆盖finalize()方法或者不是虚拟机第一次调用，则判断为没有必要执行finalize()方法。
如果对象有必要执行finalized()方法，则会将该对象放到一个F-Queue队列中，并且虚拟机会自动创建一个低优先级的Finalizer线程执行。“执行”的含义是虚拟机会去触发Finalizer线程的执行，但是不会等待结果的返回。因为如果finalized()方法执行时间较长或者产生死循环的话，将导致F-Queue中的其他对象永远处于等待状态。甚至导致整个回收系统的奔溃。finalized()方法是对象实现逃脱的唯一一次机会。如果对象没有逃脱，则在JVM进行第二次标记之后会回收该对象。
finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那么在第二次标记时它将被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那么基本上它就真的被回收了。

方法区回收

方法区处于永久代中，永久代中主要有两部分回收内容：废弃的常量和无用的类。

回收常量：回收常量和回收堆对象是相同的，如果一个常量在在常量池中已经存在，如果在系统中没有一个对象引用常量池中的常量的话，那么这个常量就需要被回收。
回收类：回收类的条件比回收常量的苛刻许多：以下三点为必要不充分条件：
- 该类所有的实例都已经被回收，也就是说java堆中不存在该类的任何实例
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

3.Java语言中的GC Roots

在虚拟机栈 (其实是栈帧中的本地变量表) 中引用的对象
在方法区中的类静态属性引用对象
在方法区中的常量引用的对象
在本地方法栈中JNI(即一般说的Native方法)的引用对象

4.FAQ:

1)当对象存在引用时，是否可能在系统触发GC时被回收？可能，要看引用类型？

2)当GC系统没有启动时，对象是否可能被回收？可能，看你对象分配在哪了？(如果是栈里,则不需要启动GC)

3)当GC系统触发时，假如对象要被销毁了会执行finalize方法吗？

finalize()并不是必须要执行的，它只能执行一次或者0次。如果在finalize中建立对象关联，则当前对象可以复活一次。Finalizer线程不保证一定执行finalize方法，因为此线程的优先级很低，获得CPU资源有限;而且这样会避免finalize执行缓慢或者发生死循环，从而导致整个GC奔溃

回收时间：

即触发GC的时间，在新生代的Eden区满了，会触发新生代GC（Mimor GC），经过多次触发新生代GC存活下来的对象就会升级到老年代，升级到老年代的对象所需的内存大于老年代剩余的内存，则会触发老年代GC（Full GC）。当程序调用System.gc()时也会触发Full GC。

[GC (System.gc()) [PSYoungGen: 1966K->600K(37888K)] 1966K->608K(123904K), 0.0036263 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (System.gc()) [PSYoungGen: 600K->0K(37888K)] [ParOldGen: 8K->517K(86016K)] 608K->517K(123904K), [Metaspace: 2646K->2646K(1056768K)], 0.0087037 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
 Heap
 PSYoungGen      total 37888K, used 983K 
  	eden space 32768K, 3% 
    from space 5120K, 0%
    to   space 5120K, 0%
    ParOldGen       total 86016K, used 517K 
  object space 86016K, 0% 
    Metaspace       used 2654K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 282K, capacity 386K, committed 512K, reserved 1048576K

堆里面的分区：Eden，survival （from+ to），老年代，各自的特点？

堆里面分为新生代和老生代（java8 取消了永久代，采用了 Metaspace），新生代包含 Eden+Survivor 区，survivor 区里面分为 from 和 to 区，内存回收时，如果用的是复制算法，从 from 复制到 to，当经过一次或者多次 GC 之后，存活下来的对象会被移动到老年区，当 JVM 内存不够用的时候，会触发 Full GC，清理 JVM 老年区当新生区满了之后会触发 YGC,先把存活的对象放到其中一个 Survice 区，然后进行垃圾清理。

因为如果仅仅清理需要删除的对象，这样会导致内存碎片，因此一般会把 Eden 进行完全的清理，然后整理内存。

那么下次 GC 的时候，就会使用下一个 Survive，这样循环使用。

如果有特别大的对象，新生代放不下，就会使用老年代的担保，直接放到老年代里面。
因为 JVM 认为，一般大对象的存活时间一般比较久远。

原文地址：https://www.cnblogs.com/liqbk/p/13216253.html

java学习day40--JVM---GC