垃圾收集器

之前一篇 Blog 已经将GC的机制以及GC的算法讲了一下。 而这篇Blog主要是讨论这些GC的算法在JVM中的不同应用。 1. 串行收集器 串行收集器是 最古老，最稳定以及 效率高的收集器 可能会产生较长的停顿， 只使用一个线程去回收 -XX:+UseSerialGC 新生代、老年代使用串行回收 新生代复制算法 老年代标记-压缩 串行收集器的日志输出： 0.844: [GC 0.844: [DefNew: 17472K->2176K(19648K), 0.0188339 secs] 17472K->2375K(63360K), 0.0189186 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 8.259: [Full GC 8.259: [Tenured: 43711K->40302K(43712K), 0.2960477 secs] 63350K->40302K(63360K), [Perm : 17836K->17836K(32768K)], 0.2961554 secs] [Times: user=0.28 sys=0.02, real=0.30 secs] 2. 并行收集器 2.1 ParNew -XX:+UseParNewGC（new代表新生代，所以适用于新生代） 新生代并行 老年代串行

垃圾收集器与内存分配策略简介： 一：垃圾收集算法 1.1：简介 说起垃圾收集，大部分人都把这项技术当做java语言的伴生物，其实，GC的历史比java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言，档Lisp在胚胎的时候，人们就在考虑GC需要完成的三件事情： 1：那些内存需要回收 2：什么时候回收 3：如何回收 1.2：垃圾收集算法： 由于笔者也是刚开始学习，对算法的具体实现不甚了解，所以请见谅。 1.2.1标记-清除算法 该算法也是最基础的收集算法，就给名字一样，分为标记和清除两部分，首先标记处所有需要清理的对象，然后在标记完成之后在统一回收。该算法的最大缺点就是标记清除之后会产生大量不连续的内存碎片，空间碎片化太高可能会导致，当程序在以后的运行霍城中需要分配大对象的时候没有办法找到连续的空间再去触发一次垃圾回收动作，有点得不偿失，还有一点就是该算法的收集效率也不是太高。如下所示： 1.2.2:复制算法： 为了解决效率问题，一种称为“复制”算法的收集算法出现了，他讲容量划分为大小相等的两块，每次只是用一块，当一块内存块用完之后，就把存活的对象复制到另一块上去，然后把已经使用过的内存空间一次清理掉，这样使得每次都对其中一块进行垃圾回收，再次进行内存分配的时候也不用考虑空间碎片化的问题。这种算法也有坏处就是内存压缩为原来的一半，利用率比较低

JVM ——垃圾收集器总结 垃圾收集器概览 收集算法是内存回收的方法论，垃圾收集据是内存回收的具体实现。 Java 虚拟机规范中对垃圾收集器应该如何实现没有规定，不同的厂商、不同版本的虚拟机所提供的垃圾收集器可能会有很大差别，一般都会提供参数供用户根据自己的所用特点和要求组合出各个年代所使用的收集器。下面是基于 JDK 1.7 Update 14 之后的 HotSpot 虚拟机垃圾收集器。如果两个收集器之间有连线就说明它们可以搭配使用。 直到现在还没有最好的收集器，更加设有万能的收集器，只是对具体应用选择最合适的收集器。 垃圾收集器概览图如下： Serial 收集器 Serial 收集器是最基本、历史最悠久的收集器，它是一个单线程的收集器，即它只会使用一个 CPU 或一条收集线程去完成垃圾收集工作，而且在进行垃圾收集时， 必须暂停其他所有的工作钱程，直到它收集结束，虽然它有很大缺点，但依然是虚拟机运行在 Client 模式下的默认新生代收集器。它也有着优于其他收集器的地方： 简单而高效。 Serial 收集器没有线程交互的开销， 专心做垃圾收集，可以获得很高的单线程收集效率。 运行示意图如下： ParNew 收集器 ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括 Serial 收集器可用的所有控制参数、、收集算法

等下会以英文源文档+翻译的方式来分析Reference这一个类。 约定对应的中文翻译对对应于正上面的英文或者代码，英文源文档直接对应于正上面的代码。 >类的定义 Abstract base class for reference objects. This class defines the operations common to all reference objects. Because reference objects are implemented in close cooperation with the garbage collector, this class may not be subclassed directly. 从JDK中文文档的翻译是： 引用对象的抽象基类。此类定义了常用于所有引用对象的操作。因为引用对象是通过与垃圾回收器的密切合作来实现的，所以不能直接为此类创建子类。 >private T referent; /* Treated specially by GC */ /* A Reference instance is in one of four possible internal states: * * Active: Subject to special treatment by the garbage collector. Some *

这是jvm优化系列第三篇： jvm优化——垃圾回收 jvm优化——监控工具 JVM性能调优涉及到方方面面的取舍，往往是牵一发而动全身，需要全盘考虑各方面的影响。但也有一些基础的理论和原则，理解这些理论并遵循这些原则会让你的性能调优任务将会更加轻松。为了更好的理解本篇所介绍的内容。你需要已经了解和遵循以下内容: 1、已了解jvm 垃圾收集器 2、已了解jvm 性能监控常用工具 3、能够读懂gc日志 4、确信不为了调优而调优，jvm调优不能解决一切性能问题 这些内容在之前的两篇文章已经介绍过了，如果有不了解的可以去点击上述连接进行回顾，如果对这些不了解不建议读本篇文章。 本篇文章基于jvm性能调优，结合jvm的各项参数对应用程序调优，主要内容有以下几个方面： 1、jvm调优的一般流程 2、jvm调优所要关注的几个性能指标 3、jvm调优需要掌握的一些原则 4、调优策略&示例 一、性能调优的层次 为了提升系统性能，我们需要对系统的各个角度和层次来进行优化，以下是需要优化的几个层次。 从上面我们可以看到，除了jvm调优以外，还有其他几个层面需要来处理，所以针对系统的调优不是只有jvm调优一项，而是需要针对系统来整体调优，才能提升系统的性能。本篇只针对jvm调优来讲解，其他几个方面，后续再介绍。 在进行jvm调优之前，我们假设项目的架构调优和代码调优已经进行过或者是针对当前项目是最优的