java虚拟机JVM总结

JVM简介

一．JVM简介

JVM 是我们Java的最基本功底了，刚开始学Java 的时候，一般都是从“Hello World ”开始的，然后会写个复杂点class ，然后再找一些开源框架，比如Spring ，Hibernate 等等，再然后就开发企业级的应用，比如网站、企业内部应用、实时交易系统等等，直到某一天突然发现做的系统咋就这么慢呢，而且时不时还来个内存溢出什么的，今天是交易系统报了StackOverflowError ，明天是网站系统报了个OutOfMemoryError ，这种错误又很难重现，只有分析Javacore 和dump 文件，运气好点还能分析出个结果，运行遭的点，就直接去庙里烧香吧！每天接客户的电话都是战战兢兢的，生怕再出什么幺蛾子了。我想Java 做的久一点的都有这样的经历，那这些问题的最终根结是在哪呢？—— JVM 。

JVM 全称是Java Virtual Machine ，Java 虚拟机，也就是在计算机上再虚拟一个计算机，这和我们使用 VMWare 不一样，那个虚拟的东西你是可以看到的，这个JVM 你是看不到的，它存在内存中。我们知道计算机的基本构成是：运算器、控制器、存储器、输入和输出设备，那这个JVM 也是有这成套的元素，运算器是当然是交给硬件CPU 还处理了，只是为了适应“一次编译，随处运行”的情况，需要做一个翻译动作，于是就用了JVM 自己的命令集，这与汇编的命令集有点类似，每一种汇编命令集针对一个系列的CPU ，比如8086 系列的汇编也是可以用在8088 上的，但是就不能跑在8051 上，而JVM 的命令集则是可以到处运行的，因为JVM 做了翻译，Java虚拟机在执行字节码时,把字节码解释成具体平台上的机器指令执行。

JVM 中我们最需要深入理解的就是它的存储部分，存储？硬盘？NO ，NO ， JVM 是一个内存中的虚拟机，那它的存储就是内存了，我们写的所有类、常量、变量、方法都在内存中，这决定着我们程序运行的是否健壮、是否高效。

二．JVM 的组成部分

我们先把JVM 这个虚拟机画出来，如下图所示：



从这个图中可以看到，JVM 是运行在操作系统之上的，它与硬件没有直接的交互。我们再来看下JVM 有哪些组成部分，如下图所示：

该图参考了网上广为流传的JVM 构成图，大家看这个图，整个JVM 分为四部分：

（1）Class Loader 类加载器

类加载器的作用是加载类文件到内存，比如编写一个HelloWord.java 程序，然后通过javac 编译成class 文件，那怎么才能加载到内存中被执行呢？Class Loader 承担的就是这个责任，那不可能随便建立一个.class 文件就能被加载的，Class Loader 加载的class 文件是有格式要求，在《JVM Specification 》中式了定义Class 文件的结构。

友情提示：Class Loader 只管加载，只要符合文件结构就加载，至于说能不能运行，则不是它负责的，那是由Execution Engine 负责的。

（2） Execution Engine 执行引擎

执行引擎也叫做解释器(Interpreter) ，负责解释命令，提交操作系统执行。

（3） Native Interface 本地接口

本地接口的作用是融合不同的编程语言为Java 所用，它的初衷是融合C/C++ 程序，Java 诞生的时候是C/C++ 横行的时候，要想立足，必须有一个聪明的、睿智的调用C/C++ 程序，于是就在内存中专门开辟了一块区域处理标记为native 的代码，它的具体做法是Native Method Stack 中登记native 方法，在Execution Engine 执行时加载native libraies 。目前该方法使用的是越来越少了，除非是与硬件有关的应用，比如通过Java 程序驱动打印机，或者Java 系统管理生产设备，在企业级应用中已经比较少见，因为现在的异构领域间的通信很发达，比如可以使用Socket 通信，也可以使用Web Service 等等，不多做介绍。

（3） Runtime data area 运行数据区

运行数据区是整个JVM 的重点。我们所有写的程序都被加载到这里，之后才开始运行，Java 生态系统如此的繁荣，得益于该区域的优良自治。

整个JVM 框架由加载器加载class文件到内存，然后执行器在内存中处理数据，解释命令，提交操作系统执行，需要与异构系统交互的可以通过本地接口进行。

三．JVM加载class文件的原理机制

1.Java中的所有类，必须被装载到jvm中才能运行，这个装载工作是由jvm中的类装载器Class Loader完成的,类装载器所做的工作实质是把类文件从硬盘读取到内存中 。

2.java中的类大致分为三种：

1）.系统类

2）.扩展类

3）.由程序员自定义的类

3.类加载方式，有两种

1）.隐式加载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中，

2）.显式加载， 通过class.forname()等方法，显式加载需要的类 。即反射机制。

4.类加载的动态性体现

一个应用程序总是由n多个类组成，Java程序启动时，并不是一次把所有的类全部加载后再 运行，它总是先把保证程序运行的基础类一次性加载到jvm中，其它类等到jvm用到的时候再加载，这样的好处是节省了内存的开销，因为java最早就是为嵌入式系统而设计的，内存宝贵，这是一种可以理解的机制，而用到时再加载这也是java动态性的一种体现

5．java类装载器

Java中的类装载器实质上也是类，功能是把类载入jvm中，值得注意的是jvm的类装载器并不是一个，而是三个，层次结构如下：

Bootstrap Loader - 负责加载系统类

|

- - ExtClassLoader - 负责加载扩展类

|

- - AppClassLoader - 负责加载应用类

为什么要有三个类加载器，一方面是分工，各自负责各自的区块，另一方面为了实现委托模型，下面会谈到该模型

6. 类加载器之间是如何协调工作的

前面说了，java中有三个类加载器，问题就来了，碰到一个类需要加载时，它们之间是如何协调工作的，即java是如何区分一个类该由哪个类加载器来完成呢。

在这里java采用了委托模型机制，这个机制简单来讲，就是“类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入，如果Parent 找不到,那么才由自己依照自己的搜索路径搜索类”，注意喔，这句话具有递归性

1. public class TestClass {

2. public static void main(String[] args) throws Exception{

3. //调用class加载器

4. ClassLoader cl = TestClass.class .getClassLoader();

5. System.out.println(cl);

6. //调用上一层Class加载器

7. ClassLoader clParent = cl.getParent();

8. System.out.println(clParent);

9. //调用根部Class加载器

10. ClassLoader clRoot = clParent.getParent();

11. System.out.println(clRoot);

12. }

13. }

1. Run， Console中出现的log信息如下：

2. sun.misc.Launcher$AppClassLoader@7259da

3. sun.misc.Launcher$ExtClassLoader@16930e2

4. null

可以看出TestClass是由AppClassLoader加载器加载的 AppClassLoader的Parent 加载器是 ExtClassLoader 但是ExtClassLoader的Parent为 null 是怎么回事呵，朋友们留意的话，前面有提到Bootstrap Loader是用C++语言写的,依java的观点来看，逻辑上并不存在Bootstrap Loader的类实体，所以在java程序代码里试图打印出其内容时，我们就会看到输出为null

【注：以下内容大部分引用java深度历险】

弄明白了上面的示例，接下来直接进入类装载的委托模型实例，写两个文件，如下：

Java代码

1. public class Test1 {

2. public static void main(String[] args) throws Exception {

3. System.out.println(Test1.class .getClassLoader());

4. Test2 test2 = new Test2();

5. test2.print();

6. }

7.

8. }

9.

10. public class Test2 {

11. public void print(){

12. System.out.println(Test2.class );

13. System.out.println(this .getClass());

14. System.out.println(Test2.class .getClassLoader());

15. }

16. }

Result代码

1. Run,Console出现log如下：

2. sun.misc.Launcher$AppClassLoader@7259da

3. class com.java.test.Test2

4. class com.java.test.Test2

5. sun.misc.Launcher$AppClassLoader@7259da

7. 预先加载与依需求加载

Java 运行环境为了优化系统，提高程序的执行速度，在 JRE 运行的开始会将 Java 运行所需要的基本类采用预先加载（ pre-loading ）的方法全部加载要内存当中，因为这些单元在 Java 程序运行的过程当中经常要使用的，主要包括 JRE 的 rt.jar 文件里面所有的 .class 文件。 当 java.exe 虚拟机开始运行以后，它会找到安装在机器上的 JRE 环境，然后把控制权交给 JRE ， JRE 的类加载器会将 lib 目录下的 rt.jar 基础类别文件库加载进内存，这些文件是 Java 程序执行所必须的，所以系统在开始就将这些文件加载，避免以后的多次 IO 操作，从而提高程序执行效率。

相对于预先加载，我们在程序中需要使用自己定义的类的时候就要使用依需求加载方法（ load-on-demand ），就是在 Java 程序需要用到的时候再加载，以减少内存的消耗，因为 Java 语言的设计初衷就是面向嵌入式领域的。

8. 自定义类加载机制

之前我们都是调用系统的类加载器来实现加载的，其实我们是可以自己定义类加载器的。利用 Java 提供的 java.net.URLClassLoader 类就可以实现。下面我们看一段范例：

Java代码

1. try {

2. URL url = new URL( "file:/d:/test/lib/" );

3. URLClassLoader urlCL = new URLClassLoader( new URL[]{url});

4. Class c = urlCL.loadClass("TestClassA" );

5. TestClassA object = (TestClassA)c.newInstance();

6. object.method();

7. }catch (Exception e){

8. e.printStackTrace();

9. }

我们通过自定义的类加载器实现了 TestClassA 类的加载并调用 method （）方法。分析一下这个程序：首先定义 URL 指定类加载器从何处加载类， URL 可以指向网际网络上的任何位置，也可以指向我们计算机里的文件系统 ( 包含 JAR 文件 ) 。上述范例当中我们从 file:/d:/test/lib/ 处寻找类；然后定义 URLClassLoader 来加载所需的类，最后即可使用该实例了。

9. 类加载器的阶层体系

讨论了这么多以后，接下来我们仔细研究一下 Java 的类加载器的工作原理：

当执行 java ***.class 的时候， java.exe 会帮助我们找到 JRE ，接着找到位于 JRE 内部的 jvm.dll ，这才是真正的 Java 虚拟机器 , 最后加载动态库，激活 Java 虚拟机器。虚拟机器激活以后，会先做一些初始化的动作，比如说读取系统参数等。一旦初始化动作完成之后，就会产生第一个类加载器―― Bootstrap Loader ， Bootstrap Loader 是由 C++ 所撰写而成，这个 Bootstrap Loader 所做的初始工作中，除了一些基本的初始化动作之外，最重要的就是加载 Launcher.java 之中的 ExtClassLoader ，并设定其 Parent 为 null ，代表其父加载器为 BootstrapLoader 。然后 Bootstrap Loader 再要求加载 Launcher.java 之中的 AppClassLoader ，并设定其 Parent 为之前产生的 ExtClassLoader 实体。这两个加载器都是以静态类的形式存在的。这里要请大家注意的是， Launcher$ExtClassLoader.class 与 Launcher$AppClassLoader.class 都是由 Bootstrap Loader 所加载，所以 Parent 和由哪个类加载器加载没有关系。

下面的图形可以表示三者之间的关系：

BootstrapLoader ，AppClassLoader，ExtClassLoader

这三个加载器就构成我们的 Java 类加载体系。他们分别从以下的路径寻找程序所需要的类：

BootstrapLoader ： sun.boot.class.path

ExtClassLoader: java.ext.dirs

AppClassLoader: java.class.path

这三个系统参量可以通过 System.getProperty() 函数得到具体对应的路径。大家可以自己编程实现查看具体的路径。

四．JVM内存管理和垃圾回收机制

Java虚拟机会将内存分为几个不同的管理区，这些区域各自有各自的用途，根据不同的特点，承担不同的任务以及在垃圾回收时运用不同的算法。总体分为下面几个部分：

程序计数器（Program Counter Register）、JVM虚拟机栈（JVM Stacks）、本地方法栈（Native Method Stacks）、堆（Heap）、方法区（Method Area）。



作为Java程序员我们很难去控制JVM的内存回收，只能根据它的原理去适应，尽量提高程序的性能。下面开始讲解Java垃圾回收，即Garbage Collection,GC。

随着程序的运行，内存中存在的实例对象、变量等信息占据的内存越来越多，如果不及时进行垃圾回收，必然会带来程序性能的下降，甚至会因为可用内存不足造成一些不必要的系统异常。

在我们上面介绍的五大区中，有三个是不需要进行垃圾回收的：程序计数器、JVM栈、本地方法栈。因为它们的生命周期是和线程同步的，随着线程的销毁，它们占用的内存会自动释放，所以只有方法区和堆需要进行GC。具体到哪些对象的话，简单概况一句话：如果某个对象已经不存在任何引用，那么它可以被回收。通俗解释一下就是说，如果一个对象，已经没有什么作用了，就可以被当废弃物被回收了。

五．Java程序性能优化

gc()的调用

调用gc 方法暗示着Java 虚拟机做了一些努力来回收未用对象，以便能够快速地重用这些对象当前占用的内存。当控制权从方法调用中返回时，虚拟机已经尽最大努力从所有丢弃的对象中回收了空间，调用System.gc() 等效于调用Runtime.getRuntime().gc()。

finalize()的调用及重写

gc 只能清除在堆上分配的内存(纯java语言的所有对象都在堆上使用new分配内存)，而不能清除栈上分配的内存（当使用JNI技术时,可能会在栈上分配内存，例如java调用c程序，而该c程序使用malloc分配内存时）。因此，如果某些对象被分配了栈上的内存区域，那gc就管不着了，对栈上的对象进行内存回收就要靠finalize()。举个例子来说,当java 调用非java方法时（这种方法可能是c或是c++的）,在非java代码内部也许调用了c的malloc()函数来分配内存，而且除非调用那个了 free() 否则不会释放内存(因为free()是c的函数),这个时候要进行释放内存的工作,gc是不起作用的,因而需要在finalize()内部的一个固有方法调用free()。

优秀的编程习惯

（1）避免在循环体中创建对象，即使该对象占用内存空间不大。

（2）尽量及时使对象符合垃圾回收标准。

（3）不要采用过深的继承层次。

（4）访问本地变量优于访问类中的变量。

六．常见问题

1、内存溢出

就是你要求分配的java虚拟机内存超出了系统分配的内存，系统不能满足需求，于是产生溢出。在Java虚拟机规范的描述中，除了PC(程序计数器)寄存器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError异常的可能。当发生OutOfMemoryError异常时，无法用try...catch捕捉。

2、内存泄漏

是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。

七．当异常发生时，JVM采取的措施

异常情况在Java中被称作Error(错误)或Exception(异常),是Throwable类的子类,在程序中的原因是:①动态链接错,如无法找到所需的class文件，即编译过程。②运行时错,如对一个空指针的引用。

检查与当前方法相联系的catch子句表。每个catch子句包含其有效指令范围,能够处理的异常类型,以及处理异常的代码块地址。与异常相匹配的catch子句应该符合下面的条件：造成异常的指令在其指令范围之内,发生的异常类型是其能处理的异常类型及其子类型。如果找到了匹配的 catch子句,那么系统转移到指定的异常处理块处执行;如果没有找到异常处理块,重复寻找匹配的catch子句的过程,直到当前方法的所有嵌套的 catch子句都被检查过。

由于虚拟机从第一个匹配的catch子句处继续执行,所以catch子句表中的顺序是很重要的。因为Java代码是结构化的,因此总可以把某个方法的所有的异常处理器都按序排列到一个表中,对任意可能的程序计数器的值,都可以用线性的顺序找到合适的异常处理块,以处理在该程序计数器值下发生的异常情况。

·如果找不到匹配的catch子句,那么当前方法得到一个"未截获异常"的结果并返回到当前方法的调用者,好像异常刚刚在其调用者中发生一样。如果在调用者中仍然没有找到相应的异常处理块,那么这种错误传播将被继续下去。如果错误被传播到最顶层,那么系统将调用一个缺省的异常处理块。