0.1.JVM&垃圾回收

JVM(Java Virtual Machine，Java虚拟机)

    Java程序的跨平台特性主要是指字节码文件可以在任何具有Java虚拟机的计算机或者电子设备上运行，Java虚拟机中的Java解释器负责将字节码文件解释成为特定的机器码进行运行。因此在运行时，Java源程序需要通过编译器编译成为.class文件。众所周知java.exe是java class文件的执行程序，但实际上java.exe程序只是一个执行的外壳，它会装载jvm.dll（windows下，下皆以windows平台为例，linux下和solaris下其实类似，为：libjvm.so），这个动态连接库才是java虚拟机的实际操作处理所在。

    JVM是JRE的一部分。它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java语言最重要的特点就是跨平台运行。使用JVM就是为了支持与操作系统无关，实现跨平台。所以，JAVA虚拟机JVM是属于JRE的，而现在我们安装JDK时也附带安装了JRE(当然也可以单独安装JRE)。

JVM 允许一个应用并发执行多个线程。Hotspot JVM 中的 Java 线程与原生操作系统线程有直接的映射关系。当线程本地存储、缓冲区分配、同步对象、栈、程序计数器等准备好以后，就会创建一个操作系统原生线程。Java 线程结束，原生线程随之被回收。操作系统负责调度所有线程，并把它们分配到任何可用的 CPU 上。当原生线程初始化完毕，就会调用 Java 线程的 run() 方法。run() 返回时，被处理未捕获异常，原生线程将确认由于它的结束是否要终止 JVM 进程（比如这个线程是最后一个非守护线程）。当线程结束时，会释放原生线程和 Java 线程的所有资源。

java运行时环境(JRE)

    java运行时环境是JVM的一个超集。JVM对于一个平台或者操作系统是明确的，而JRE确实一个一般的概念，他代表了完整的运行时环境。我们在jre文件夹中看到的所有的jar文件和可执行文件都会变成运行时的一部分。事实上，运行时JRE变成了JVM。所以对于一般情况时候使用JRE，对于明确的操作系统来说使用JVM。当你下载了JRE的时候，也就自动下载了JVM。

java开发工具箱(JDK)

    java开发工具箱指的是编写一个java应用所需要的所有jar文件和可执行文件。事实上，JRE是JKD的一部分。如果你下载了JDK,你会看到一个名叫JRE的文件夹在里面。JDK中要被牢记的jar文件就是tools.jar,它包含了用于执行java文档的类还有用于类签名的jar包。

即时编译器(JIT)

    即时编译器是种特殊的编译器，它通过有效的把字节码变成机器码来提高JVM的效率。JIT这种功效很特殊，因为他把检测到的相似的字节码编译成单一运行的机器码，从而节省了CPU的使用。这和其他的字节码编译器不同，因为他是运行时(从字节码到机器码）而不是在程序运行之前。正是因为这些，动态编译这个词汇才和JIT有那么紧密的关系。

JVM内存区域划分

粗略分来，JVM的内部体系结构分为三部分，分别是：类装载器（ClassLoader）子系统，运行时数据区，和执行引擎。

类装载器

    每一个Java虚拟机都由一个类加载器子系统（class loader subsystem），负责加载程序中的类型（类和接口），并赋予唯一的名字。每一个Java虚拟机都有一个执行引擎（execution engine）负责执行被加载类中包含的指令。JVM的两种类装载器包括：启动类装载器和用户自定义类装载器，启动类装载器是JVM实现的一部分，用户自定义类装载器则是Java程序的一部分，必须是ClassLoader类的子类。

JVM 中有多个类加载器，分饰不同的角色。每个类加载器由它的父加载器加载。bootstrap 加载器除外，它是所有最顶层的类加载器。

• Bootstrap 加载器 一般由本地代码实现，因为它在 JVM 加载以后的早期阶段就被初始化了。bootstrap 加载器负责载入基础的 Java API，JRE/lib/rt.jar。它只加载拥有较高信任级别的启动路径下找到的类，因此跳过了很多普通类需要做的校验工作。
• Extension 加载器 加载了标准 Java 扩展 API 中的类，比如 security 的扩展函数。JRE/lib/ext或者java.ext.dirs指向的目录（Class.forName（））
• Application类加载器 – CLASSPATH环境变量, 由-classpath或-cp选项定义,或者是JAR中的Manifest的classpath属性定义.（System 加载器 是应用的默认类加载器，比如从 classpath 中加载应用类）

用户自定义类加载器 也可以用来加载应用类。使用自定义的类加载器有很多特殊的原因：运行时重新加载类或者把加载的类分隔为不同的组，典型的用法比如 web 服务器 Tomcat。

类加载器的工作原理

类加载器的工作原理基于三个机制：委托、可见性和单一性。类加载器使用委托机制的工作原理。

委托机制

当一个类加载和初始化的时候，类仅在有需要加载的时候被加载。假设你有一个应用需要的类叫作Abc.class，首先加载这个类的请求由Application类加载器委托给它的父类加载器Extension类(延伸)加载器，然后再委托给Bootstrap类加载器。Bootstrap类加载器会先看看rt.jar中有没有这个类，因为并没有这个类，所以这个请求由回到Extension类加载器，它会查看jre/lib/ext目录下有没有这个类，如果这个类被Extension类加载器找到了，那么它将被加载，而Application类加载器不会加载这个类；而如果这个类没有被Extension类加载器找到，那么再由Application类加载器从classpath中寻找。记住classpath定义的是类文件的加载目录，而PATH是定义的是可执行程序如javac，java等的执行路径。

可见性机制

根据可见性机制，子类加载器可以看到父类加载器加载的类，而反之则不行。所以下面的例子中，当Abc.class已经被Application类加载器加载过了，然后如果想要使用Extension类加载器加载这个类，将会抛出java.lang.ClassNotFoundException异常。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

package test;   import java.util.logging.Level; import java.util.logging.Logger;   /** * Java program to demonstrate How ClassLoader works in Java, * in particular about visibility principle of ClassLoader. * * @author Javin Paul */  public class ClassLoaderTest {  public static void main(String args[]) {             try {                          //printing ClassLoader of this class                 System.out.println("ClassLoaderTest.getClass().getClassLoader() : "                                      + ClassLoaderTest.class.getClassLoader());                   //trying to explicitly load this class again using Extension class loader                 Class.forName("test.ClassLoaderTest", true                                 ,  ClassLoaderTest.class.getClassLoader().getParent());             } catch (ClassNotFoundException ex) {                 Logger.getLogger(ClassLoaderTest.class.getName()).log(Level.SEVERE, null, ex);             }         }       }

单一性机制

根据这个机制，父加载器加载过的类不能被子加载器加载第二次。虽然重写违反委托和单一性机制的类加载器是可能的，但这样做并不可取。你写自己的类加载器的时候应该严格遵守这三条机制。

如何显式的加载类

Java提供了显式加载类的API：Class.forName(classname)和Class.forName(classname, initialized, classloader)。就像上面的例子中，你可以指定类加载器的名称以及要加载的类的名称。类的加载是通过调用java.lang.ClassLoader的loadClass()方法，而loadClass()方法则调用了findClass()方法来定位相应类的字节码。在这个例子中Extension类加载器使用了java.net.URLClassLoader，它从JAR和目录中进行查找类文件，所有以”/”结尾的查找路径被认为是目录。如果findClass()没有找到那么它会抛出java.lang.ClassNotFoundException异常，而如果找到的话则会调用defineClass()将字节码转化成类实例，然后返回。

执行引擎：它或者在执行字节码，或者执行本地方法

    主要的执行技术有:解释，即时编译，自适应优化、芯片级直接执行其中解释属于第一代JVM，即时编译JIT属于第二代JVM，自适应优化（目前Sun的HotspotJVM采用这种技术）则吸取第一代JVM和第二代JVM的经验，采用两者结合的方式 。

    自适应优化：开始对所有的代码都采取解释执行的方式，并监视代码执行情况，然后对那些经常调用的方法启动一个后台线程，将其编译为本地代码，并进行仔细优化。若方法不再频繁使用，则取消编译过的代码，仍对其进行解释执行。

运行时数据区：主要包括：方法区，堆，Java栈，PC寄存器，本地方法栈

• 方法区和堆由所有线程共享

    堆：它是JVM用来存储对象实例以及数组值的区域，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中的对象的内存需要等待GC进行回收。

为了支持垃圾回收机制，堆被分为了下面三个区域：

• 新生代
• • 经常被分为 Eden 和 Survivor
• 老年代
• 永久代

内存管理

通常我们说的JVM内存回收总是在指堆内存回收，确实只有堆中的内容是动态申请分配的，所以以上对象的年轻代和年老代都是指的JVM的Heap空间，而持久代则是之前提到的MethodArea，不属于Heap。GC的基本原理：将内存中不再被使用的对象进行回收，GC中用于回收的方法称为收集器，由于GC需要消耗一些资源和时间，Java在对对象的生命周期特征进行分析后，按照新生代、旧生代的方式来对对象进行收集，以尽可能的缩短GC对应用造成的暂停

对象和数组永远不会显式回收，而是由垃圾回收器自动回收。通常，过程是这样的：

（1）对新生代的对象的收集称为minor GC；

（2）对旧生代的对象的收集称为Full GC；

•  新生代 GC（Minor GC）：指发生在新生代的垃圾收集动作，因为 Java 对象大多都具

备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。

•  老年代 GC（Major GC  / Full GC）：指发生在老年代的 GC，出现了 Major GC，经常

会伴随至少一次的 Minor GC（但非绝对的，在 ParallelScavenge 收集器的收集策略里,就有直接进行 Major GC 的策略选择过程） 。MajorGC 的速度一般会比 Minor GC 慢 10倍以上。

Minor GC触发机制：

当年轻代满时就会触发Minor GC，这里的年轻代满指的是Eden代满，Survivor满不会引发GC

Full GC触发机制：

当年老代满时会引发Full GC，Full GC将会同时回收年轻代、年老代，

当永久代满时也会引发Full GC，会导致Class、Method元信息的卸载

（3）程序中主动调用System.gc()强制执行的GC为Full GC。

    不同的引用类型， GC会采用不同的方法进行回收，JVM对象的引用分为了四种类型：

（1）强引用：默认情况下，对象采用的均为强引用（这个对象的实例没有其他对象引用

，GC时才会被回收）

（2）软引用：软引用是Java中提供的一种比较适合于缓存场景的应用（只有在内存不够用

的情况下才会被GC）

（3）弱引用：在GC时一定会被GC回收

（4）虚引用：由于虚引用只是用来得知对象是否被GC

• Young（年轻代）虚拟机给每个对象定义了一个对象年龄（Age）计数器。

    年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制年老区(Tenured。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空的。

• Tenured（年老代）

    年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。

• Perm（持久代）

    用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

（Java有四种类型的垃圾回收器：

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

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

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

4.G1垃圾回收器（G1 Garbage Collector）

1、串行垃圾回收器

串行垃圾回收器通过持有应用程序所有的线程进行工作。它为单线程环境设计，只使用一个单独的线程进行垃圾回收，通过冻结所有应用程序线程进行工作，所以可能不适合服务器环境。它最适合的是简单的命令行程序。通过JVM参数-XX:+UseSerialGC可以使用串行垃圾回收器。

2、并行垃圾回收器

并行垃圾回收器也叫做 throughput collector 。它是JVM的默认垃圾回收器。与串行垃圾回收器不同，它使用多线程进行垃圾回收。相似的是，也会冻结所有的应用程序线程当执行垃圾回收的时候

3、并发标记扫描垃圾回收器

并发标记垃圾回收使用多线程扫描堆内存，标记需要清理的实例并且清理被标记过的实例。并发标记垃圾回收器只会在下面两种情况持有应用程序所有线程。

1.当标记的引用对象在tenured区域；2.在进行垃圾回收的时候，堆内存的数据被并发的改变。

相比并行垃圾回收器，并发标记扫描垃圾回收器使用更多的CPU来确保程序的吞吐量。如果我们可以为了更好的程序性能分配更多的CPU，那么并发标记上扫描垃圾回收器是更好的选择相比并发垃圾回收器。通过JVM参数 XX:+USeParNewGC 打开并发标记扫描垃圾回收器。

4、G1垃圾回收器

G1垃圾回收器适用于堆内存很大的情况，他将堆内存分割成不同的区域，并且并发的对其进行垃圾回收。G1也可以在回收内存之后对剩余的堆内存空间进行压缩。并发扫描标记垃圾回收器在STW情况下压缩内存。G1垃圾回收会优先选择第一块垃圾最多的区域。通过JVM参数 –XX:+UseG1GC 使用G1垃圾回收器）

非堆内存

非堆内存指的是那些逻辑上属于 JVM 一部分对象，但实际上不在堆上创建。

非堆内存包括：

• 永久代，包括：
• • • 方法区
    • 驻留字符串（interned strings）
• • 代码缓存(Code Cache)：用于编译和存储那些被 JIT 编译器编译成原生代码的方法。

    方法区：当JVM的类装载器加载.class文件，并进行解析，把解析的类型信息放入方法区。方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，当开发人员在程序中通过Class对象中的getName、isInterface等方法来获取信息时，这些数据都来源于方法区域，同时方法区域也是全局共享的，在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。

• Java栈和PC寄存器由线程独享

    JVM栈是线程私有的，每个线程创建的同时都会创建JVM栈，JVM栈中存放的为当前线程中局部基本类型的变量（java中定义的八种基本类型：boolean、char、byte、short、int、long、float、double）、部分的返回结果以及Stack Frame，非基本类型的对象在JVM栈上仅存放一个指向堆上的地址

本地方法栈：存储本地方法调用的状态

程序计数器 : 程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。如果线程正在执行的是一个Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie 方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在Java 虚拟机规范中没有规定任何OutOfMemoryError 情况的区域。