JVM学习(二)

上一篇文章简单介绍了一下jvm的几个概念。接下来这篇文章将跟大家探讨一下JVM的工作原理。

在JDK1.7及其以前我们所使用的都是Sun公司的HotSpot，但由于Sun公司和BEA公司都被oracle收购，jdk1.8将采用Sun公司的HotSpot和BEA公司的JRockit两个JVM中精华形成jdk1.8的JVM。

我们都知道java一直宣传的口号是：一次编译，到处运行。那么它如何实现的呢？我们看下图：

我们先看一段代码：

public class HelloWorld { 
   public static void main(String[] args) { 
      System.out.print("Hello world"); 
   } 
}

这段程序从编译到运行，最终打印出“Hello world”中间经过了哪些步骤呢？我们直接上图：

这里我们先不讨论类加载的问题。

JVM的生命周期

1.启动。启动一个Java程序，一个JVM实例就产生。拥有public static void main(String[] args)函数的class可以作为JVM实例运行的起点。

2.运行。main()作为程序初始线程的起点，任何其他线程均可由该线程启动。JVM内部有两种线程：守护线程和非守护线程，main()属于非守护线程，守护线程通常由JVM使用，程序可以指定创建的线程为守护线程。

3.消亡。当程序中的所有非守护线程都终止时，JVM才退出；若安全管理器允许，程序也可以使用Runtime类或者System.exit()来退出。

JVM执行引擎实例则对应了属于用户运行程序线程它是线程级别的。

JVM的体系结构

JVM的数据运行区

JVM调优主要就是优化 Heap堆 和 Method Area 方法区。

Method Area方法区

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间。

静态变量+常量+类信息+运行时常量池存在方法区中，实例变量存在堆内存中。

Stack 栈

栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧F1，并被压入到栈中，A方法又调用了B方法，于是产生栈帧F2也被压入栈，B方法又调用了C方法，于是产生栈帧F3也被压入栈…… 依次执行完毕后，先弹出后进......F3栈帧，再弹出F2栈帧，再弹出F1栈帧。

遵循“先进后出”/“后进先出”原则。

Heap 堆

堆这块区域是JVM中最大的，应用的对象和数据都是存在这个区域，这块区域也是线程共享的，也是 gc 主要的回收区，一个 JVM 实例只存在一个堆类存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，以方便执行器执行，堆内存分为三部分：

① 新生区

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存者区（Survivor pace），所有的类都是在伊甸区被new出来的。幸存区有两个：0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园进行垃圾回收（Minor GC）,将伊甸园中的剩余对象移动到幸存0区。若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1去也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生Major GC（FullGCC），进行养老区的内存清理。若养老区执行Full GC 之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：

a.Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

b.代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

② 养老区

养老区用于保存从新生区筛选出来的 JAVA 对象，一般池对象都在这个区域活跃。

③ 永久区

永久存储区是一个常驻内存区域，用于存放JDK自身所携带的 Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭 JVM 才会释放此区域所占用的内存。

如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。原因有二：

a. 程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。

b. 大量动态反射生成的类不断被加载，最终导致Perm区被占满。

JVM垃圾回收

（一）引用计数（Reference Counting）:

比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。

（二）标记-清除（Mark-Sweep）:

此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。

（三）复制（Copying）:

此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。

（四）标记-整理（Mark-Compact）:

此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。