JVM内存区域和垃圾回收机制

JVM:Java Virtual Machine的简称，Java虚拟机

JVM内存区域划分

运行时数据区域

JVM在执行Java程序的过程中把它管理的内存划分为若干个不同的数据区域。这些数据区域各有各的作用，各有各的创建于销毁时间，有的区域随着JVM进程的启动而存在，有的则依赖于用户线程的启动和结束而创建与销毁。

• 程序计数器（线程私有）
  程序计数器是一块比较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器。在JVM的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
  如果线程执行的是一个Java方法，计数器记录的是正在执行的虚拟机字节码指令的地址；如果程序执行的是一个Native方法，计数器的值则为空。
  程序计数器内存区域是在JVM规范中唯一一个没有规定任何OOM情况的区域！！!
  这些数据区域分为两种线程私有和线程共享，那么什么是线程私有呢？？？
  由于JVM的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，因此在任何一个确定的时刻，一个多处理器都只会执行一条线程中的指令。所以为了切换线程后能恢复到正确的执行位置，每条线程都需要独立的程序计数器，各条线程之间计数器互不影响，独立存储。这类区域就称之为“线程私有”的内存。
• Java 虚拟机栈（线程私有）
  虚拟机栈描述的是Java方法执行的内存模型：每个方法执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应一个栈帧在虚拟机中入栈到出栈的过程。声明周期与线程相同。
  虚拟机栈描述的其实是虚拟机栈中的局部变量表部分。
  
  局部变量表：存放了编译器可知的各种剧本数据类型（boolean byte char short int float long double）和对象引用（reference类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用地址，也可能是指向一个代表对象的句柄或者其它于此对象相关的位置）。局部变量表所需的内存空间在编译时期完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量是完全确定的，在执行期间不会改变局部变量的大小。
  此区域会产生两种异常：
  1.如果线程请求的栈深度大于细腻及所允许的深度，将会抛出StackOveryFlowError异常。
  2.如果虚拟机可以动态扩展，如果扩展时无法申请到足够的内存，会抛出OOM（OutOfMemoryError）异常。
• 本地方法栈（线程私有）
  本地方法栈与虚拟机栈的作用完全一样，区别是本地方法栈为虚拟机使用的Native方法服务
  ，而虚拟机栈为JVM执行的Java方法服务。
  在HotSpot虚拟机中，本地方法栈与虚拟机栈是同一块内存。
• Java堆（线程共享）
  Java堆是JVM所管理的最大内存区域。Java堆是所有线程共享的一块区域，在JVM启动时创建。唯一的目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。
  Java堆是垃圾回收器管理的主要区域，因此很多时候可以称之为“GC堆”。从内存回收的角度看，由于现在收集器基本都采用分代收集算法，所以Java堆可以细分为：新生代、老年代；从内存分配的角度看，线程共享的Java堆可能划分出多个线程私有的分配缓冲区。
  Java堆可以处于物理上不连续的内存空间中。
  Java虚拟机规定，如果在堆上没有足够的内存完成实例分配并且堆上也无噶扩展时，将会抛出OOM异常。
  Java堆内存的OOM异常：
  内存泄露：程序中一些对象不会被GC所回收，它始终占用内存。
  内存溢出：程序运行过程中无法申请到足够的内存而导致的一种错误。内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。
• 方法区（线程共享）
  方法区与Java堆一样，是各个线程共享的区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译(JIT)后的代码等数据。在JDK 8以前的HotSpot虚拟机中，方法区也称为“永久代”（JDK 8以后已被元空间取代）
  Java虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。这个区域的内存回收主要是针对常量池的回收以及对类型的卸载。
• 运行时常量池
  运行时常量池是方法区的一部分，存放字面量和符号引用。

垃圾回收机制

垃圾回收（Garbage Collection）是JVM垃圾回收器提供的一种用于在空闲时间不定时回收无任何对象引用的对象占据的内存空间的一种机制。

如何判断“垃圾”

Java堆中存放着几乎所有的对象实例，垃圾回收器在对堆进行垃圾回收前，首先要判断哪些对象还存活，哪些对象“已死”！
如何判断对象“已死”？？？
引用计数法
给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象“已死”。
引用计数器实现简单，判断效率也比较高，在大部分情况下是很不错的。但是在主流的JVM中没有选用引用计数器来管理内存的，最主要的原因是引用计数法无法解决对象的循环引用问题。
可达性分析算法
核心思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称之为“引用链”，当一个对象到GC Roots没有任何的引用链相连时（从GC Roots到这个对象不可达），证明此对象是不可用的。

对象Object 5-Object 7之间虽然彼此还有关联，但是它们到GC Roots是不可达的，因此它们会被判定为可回收对象。
在Java语言中，可作为GC Roots的对象包含以下几种：
1.虚拟机栈中引用的对象
2.方法区中类静态属性引用的对象
3.方法区中常量引用的对象
4.本地方法栈中Native方法引用的对象
引用分为强引用、软引用、弱引用和虚引用，这四种引用的强度依次递减：

• 强引用：指在程序代码之中普遍存在的，类似于“Object obj = new Object()”这类引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象实例。
• 软引用：用来描述一些可能还有用但不是必须的对象。在系统内存将要溢出之前，这些对象会被垃圾收集器回收。在JDK1.2之后，提供了SoftReference类来实现软引用。
• 弱引用：也用来描述非必须对象，但强度弱于软引用。被弱引用关联的对象只能存活到下一次垃圾回收发生之前。当垃圾回收器开始进行工作时，无论当前内容是否够用，都会回收掉只被弱引用关联的对象。在JDK1.2之后提供WeakReference类来实现弱引用。
• 虚引用：也被称为幽灵引用或幻影引用，是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后提供PhantomReference类来实现虚引用。
  回收方法区的垃圾回收主要收集两部分：废弃常量和无用的类。
  如何判断一个类是“无用的类”？？？
  1.该类的所有实例都已经被回收（即Java堆中不存在任何该类的实例）
  2.加载该类的ClassLoader已经被回收
  3.该类对应的class对象没有在任何其他地方被引用，无法在任何地方通过反射访问该类的方法。

垃圾回收算法

• 标记-清除算法（Tracing Collector）
  最基础的收集算法，分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它的标记过程其实就是根搜索算法中判断垃圾对象的标记过程。
  不足：效率不高；会产生大量不连续的空间碎片
• 复制算法（新生代回收算法 Copying Collector）
  “复制”算法是为了解决“标记-清除”算法的效率问题。将可用内存按容量分为大小相等的两块，每次只使用其中的一块。当这一块需要进行垃圾回收时，会将此区域还存活着的对象复制到另外一块内存上面，然后再把已经使用过的内存区域一次性清理掉。这样做的好处是每次都是对整个半区进行内存回收，内存分配时也就不需要考虑内存碎片等复杂情况，只需要移动堆顶指针，按顺序分配即可。实现简单，运行高效。
• 标记-整理算法（老年代回收算法 Compacting Collector）
  “复制”算法在对象存活效率较高时会进行比较多的复制操作，效率会变低。因此老年代一般不能使用“复制”算法，而是使用“标记-整理”算法。它的标记过程与“标记-清除”算法的标记过程一致，但后续不是直接对可回收对象直接清理，而是让所有存活对象都向一端移动，然后直接清理掉边界以外的内存。

垃圾收集器

上图是七种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明他们之间可以搭配使用。所处区域表示属于新生代还是老年代。在此之前我们还需要明确三个概念：
并行（Parallel）:多条垃圾收集线程并行工作，用户线程仍处于等待状态
并发（Concurrent）：用户线程与垃圾收集线程同时执行（不一定并行，可能交替执行），用户线程继续运行，而垃圾收集程序在另外一个CPU上
吞吐量：CPU用于运行用户代码的事件与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

• Serial收集器（新生代收集器，串行GC）
  最基本、发展历史最悠久的收集器，是一个单线程收集器。它的“单线程”意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。
  应用场景：虚拟机运行在Client模式下的默认新生代收集器。
  优势：简单高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。实际上到现在为止它依然是虚拟机运行在Client模式下的默认新生代收集器。
• ParNew收集器（新生代收集器，并行GC）
  ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。
  应用场景：许多运行在Server模式下的虚拟机首选的新生代收集器。
  ！！！作为Server的首选收集器有一个与性能无关的很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。在JDK1.5之前，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。但是，CMS作为老年代的收集器，却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个！！！
• Parallel Savenge收集器（新生代收集器，并行GC）
  是使用复制算法的收集器，也是并行的多线程收集器。使用两个参数控制吞吐量：
  1.XX：MaxGCPauseMillis控制最大的垃圾收集停顿时间
  2.XX：GCRatio直接设置吞吐量的大小
  直观上，只要最大的垃圾收集停顿时间越小，吞吐量是越高的，但是GC停顿时间的缩短是以牺牲吞吐量和新生代空间作为代价的。所以停顿时间下降的同时，吞吐量也下降了
  应用场景：停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率的利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
  对比分析：
  Parallel Scavenge收集器 VS CMS等收集器： Parallel Scavenge收集器的特点是它的关注点与其他收集器不 同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的 目标则是达到一个可控制的吞吐量（Throughput）。
  Parallel Scavenge收集器 VS ParNew收集器： Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略。
• Serial Old收集器（老年代收集器，串行GC）
  是Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。
  应用场景：
  Client模式：Serial Old收集器的主要意义也是在于给Client模式下的虚拟机使用。
  Server模式：有两大用途：一种用途是在JDK 1.5以及之前的版本中与 Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生 Concurrent Mode Failure时使用
• Parallel Old收集器（老年代收集器，并行GC）
  是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法
  应用场景：在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。
• CMS收集器（老年代收集器，并发GC）
  CMS（Concurrent Mark Sweep）收集器是一种以获取短回收停顿时间为目标的收集器。目前很大一 部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间 短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
  CMS收集器是基于==“标记—清除”==算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为 4个步骤：
  初始标记（CMS initial mark） 初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快， 需要“Stop The World”。
  并发标记（CMS concurrent mark） 并发标记阶段就是进行GC Roots Tracing的过程。
  重新标记（CMS remark） 重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生 变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标 记的时间短，仍然需要“Stop The World”。
  并发清除（CMS concurrent sweep） 并发清除阶段会清除对象。
  由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来 说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
  优点：并发收集、低停顿
  缺点：
  1.CMS收集器对CPU资源非常敏感。其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总 吞吐量会降低。 CMS默认启动的回收线程数是（CPU数量+3）/ 4，也就是当CPU在4个以上时，并发回 收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个（譬如2个）时，CMS对用户程序的影响就可能变得很大。
  2.CMS收集器无法处理浮动垃圾。CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会 有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留 待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运 行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到 老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。要是CMS 运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将 启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
  3.CMS收集器会产生大量空间碎片。CMS是一款基于“标记—清除”算法实现的收集器，这意味着收集结束时 会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很 大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

终于写完了！！！