Java-虚拟机原理

序言

(1) Java的跨平台

理解Java的跨平台特性,是对JVM最直观的认识。所谓的“一次编译,到处运行”,为什么C/C++ 却不能实现呢?这一类语言直接使用物理硬件(或者说操作系统的内存模型),那么不同系统之间的内存模型是不同的,比如说Linux和Window,这就意味,在Window编译好的代码,却不能在Linux上运行。

《深入理解Java虚拟机》记录说,Java虚拟机规范中试图定义一种Java内存模型(JMM)来屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台上都能达到一致性的并发效果。举个现实的例子,一个只会听说中文的人,要如何和一个只会听说英文的人交流,在Java的世界里,采用的方式即是给两边的人各配一名翻译官(JVM),所以,这就是为什么JVM要有window版本,也要有Linux版本

  众所周知,Java的程序编译的最终样子是.class文件,不同虚拟机的对每一个.class文件的翻译结果都是一致的。而对于C/C++而言,编译生成的是纯二进制的机器指令,是直接面对计算机系统的内存,但是,java程序的编译结果是面向JVM,是要交付给JVM,让他再做进一步处理从而让计算机识别运行,这就是所谓的“屏蔽掉各种硬件和操作系统的内存访问差异”。这里的特点又和面向对象推崇的面向接口有着不可描述的关系,我只需要有这么个规范,不需要去知道接触你的底层原理实现。

(2) 虚拟机

JVM,全称Java Virtual Machine,英文为Java虚拟机,简单的探讨一下虚拟机这三个字,对后面的学习也是挺舒服的。百度百科描述说,“虚拟机(Virtual Machine)指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统”,但是虚拟机本质还是该计算机系统的一个进程,可以类比香港澳门具有高度自治,但本质上他们还是属于中国的。为了方便描述,我们把整个计算机当成一幢大楼,而虚拟机则是某一个楼层。大楼划分了一个区域给一个楼层,让这个楼层自己管理自己,也就对应着,计算机划分了一个内存给JVM,让JVM自己管理自己。

下面这张图是笔者的阿里云服务器上的内存使用情况,可以看到JVM足足占用了接近500M的内存。那么问题来了,JVM要这么多的内存干什么,这里面又是怎么划分?
这里写图片描述

(3) 内存

接着上面的例子,JVM是作为某一个楼层,单独占有了一大块区域(内存)。这个楼层中,有主厅,客厅,客房,这四个之间的区别之一就行,主厅和客厅是公有的,而主房和客房是私有的,这里对应到JVM层次上即是,有某几块内存,是无论是谁访问,有多少人(线程)访问,这些共有区域都可以为他们服务,而客房,私有区域,假定我们这个楼层比较牛逼,来了多少个客人,就会单独为他们建造每一件客房,每个客人都有自己私有区域,A客人是进不了B客人的房间。

  对应的JVM的层次,即是JVM运行时数据区域划分为两大块,线程隔离的区域和线程共享的区域。我们可以简单的理解为,每个客人即是一条线程。

(4) 什么是垃圾

  回想起小时候,很多小伙伴都会一起结伴过来我家玩耍,虽然大家玩得很开心,等到了时间点之后,他们就拍拍屁股走人,留下我家里一片狼藉,这个时候如果我不收拾一下垃圾的话,我老妈估计就要来拍拍我的屁股了。客人(线程)同样如此,我来过你的世界,总会留下属于我的痕迹,是不是垃圾,就要看你自己如何判定了。这里就引出另一个问题,我怎么判断是哪个才是垃圾,哪个不是垃圾,只不过是玩耍的时候,我或者小伙伴随手把老妈的戒指扔到地上而已。站在人类的视角上看,一眼就知道哪个是垃圾,哪个不是垃圾,但是计算机可不是这样,计算机有些时候确实不如人类,明明人类一眼或者几秒能完成的事情,要让计算机同样能够完成对应的功能的话,需要付出千万倍的代价才能够实现。

   笔者的老妈在家里收拾垃圾的时候,为了确保扔掉的东西是垃圾,她会将这个东西,一个一个问家里的每个人,这个东西是不是你的,你还要不要,当没有一个人承认说这个东西是属于他的时候,老妈就将这个东西视为垃圾,当有人说这个不是垃圾,是他的宝贝的时候,我老妈就这个东西标记一下。JVM采用的是类似的做法,每个对象到GC ROOT都有一定的联系和路径可达,当某个对象,对于GC ROOT不可达(即没有人说这个东西是属于他的)的对象,JVM则判定为垃圾。JVM里称此行为是可达性分析

  finalize的作用:假设一个本子已经被老妈认定为垃圾了,但老妈在扔掉垃圾的时候必须先经过一个程序,即finalize,假如在这个程序过程中,我突然想起这个本子对我还是有用的,那么这个本子就不会被认定为垃圾,从而继续保留在内存中。

(5) 垃圾回收算法

  知道什么是垃圾,找到了垃圾的位置,接下来的问题是我要怎么处理这个垃圾,即垃圾回收。我要怎样忘了你是谁,关键是要怎么字,这个动作是怎么发生的。

  标记清除:在这个楼层中,垃圾四处都有,甚至散乱在非垃圾之间或者周围,即然我老妈已经给有用的东西做个标志,那么这就意味着我老妈只需要清除那些没有标识的东西。标记清除的做法形象成就是我老妈拿着垃圾桶,从头到尾,看到垃圾就把他扔到垃圾桶里面。这种做法无疑是最简单的,但是带来的后果也是很明显的,空间碎片太多。这里的空间碎片又要做如何理解,每个物品(每个对象)都是需要占据着一定的的面积(即内存),他要站住脚跟嘛,但是如果空间碎片的太多,就会导致大的物品来临的时候,区域(内存)不够用,就会再次引发垃圾回收(意味着你打游戏的时候可能要停顿个几秒)。再举个现实中的例子,打包行李箱的时候,随随便便,散乱的放置东西,行李厢很容易被撑满,这个时候你还想放一双鞋进去,你会发现空间不够用,只能把所以东西都倒出来,整整齐齐的,从上到下从左到右的放置物品。对于空间的利用率,整齐的做法比散乱无章的行为更来得高,这就引出了另外一个做法,标记整理算法。

  标记整理:你见过有谁扫地的时候,看到垃圾就直接把扫到扫帚了里面,看到就扫。不存在的!人是有惰性的,所有总会找到更高效的做法,更习惯的做法是将垃圾扫到一起,再统一将其扔到垃圾桶中。

  复制:这个算法就有点奢侈了,不管这个内存里有多少垃圾,我老妈都统一将他们扔掉,然后重新再买一次那些我们还需要用的物品,俗称复制。因此,如果存活对象太多,这个算法是不适合的(想想就知道了-.-),其二,JVM里面需要将可用内存分为两半,一半供目前使用,一半供复制后的对象使用。
  


1、深入理解JVM

JVM的标准定义:

虚拟机是一种抽象化的计算机,通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机有自己完善的硬体架构,如处理器、堆栈、寄存器等,还具有相应的指令系统。JVM屏蔽了与具体操作系统平台相关的信息,使得Java程序只需生成在Java虚拟机上运行的目标代码(字节码),就可以在多种平台上不加修改地运行。

Java源文件—->编译器—->字节码文件
字节码文件—->JVM—->机器码
每一种平台的解释器是不同的,但是实现的虚拟机是相同的,这也就是Java为什么能够跨平台的原因了。
当一个程序从开始运行,这时虚拟机就开始实例化了,多个程序启动就会存在多个虚拟机实例。程序退出或者关闭,则虚拟机实例消亡,多个虚拟机实例之间数据不能共享。
这里写图片描述

(1) 进程角度解释JVM

虚拟机是运行在操作系统之中的,那么什么东西才能在操作系统中运行呢?当然是进程,因为进程是操作系统中的执行单位。可以这样理解,当它在运行的时候,它就是一个操作系统中的进程实例,当它没有在运行时(作为可执行文件存放于文件系统中),可以把它叫做程序。

对命令行比较熟悉的同学,都知道其实一个命令对应一个可执行的二进制文件,当敲下这个命令并且回车后,就会创建一个进程,加载对应的可执行文件到进程的地址空间中,并且执行其中的指令。下面对比C语言和Java语言的HelloWorld程序来说明问题。

首先编写C语言版的HelloWorld程序:

    #include <stdio.h>
    #include <stdlib.h>

    int main(void) {
        printf("hello world\n");
        return 0;
    }

编译C语言版的HelloWorld程序:

gcc HelloWorld.c -o HelloWorld

运行C语言版的HelloWorld程序:

zhangjg@linux:/deve/workspace/HelloWorld/src$ ./HelloWorld 
hello world

gcc编译器编译后的文件直接就是可被操作系统识别的二进制可执行文件,当我们在命令行中敲下 ./HelloWorld这条命令的时候, 直接创建一个进程, 并且将可执行文件加载到进程的地址空间中, 执行文件中的指令。

作为对比, 我们看一下Java版HelloWord程序的编译和执行形式。首先编写源文件HelloWord.java :

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

编译Java版的HelloWorld程序:

zhangjg@linux:/deve/workspace/HelloJava/src$ javac HelloWorld.java 
zhangjg@linux:/deve/workspace/HelloJava/src$ ls
HelloWorld.class  HelloWorld.java

运行Java版的HelloWorld程序:

zhangjg@linux:/deve/workspace/HelloJava/src$ java -classpath . HelloWorld 
HelloWorld

从上面的过程可以看到,我们在运行Java版的HelloWorld程序的时候,敲入的命令并不是 ./HelloWorld.class 。因为class文件并不是可以直接被操作系统识别的二进制可执行文件 。我们敲入的是java这个命令。这个命令说明,

我们首先启动的是一个叫做java的程序, 这个java程序在运行起来之后就是一个JVM进程实例。

可以看出,java命令首先启动虚拟机进程,虚拟机进程成功启动后,读取参数“HelloWorld”,把他作为初始类加载到内存,对这个类进行初始化和动态链接(关于类的初始化和动态链接会在后面的博客中介绍),然后从这个类的main方法(主线程)开始执行。也就是说我们的.class文件不是直接被系统加载后直接在cpu上执行的,而是被一个叫做虚拟机的进程托管的。首先必须虚拟机进程启动就绪,然后由虚拟机中的类加载器加载必要的class文件,包括jdk中的基础类(如String和Object等),然后由虚拟机进程解释class字节码指令,把这些字节码指令翻译成本机cpu能够识别的指令,才能在cpu上运行。

(2) JVM体系结构简介

这里写图片描述
根据上图表达的内容,我们编译之后的class文件是作为Java虚拟机的原料被输入到Java虚拟机的内部的,那么具体由谁来做这一部分工作呢?其实在Java虚拟机内部,有一个叫做类加载器的子系统,这个子系统用来在运行时根据需要加载类。注意上面一句话中的“根据需要”四个字。在Java虚拟机执行过程中,只有他需要一个类的时候,才会调用类加载器来加载这个类,并不会在开始运行时加载所有的类。就像一个人,只有饿的时候才去吃饭,而不是一次把一年的饭都吃到肚子里。一般来说,虚拟机加载类的时机,在第一次使用一个新的类的时候。本专栏后面的文章会具体讨论Java中的类加载器。

由虚拟机加载的类,被加载到Java虚拟机内存中之后,虚拟机会读取并执行它里面存在的字节码指令。虚拟机中执行字节码指令的部分叫做执行引擎。就像一个人,不是把饭吃下去就完事了,还要进行消化,执行引擎就相当于人的肠胃系统。在执行的过程中还会把各个class文件动态的连接起来。关于执行引擎的具体行为和动态链接相关的内容也会在本专栏后续的文章中进行讨论。

我们知道,Java虚拟机会进行自动内存管理。具体说来就是自动释放没有用的对象,而不需要程序员编写代码来释放分配的内存。这部分工作由垃圾收集子系统负责。

从上面的论述可以知道,

一个Java虚拟机实例在运行过程中有三个子系统来保障它的正常运行,分别是类加载器子系统执行引擎子系统垃圾收集子系统

如下图所示:
这里写图片描述
虚拟机的运行,必须加载class文件,并且执行class文件中的字节码指令。它做这么多事情,必须需要自己的空间。就像人吃下去的东西首先要放在胃中。虚拟机也需要空间来存放个中数据。首先,加载的字节码,需要一个单独的内存空间来存放;一个线程的执行,也需要内存空间来维护方法的调用关系,存放方法中的数据和中间计算结果;在执行的过程中,无法避免的要创建对象,创建的对象需要一个专门的内存空间来存放。关于虚拟机运行时数据区的内容,也会出现在本专栏后续的文章中。虚拟机的运行时内存区大概可以分成下图所示的几个部分。(这里只是大概划分, 并没有划分的很精细)
这里写图片描述

(3) 小结

1、虚拟机并不神秘,在操作系统的角度看来,它只是一个普通进程。

2、这个叫做虚拟机的进程比较特殊,它能够加载我们编写的class文件。如果把JVM比作一个人,那么class文件就是我们吃的食物。

3、加载class文件的是一个叫做类加载器的子系统。就好比我们的嘴巴,把食物吃到肚子里。

4、虚拟机中的执行引擎用来执行class文件中的字节码指令。就好比我们的肠胃,对吃进去的食物进行消化。

5、虚拟机在执行过程中,要分配内存创建对象。当这些对象过时无用了,必须要自动清理这些无用的对象。清理对象回收内存的任务由垃圾收集器负责。就好比人吃进去的食物,在消化之后,必须把废物排出体外,腾出空间可以在下次饿的时候吃饭并消化食物。

2、类文件格式

有趣的是,其实JVM并不关心Java语言或其他编程语言的语义和语法结构。当JVM执行一段程序的时候,它主要关注的是一种称为“类文件”的特定文件格式。.class类文件格式和Java代码定义的面向对象的类结构毫无关系。编译器将.java文件编译成.class文件,然后JVM对.class文件进行解译,它不关心这个类文件是由哪种编译器生成的,只要符合类文件的文件格式即可。Java编译器将一段程序编译为等价的类文件。这些类文件实际上包含了半编译的代码——字节码。之所以称之为半编译,是因为字节码并不像C/C++编译器编译的二进制文件一样会被直接执行。字节码要先被输入到JVM中,然后再转换为底层平台可以执行的最终指令。所以字节码包含了JVM的指令、符号表和其他的辅助信息。不管何种语言,能根据JVM的语法和结构约束编译生成字节码的编译器,都是一个可以在JVM上执行的候选者。

3、JVM的定位

JVM将自身定位于字节码和底层平台之间。底层平台是指操作系统(OS)和硬件。操作系统和硬件体系结构在不同的机器上可能不同,但是同一段Java程序可以不用做任何的代码修改就能在不同的机器上运行。这是在虚拟环境中执行的程序语言的独特之处。例如,由其他程序语言编译器编译的目标代码如C++和Java相比的不同点在于,C++程序需要被特定平台的编译器重新编译,从而使它能在不同的体系结构上面运行。而Java代码并不需要做任何改变,因为由Java编译器编译的字节码是在外围的JVM上执行。因此,JVM负责重新解译由Java编译器生成的字节码,并和底层平台协调工作。也就是说,尽管Java编译器生成的结果是平台独立的,但JVM与特定平台相关的。除非两台机器有相同的体系结构,在某个体系结构上安装和使用的JVM可能换一台机器就不能正常工作了。
这里写图片描述

4、JRE和JDK是什么

想要运行Java程序,我们需要JVM因为它提供了字节码的运行环境

Oracle提供了两种不同的产品:JDK(Java开发工具)和JRE(Java运行环境)。JRE是我们安装运行Java程序的最基本软件。它和Java类库以及运行Java程序所需要的其他组件一起够成了JVM的一个实现。所以,如果我们想运行一个类文件或一段字节码,仅需要JRE就够了

而JDK(Java开发工具)是JRE的超集。它包含了JRE提供的所有东西,包括创建类文件的工具如Java编译器、调试器和其他许多开发Java程序相关的工具。所以,当我们要创建类文件(编译Java源码)时,我们就需要JDK

1、JDK是用于支持Java开发的最小环境,是JRE的超集,包含Java程序设计语言、Java虚拟机、Java API类库三部分;
2、JRE是支持Java程序运行的标准环境,包含Java API类库中的Java SE API 子集和Java虚拟机两部分;

下面是一张Java API文档的截图。注意组成JDK,JRE和Java SE API核心类库的组件;通过这张截图你可以了解JRE和JDK里面都有哪些内容。
这里写图片描述

5、类加载器

首先来看一下java程序的执行过程:
这里写图片描述
从这个框图很容易从大体上了解java程序工作原理。首先,你写好java代码,保存到硬盘当中。然后你在命令行中输入

javac YourClassName.java

此时,你的java代码就被编译成字节码(.class).如果你是在Eclipse IDE或者其他开发工具中,你保存代码的时候,开发工具已经帮你完成了上述的编译工作,因此你可以在对应的目录下看到class文件。此时的class文件依然是保存在硬盘中,因此,当你在命令行中运行

java YourClassName

就完成了上面红色方框中的工作。JRE的加载器从硬盘中读取class文件,载入到系统分配给JVM的内存区域–运行数据区(Runtime Data Areas). 然后执行引擎解释或者编译类文件,转化成特定CPU的机器码,CPU执行机器码,至此完成整个过程。

接下来就重点研究一下类加载器究竟为何物?又是如何工作的?

(1) 层级结构

类加载器被组织成一种层级结构关系,也就是父子关系。其中,Bootstrap是所有类加载器的父亲。如下图所示:
这里写图片描述

类加载, 是通过JVM的类加载器从JVM外部以二进制字节流的方式加载到JVM中。但JVM本身有至少三种类加载器:BootStrap(根类加载器,C++实现, 加载位于jre/lib/rt.jar)、Extension(扩展类加载器, 主要用于加载jre/lib/ext/下的jar)、System(加载classpath环境变量所指定的class);当然还有,自定义的类加载器(用于实现自己的类加载器, 如Tomcat中就实现多个类加载器,用来管理不同的jar)。

比如, 我有一个HelloWorld的类需要加载, 首先类加载器会去从最底层的类加载器去验证这个类是否被加载, 如果没有, 则委托(委派模式)给上一层的类加载器验证是否被加载, 如果连到BootStrap类加载器都没有发现HelloWorld类被加载, 那么类加载器将执行加载任务,如果根类加载器没有加载, 则委托给下一级的Extension类加载器去尝试加载,直到这个类被加载成功。 参考下图:
这里写图片描述

(2) 具体过程

被java编译器(不仅限于,还有其他任何的可以编辑成为.class的编译器)编译过的.class文件(可能是以jar、war、jsp等形式),经过类加载器加载、验证、准备、解析、初始化之后,才可以被使用。基本的过程如下:
这里写图片描述

6、运行数据区域

这里写图片描述
Runtime Data Areas:当运行一个JVM示例时,系统将分配给它一块内存区域(这块内存区域的大小可以设置的),这一内存区域由JVM自己来管理。从这一块内存中分出一块用来存储一些运行数据,例如创建的对象,传递给方法的参数,局部变量,返回值等等。分出来的这一块就称为运行数据区域
这里写图片描述

运行数据区域可以划分为5大块:Java栈、程序计数寄存器(PC寄存器)、本地方法栈(Native Method
Stack)、Java堆、方法区域。其中,前面3各区域(PC寄存器、Java栈、本地方法栈)是每个线程独自拥有的,而后二者(Java堆、方法区)则是整个JVM实例中的所有线程共有的

(1) PC计数器

每个线程都有一个程序计算器,就是一个指针,指向方法区中的方法字节码(下一个将要执行的指令代码),由执行引擎读取下一条指令,是一个非常小的内存空间,几乎可以忽略不记。

(2) Java内存栈

① 栈是什么

栈也叫栈内存,主管Java程序的运行,是在线程创建时创建,它的生命期是跟随线程的生命期,线程结束栈内存也就释放,对于栈来说不存在垃圾回收问题,只要线程一结束该栈就Over,生命周期和线程一致,是线程私有的。

基本类型的变量和对象的引用变量都是在函数的栈内存中分配。

② 栈存储什么?

Java栈也是每个线程单独拥有,线程启动时创建。这个栈中存放着一系列的栈帧(Stack Frame),JVM只能进行压入(Push)和弹出(Pop)栈帧这两种操作。每当调用一个方法时,JVM就往栈里压入一个栈帧,方法结束返回时弹出栈帧。
这里写图片描述
栈帧中主要保存3类数据:

本地变量(Local Variables):局部(本地)变量数组中,从0开始按顺序存放方法所属对象的引用、传递给方法的参数、局部变量;

操作数栈(Operand Stack):操作数栈中存放方法执行时的一些中间变量,JVM在执行方法时压入或者弹出这些变量。其实,操作数栈是方法真正工作的地方,执行方法时,局部变量数组与操作数栈根据方法定义进行数据交换;

栈帧中数据引用:除了局部变量数组和操作数栈之外,栈帧还需要一个常量池的引用。当JVM执行到需要常量池的数据时,就是通过这个引用来访问常量池的。栈帧中的数据还要负责处理方法的返回和异常。

③ 栈运行原理

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

(3) Java内存堆

堆这块区域是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区被占满。

说明:
Jdk1.6及之前:常量池分配在永久代 。
Jdk1.7:有,但已经逐步“去永久代” 。
Jdk1.8及之后:无(java.lang.OutOfMemoryError: PermGen space,这种错误将不会出现在JDK1.8中)。

(4) 方法区域

方法区域是一个JVM实例中的所有线程共享的,当启动一个JVM实例时,方法区域被创建。它用于存运行放常量池、有关域和方法的信息、静态变量、类和方法的字节码。

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

运行常量池指这个区域存放类和接口的常量,除此之外,它还存放方法和域的所有引用。当一个方法或者域被引用的时候,JVM就通过运行常量池中的这些引用来查找方法和域在内存中的的实际地址。

(5) 本地方法栈

当程序通过JNI(Java Native Interface)调用本地方法(如C或者C++代码)时,就根据本地方法的语言类型建立相应的栈。

(6) 小结-Java内存栈/堆

Java 内存模型把 Java 虚拟机内部划分为线程栈和堆。

Java把内存分成两种,一种叫做栈内存,一种叫做堆内存
(1)在函数中定义的一些基本类型的变量和对象的引用变量都是在函数的栈内存中分配。当在一段代码块中定义一个变量时,java就在栈中为这个变量分配内存空间,当超过变量的作用域后,java会自动释放掉为该变量分配的内存空间,该内存空间可以立刻被另作他用。
(2)堆内存用于存放由new创建的对象和数组。在堆中分配的内存,由java虚拟机自动垃圾回收器来管理。在堆中产生了一个数组或者对象后,还可以在栈中定义一个特殊的变量,这个变量的取值等于数组或者对象在堆内存中的首地址,在栈中的这个特殊的变量就变成了数组或者对象的引用变量,以后就可以在程序中使用栈内存中的引用变量来访问堆中的数组或者对象,引用变量相当于为数组或者对象起的一个别名,或者代号。
(3)引用变量是普通变量,定义时在栈中分配内存,引用变量在程序运行到作用域外释放。而数组&对象本身在堆中分配,即使程序运行到使用new产生数组和对象的语句所在地代码块之外,数组和对象本身占用的堆内存也不会被释放,数组和对象在没有引用变量指向它的时候,才变成垃圾,不能再被使用,但是仍然占着内存,在随后的一个不确定的时间被垃圾回收器释放掉。这个也是java比较占内存的主要原因,实际上,栈中的变量指向堆内存中的变量,这就是Java 中的指针!

这张图演示了 Java 内存模型的逻辑视图:
这里写图片描述

7、执行引擎

类加载器将字节码载入内存之后,执行引擎以Java 字节码指令为单元,读取Java字节码。问题是,现在的java字节码机器是读不懂的,因此还必须想办法将字节码转化成平台相关的机器码。这个过程可以由解释器来执行,也可以由即时编译器(JIT Compiler)来完成。
这里写图片描述

8、垃圾回收

猿们都知道JVM的内存结构包括五大区域:程序计数器、虚拟机栈、本地方法栈、堆区、方法区。其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生、随线程而灭,因此这几个区域的内存分配和回收都具备确定性,就不需要过多考虑回收的问题,因为方法结束或者线程结束时,内存自然就跟随着回收了。而Java堆区和方法区则不一样、不一样!(怎么不一样说的朗朗上口),这部分内存的分配和回收是动态的,正是垃圾收集器所需关注的部分。

  垃圾收集器在对堆区和方法区进行回收前,首先要确定这些区域的对象哪些可以被回收,哪些暂时还不能回收,这就要用到判断对象是否存活的算法!

(1) 引用计数算法

1.1 算法分析

  引用计数是垃圾收集器中的早期策略。在这种方法中,堆中每个对象实例都有一个引用计数。当一个对象被创建时,就将该对象实例分配给一个变量,该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时,计数加1(a = b,则b引用的对象实例的计数器+1),但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时,对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时,它引用的任何对象实例的引用计数器减1。
  
1.2 优缺点

优点:引用计数收集器可以很快的执行,交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。

缺点:无法检测出循环引用。如父对象有一个对子对象的引用,子对象反过来引用父对象。这样,他们的引用计数永远不可能为0。

1.3 缺点示例

public class ReferenceFindTest {
    public static void main(String[] args) {
        MyObject object1 = new MyObject();
        MyObject object2 = new MyObject();

        object1.object = object2;
        object2.object = object1;

        object1 = null;
        object2 = null;
    }
}

这段代码是用来验证引用计数算法不能检测出循环引用。最后面两句将object1和object2赋值为null,也就是说object1和object2指向的对象已经不可能再被访问,但是由于它们互相引用对方,导致它们的引用计数器都不为0,那么垃圾收集器就永远不会回收它们

(2) 可达性分析算法

  可达性分析算法是从离散数学中的图论引入的,程序把所有的引用关系看作一张图,从一个节点GC ROOT开始,寻找对应的引用节点,找到这个节点以后,继续寻找这个节点的引用节点,当所有的引用节点寻找完毕之后,剩余的节点则被认为是没有被引用到的节点,即无用的节点,无用的节点将会被判定为是可回收的对象。
  这里写图片描述
   在Java语言中,可作为GC Roots的对象包括下面几种:

  a) 虚拟机栈中引用的对象(栈帧中的本地变量表);

  b) 方法区中类静态属性引用的对象;

  c) 方法区中常量引用的对象;

  d) 本地方法栈中JNI(Native方法)引用的对象。

(3) Java中的引用

无论是通过引用计数算法判断对象的引用数量,还是通过可达性分析算法判断对象的引用链是否可达,判定对象是否存活都与“引用”有关。在Java语言中,将引用又分为强引用、软引用、弱引用、虚引用4种,这四种引用强度依次逐渐减弱。

强引用

  在程序代码中普遍存在的,类似 Object obj = new Object() 这类引用,只要强引用还存在,垃圾收集器永远不会回收掉被引用的对象。

软引用

  用来描述一些还有用但并非必须的对象。对于软引用关联着的对象,在系统将要发生内存溢出异常之前,将会把这些对象列进回收范围之中进行第二次回收。如果这次回收后还没有足够的内存,才会抛出内存溢出异常。

弱引用

  也是用来描述非必需对象的,但是它的强度比软引用更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,都会回收掉只被弱引用关联的对象。

虚引用

  也叫幽灵引用或幻影引用(名字真会取,很魔幻的样子),是最弱的一种引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。它的作用是能在这个对象被收集器回收时收到一个系统通知。

  不要被概念吓到,也别担心,还没跑题,再深入,可就不好说了。小编罗列这四个概念的目的是为了说明,无论引用计数算法还是可达性分析算法都是基于强引用而言的

(4) 对象死亡(被回收)前的最后一次挣扎

即使在可达性分析算法中不可达的对象,也并非是“非死不可”,这时候它们暂时处于“缓刑”阶段,要真正宣告一个对象死亡,至少要经历两次标记过程。

  第一次标记:如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链,那它将会被第一次标记;

  第二次标记:第一次标记后接着会进行一次筛选,筛选的条件是此对象是否有必要执行finalize()方法。在finalize()方法中没有重新与引用链建立关联关系的,将被进行第二次标记。

  第二次标记成功的对象将真的会被回收,如果对象在finalize()方法中重新与引用链建立了关联关系,那么将会逃离本次回收,继续存活。猿们还跟的上吧,嘿嘿。

(5) 方法区如何判断是否需要回收

  猿们,方法区存储内容是否需要回收的判断可就不一样咯。方法区主要回收的内容有:废弃常量和无用的类。对于废弃常量也可通过引用的可达性来判断,但是对于无用的类则需要同时满足下面3个条件:

A、该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例;
B、加载该类的ClassLoader已经被回收;
C、该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。

(6) 标记-清除算法

标记-清除算法采用从根集合(GC Roots)进行扫描,对存活的对象进行标记,标记完毕后,再扫描整个空间中未被标记的对象,进行回收,如下图所示。标记-清除算法不需要进行对象的移动,只需对不存活的对象进行处理,在存活对象比较多的情况下极为高效,但由于标记-清除算法直接回收不存活的对象,因此会造成内存碎片。
这里写图片描述

(7) 复制算法

 复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它开始时把堆分成 一个对象 面和多个空闲面, 程序从对象面为对象分配空间,当对象满了,基于copying算法的垃圾 收集就从根集合(GC Roots)中扫描活动对象,并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞),这样空闲面变成了对象面,原来的对象面变成了空闲面,程序会在新的对象面中分配内存。
这里写图片描述

(8) 标记-整理算法

  标记-整理算法采用标记-清除算法一样的方式进行对象的标记,但在清除时不同,在回收不存活的对象占用的空间后,会将所有的存活对象往左端空闲空间移动,并更新对应的指针。标记-整理算法是在标记-清除算法的基础上,又进行了对象的移动,因此成本更高,但是却解决了内存碎片的问题。具体流程见下图:
这里写图片描述

(9) 分代收集算法

  分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代(Tenured Generation)和新生代(Young Generation),在堆区之外还有一个代就是永久代(Permanet Generation)。老年代的特点是每次垃圾收集时只有少量对象需要被回收,而新生代的特点是每次垃圾回收时都有大量的对象需要被回收,那么就可以根据不同代的特点采取最适合的收集算法。
这里写图片描述
9.1 年轻代(Young Generation)的回收算法

a) 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

b)新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区,两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区,然后清空eden区,当这个survivor0区也存放满了时,则将eden区和survivor0区存活对象复制到另一个survivor1区,然后清空eden和这个survivor0区,此时survivor0区是空的,然后将survivor0区和survivor1区交换,即保持survivor1区为空, 如此往复。

c) 当survivor1区不足以存放 eden和survivor0的存活对象时,就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC,也就是新生代、老年代都进行回收。

d) 新生代发生的GC也叫做Minor GC,MinorGC发生频率比较高(不一定等Eden区满了才触发)。

9.2 年老代(Old Generation)的回收算法

a) 在年轻代中经历了N次垃圾回收后仍然存活的对象,就会被放到年老代中。因此,可以认为年老代中存放的都是一些生命周期较长的对象。

b) 内存比新生代也大很多(大概比例是1:2),当老年代内存满时触发Major GC即Full GC,Full GC发生频率比较低,老年代对象存活时间比较长,存活率标记高。

9.3 持久代(Permanent Generation)的回收算法

  用于存放静态文件,如Java类、方法等。持久代对垃圾回收没有显著影响,但是有些应用可能动态生成或者调用一些class,例如Hibernate 等,在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代也称方法区,具体的回收可参见上文2.5节。

(10) GC什么时候触发

  由于对象进行了分代处理,因此垃圾回收区域、时间也不一样。GC有两种类型:Scavenge GC和Full GC。
  
10.1 Scavenge GC

  一般情况下,当新对象生成,并且在Eden申请空间失败时,就会触发Scavenge GC,对Eden区域进行GC,清除非存活对象,并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行,不会影响到年老代。因为大部分对象都是从Eden区开始的,同时Eden区不会分配的很大,所以Eden区的GC会频繁进行。因而,一般在这里需要使用速度快、效率高的算法,使Eden去能尽快空闲出来。

10.2 Full GC

  对整个堆进行整理,包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收,所以比Scavenge GC要慢,因此应该尽可能减少Full GC的次数。在对JVM调优的过程中,很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC:

a) 年老代(Tenured)被写满;

b) 持久代(Perm)被写满;

c) System.gc()被显示调用;

d) 上一次GC之后Heap的各域分配策略动态变化;

猜你喜欢

转载自blog.csdn.net/weixin_39190897/article/details/82143938