对 volatile 的认识

[toc]

# 回收算法

# 引用计数算法

• Java 不再使用
• Python,COM,ActionScript3 使用
• 性能差
• 不能解决循环引用问题

# 标记-清除算法

# 标记阶段

在标记阶段, 首先通过根节点, 标记所有从根节点开始的可达对象

# 清除阶段

清除所有未被标记的对象

# 标记-压缩算法

标记-压缩算法适合用于存活对象较多的场合, 如老年代. 它在标记-清除算法的基础上做了一些优化.

# 标记阶段

从根节点开始, 对所有可达对象做一次标记

# 压缩阶段

将所有存活对象压缩到内存一端,然后清除边界外的所有空间

# 复制算法

• 与标记-清除算法相比,复制算法是一种相对高效的回收方式
• 不适合存活对象较多的场合,如老年代
• 将原来的内存分为相同大小的两块,每次只是用其中一块,在垃圾回收时,将正在是用的内存中的对象复制到未使用的内存块中,之后清除正在是用的内存中的所有对象,交换两个内存的角色,完成垃圾回收

问题:

• 空间浪费,只是用了一半

是用标记清理和复制算法配置回收垃圾

1. 在最上面那块大的区域产生新对象.
2. 大对象不太适合在复制空间, 因为复制空间的容量是有限的, 所以需要一个大的空间做担保, 所以让老年代做担保. 这样产生的大对象直接进入老年代.
3. 每一次GC, 对象的年龄就会+1, 一个对象在几次GC后仍然没有被回收, 则这个对象就是一个老年对象. 老年对象是一个长期被引用的对象, 老年对象将被放入老年代.
4. 步骤1中产生的小对象, 将进入到复制空间. 原先复制空间中的新对象也将被复制到另一块复制空间
5. 清空垃圾对象

一个堆分为new generation(新生代) , tenured generation(老年代)和compacting perm gen. 而new generation分为eden space,from space（有些地方称为s0和s1, 表示幸存代） , to space. eden space就是上面那种图中, 对象产生的地方. from space和to space是两块大小一样的区域, 是上图中的复制空间. new generation的可用总空间就是eden space+一块复制空间（另一块不算）, 但是根据new generation的地址访问可以算出是eden space + 两块复制空间区域, 所以复制算法浪费了一部分空间.

# 分代思想

依据对象的存活周期进行分类, 短命对象归为新生代, 长命对象归为老年代. 根据不同代的特点, 选取合适的收集算法

• 少量对象存活, 适合复制算法
• 大量对象存活, 适合标记清理或者标记压缩
• 进入老年代的对象有两种情况:
  1. 新生代空间不够, 老年代做担保存放一些大对象
  2. 某些对象多次GC后仍然存在, 进入老年代.

老年代的大多数对象都是第2种情况, 所以老年代的对象的生命周期比较长, GC的发生也比较少, 会有大量对象存活, 所以不用复制算法, 而改为标记清理或者标记压缩.
所有的算法, 需要能够识别一个垃圾对象, 因此需要给出一个可触及性的定义

# 可触及性

从根节点可以触及到这个对象 可复活的 一旦所有引用被释放, 就是可复活状态 因为在finalize()中可能复活该对象 不可触及的 在finalize()后, 可能会进入不可触及状态 不可触及的对象不可能复活 可以回收 下面举个例子来说明可复活这个状态:

public class CanReliveObj{
	public static CanReliveObj obj;
	@Override
	protected void finalize() throws Throwable{
		super.finalize();
		System.out.println("CanReliveObj finalize called");
		obj = this;
	}
	@Override
	public String toString(){
		return "I am CanReliveObj";
	}
	public static void main(String[] args) throws InterruptedException{
		obj = new CanReliveObj();
		obj = null; // 可复活
		System.gc();
		Thread.sleep(1000);
		if (obj == null){
			System.out.println("obj 是 null");
		}
		else{
			System.out.println("obj 可用");
		}
		System.out.println("第二次gc");
		obj = null; // 不可复活
		System.gc();
		Thread.sleep(1000);
		if (obj == null){
			System.out.println("obj 是 null");
		}
		else{
			System.out.println("obj 可用");
		}
	}
}

输出:

CanReliveObj finalize called
obj 可用
第二次gc
obj 是 null

一般我们认为, 对象赋值null后, 对象就可以被GC了, 在上述实例中, 在finalize中, 又将obj=this, 使对象复活. 因为finalize只能调用一次, 所以第二次GC时, obj被回收. 因此对于finalize会有这样的建议:

• 经验: 避免使用finalize(), 操作不慎可能导致错误.
• finalize优先级低, 何时被调用（在GC时被调用, 何时发生GC不确定） 不确定
• 可以使用try-catch-finally来替代它

另外在之前, 我们一直在提到从根出发, 那么根是指哪些对象呢？

• 栈中引用的对象
• 方法区中静态成员或者常量引用的对象（全局对象）
• JNI方法栈中引用对象

# Stop-The-World

Stop-The-World是Java中一种全局暂停的现象. 全局停顿, 所有Java代码停止, native代码可以执行, 但不能和JVM交互

多半由于GC引起, 当然Dump线程、死锁检查、堆Dump都有可能引起Stop-The-World

GC时为什么会有全局停顿？ 类比在聚会时打扫房间, 聚会时很乱, 又有新的垃圾产生, 房间永远打扫不干净, 只有让大家停止活动了, 才能将房间打扫干净.

危害

• 长时间服务停止, 没有响应
• 遇到HA系统, 可能引起主备切换, 严重危害生产环境.

新生代的GC（Minor GC）, 停顿时间比较短 老年代的GC（Full GC）, 停顿时间可能比较长

# 串行收集器

串行收集器是最古老, 最稳定以及效率高的收集器 可能会产生较长的停顿, 只使用一个线程去回收 -XX:+UseSerialGC

• 新生代、老年代使用串行回收
• 新生代复制算法
• 老年代标记-压缩

# 并行收集器

# ParNew

• -XX:+UseParNewGC（new代表新生代, 所以适用于新生代）
  • 新生代并行
  • 老年代串行
• Serial收集器新生代的并行版本
• 复制算法
• 多线程, 需要多核支持
• -XX:ParallelGCThreads 限制线程数量

# Parallel

• 类似ParNew

• 新生代复制算法

• 老年代 标记-压缩

• 更加关注吞吐量

• -XX:+UseParallelGC

• 使用Parallel收集器 + 老年代串行

• -XX:+UseParallelOldGC

• 使用Parallel收集器+ 并行老年代

• -XX:MaxGCPauseMills

  • 最大停顿时间, 单位毫秒
  • GC尽力保证回收时间不超过设定值

• -XX:GCTimeRatio

  • 0-100的取值范围
  • 垃圾收集时间占总时间的比
  • 默认99, 即最大允许1%时间做GC

• 这两个参数是矛盾的. 因为停顿时间和吞吐量不可能同时调优

# CMS收集器

• Concurrent Mark Sweep 并发标记清除

• 标记-清除算法

• 与标记-压缩相比

• 并发阶段会降低吞吐量

• 老年代收集器（新生代使用ParNew）

• -XX:+UseConcMarkSweepGC

• 初始标记

  • 根可以直接关联到的对象
  • 速度快

• 并发标记（和用户线程一起）

  • 主要标记过程, 标记全部对象

• 重新标记

  • 由于并发标记时, 用户线程依然运行, 因此在正式清理前, 再做修正

• 并发清除（和用户线程一起）

  • 基于标记结果, 直接清理对象

# 特点

• 尽可能降低停顿

• 会影响系统整体吞吐量和性能

  • 比如, 在用户线程运行过程中, 分一半CPU去做GC, 系统性能在GC阶段, 反应速度就下降一半

• 清理不彻底

  • 因为在清理阶段, 用户线程还在运行, 会产生新的垃圾, 无法清理

• 因为和用户线程一起运行, 不能在空间快满时再清理

  • -XX:CMSInitiatingOccupancyFraction设置触发GC的阈值
  • 如果不幸内存预留空间不够, 就会引起concurrent mode failure

• -XX:+ UseCMSCompactAtFullCollection Full GC后, 进行一次整理

  • 整理过程是独占的, 会引起停顿时间变长

• -XX:+CMSFullGCsBeforeCompaction

  • 设置进行几次Full GC后, 进行一次碎片整理

• -XX:ParallelCMSThreads

  • 设定CMS的线程数量

CMS的提出是想改善GC的停顿时间, 在GC过程中的确做到了减少GC时间, 但是同样导致产生大量内存碎片, 又需要消耗大量时间去整理碎片, 从本质上并没有改善时间.

# GC 参数整理

-XX:+UseSerialGC: 在新生代和老年代使用串行收集器 -XX:SurvivorRatio: 设置eden区大小和survivior区大小的比例 -XX:NewRatio:新生代和老年代的比 -XX:+UseParNewGC: 在新生代使用并行收集器 -XX:+UseParallelGC : 新生代使用并行回收收集器 -XX:+UseParallelOldGC: 老年代使用并行回收收集器 -XX:ParallelGCThreads: 设置用于垃圾回收的线程数 -XX:+UseConcMarkSweepGC: 新生代使用并行收集器, 老年代使用CMS+串行收集器 -XX:ParallelCMSThreads: 设定CMS的线程数量 -XX:CMSInitiatingOccupancyFraction: 设置CMS收集器在老年代空间被使用多少后触发 -XX:+UseCMSCompactAtFullCollection: 设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理 -XX:CMSFullGCsBeforeCompaction: 设定进行多少次CMS垃圾回收后, 进行一次内存压缩 -XX:+CMSClassUnloadingEnabled: 允许对类元数据进行回收 -XX:CMSInitiatingPermOccupancyFraction: 当永久区占用率达到这一百分比时, 启动CMS回收 -XX:UseCMSInitiatingOccupancyOnly: 表示只在到达阀值的时候, 才进行CMS回收