Java程序运行机制及其运行过程

  • Post author:
  • Post category:java


java两种核心机制:java虚拟机跟垃圾回收机制。本文主要讲的是jvm运行java程序。

(一)终端中如何运行一个java程序(这个是我在mac下运行的,windows下原理是一样的,大同小异)

做这个事情的前提下,一定是jdk已经安装好了并且没任何问题。

首先要想运行java类,应先有个java类

1.创建个名为java的文件夹,在文件夹下面创建个以.java结尾的文件(我是用sublime编辑的,其他编辑器也行),这儿以HelloWorld为例

2.通过命令编译文件

192:libexec huayu$ javac /Users/huayu/Desktop/java/HelloWorld.java 

执行完命令后你会发现在java文件夹下多出来一个以.class结尾的文件

3.执行编译好的类文件(注意一定要在类文件所在的位置下去执行命令,要不然则它会报找不到类的错误),你将会在终端中看到以下输出

192:java huayu$ java HelloWolrd
HelloWorld

到此处在终端中编译并运行了第一个java程序。

(二)jvm的运行原理

以上例子的目的不是为了让我们学会怎么在终端中运行java程序,而是希望大家知道在以上过程中都进行了哪些操作。

javac程序是一个Java编译器。它将文件HelloWorld.java编译成HelloWorld.class文件,并发送到java虚拟机。虚拟机执行编译器放在class文件中的字节码。

(1)JVM 加载 class 文件的原理机制

JVM 中类的装载是由类加载器(ClassLoader)和它的子类来实现的,Java 中的类加载器是 一个重要的 Java 运行时系统组件,它负责在运行时查找和装入类文件中的类。

由于 Java 的跨平台性,经过编译的 Java 源程序并不是一个可执行程序,而是一个或多个类文件。 当 Java 程序需要使用某个类时,JVM 会确保这个类已经被加载、连接(验证、准备和解析)和 初始化。

类的加载是指把类的.class 文件中的数据读入到内存中,通常是创建一个字节数组读 入.class 文件,然后产生与所加载类对应的 Class 对象。加载完成后,Class 对象还不完整,所以此时的类还不可用。当类被加载后就进入连接阶段,这一阶段包括验证、准备(为静态变量分 配内存并设置默认的初始值)和解析(将符号引用替换为直接引用)三个步骤。最后 JVM 对类 进行初始化,包括:1)如果类存在直接的父类并且这个类还没有被初始化,那么就先初始化父类; 2)如果类中存在初始化语句,就依次执行这些初始化语句。

类的加载是由类加载器完成的,类加载器包括:根加载器(BootStrap)、扩展加载器(Extension)、 系统加载器(System)和用户自定义类加载器(java.lang.ClassLoader 的子类)。从 Java 2(JDK 1.2)开始,类加载过程采取了父亲委托机制(PDM)。PDM 更好的保证了 Java 平台的安全性, 在该机制中,JVM 自带的 Bootstrap 是根加载器,其他的加载器都有且仅有一个父类加载器。类的加载首先请求父类加载器加载,父类加载器无能为力时才由其子类加载器自行加载。JVM 不会向 Java 程序提供对 Bootstrap 的引用。

下面是关于几个类加载器的说明:

Bootstrap:一般用本地代码实现,负责加载 JVM 基础核心类库(rt.jar);

Extension:从 java.ext.dirs 系统属性所指定的目录中加载类库,它的父加载器是 Bootstrap;

System:又叫应用类加载器,其父类是 Extension。它是应用最广泛的类加载器。它从环境变量 classpath 或者系统属性 java.class.path 所指定的目录中记载类,是用户自定义加载 器的默认父加载器。

(2)java的“一次编译到处运行”又是怎么做到的呢?

虚拟机可以理解成一个以字节码为机器指令的CPU。

对于不同的运行平台,有不同的虚拟机。

java虚拟机机制屏蔽了底层运行平台的差别,实现了“一次编译,随处运行”。

(二)垃圾回收机制(GC)

GC 是什么?为什么要有 GC?

GC 是垃圾收集的意思,内存处理是编程人员容易出现问题的地方,忘记或者错误的内存回 收会导致程序或系统的不稳定甚至崩溃,Java 提供的 GC 功能可以自动监测对象是否超过作用 域从而达到自动回收内存的目的,Java 语言没有提供释放已分配内存的显示操作方法。Java 程 序员不用担心内存管理,因为垃圾收集器会自动进行管理。要请求垃圾收集,可以调用下面的 方法之一:System.gc() 或 Runtime.getRuntime().gc() ,但 JVM 可以屏蔽掉显示的垃圾回收调用。 垃圾回收可以有效的防止内存泄露,有效的使用可以使用的内存。垃圾回收器通常是作为一个 单独的低优先级的线程运行,不可预知的情况下对内存堆中已经死亡的或者长时间没有使用的 对象进行清除和回收,程序员不能实时的调用垃圾回收器对某个对象或所有对象进行垃圾回收(程序员不能精确把控回收时间,调用System.gc() 或 Runtime.getRuntime().gc() 这两个方法,就相当于通知GC来收,催了一下而已,来什么时候来收还不一定)。

在 Java 诞生初期,垃圾回收是 Java 最大的亮点之一,因为服务器端的编程需要有效的防止内存 泄露问题,然而时过境迁,如今 Java 的垃圾回收机制已经成为被诟病的东西。移动智能终端用 户通常觉得 iOS 的系统比 Android 系统有更好的用户体验,其中一个深层次的原因就在于 Android 系统中垃圾回收的不可预知性。

补充:垃圾回收机制有很多种,包括:分代复制垃圾回收、标记垃圾回收、增量垃圾回收等方 式。标准的 Java 进程既有栈又有堆。栈保存了原始型局部变量,堆保存了要创建的对象。Java 平台对堆内存回收和再利用的基本算法被称为标记和清除,但是 Java 对其进行了改进,采用“分 代式垃圾收集”。这种方法会跟 Java 对象的生命周期将堆内存划分为不同的区域,在垃圾收集过 程中,可能会将对象移动到不同区域:

– 伊甸园(Eden):这是对象最初诞生的区域,并且对大多数对象来说,这里是它们唯一存在

过的区域。

– 幸存者乐园(Survivor):从伊甸园幸存下来的对象会被挪到这里。

– 终身颐养园(Tenured):这是足够老的幸存对象的归宿。年轻代收集(Minor-GC)过程是不 会触及这个地方的。当年轻代收集不能把对象放进终身颐养园时,就会触发一次完全收集 (Major-GC),这里可能还会牵扯到压缩,以便为大对象腾出足够的空间。

与垃圾回收相关的 JVM 参数:

  • -Xms / -Xmx — 堆的初始大小 / 堆的最大大小

  • -Xmn — 堆中年轻代的大小

  • -XX:-DisableExplicitGC — 让 System.gc()不产生任何作用

  • -XX:+PrintGCDetails — 打印 GC 的细节

  • -XX:+PrintGCDateStamps — 打印 GC 操作的时间戳

  • -XX:NewSize / XX:MaxNewSize — 设置新生代大小/新生代最大大小

  • -XX:NewRatio — 可以设置老生代和新生代的比例

  • -XX:PrintTenuringDistribution — 设置每次新生代 GC 后输出幸存者乐园中对象年龄的分

  • -XX:InitialTenuringThreshold / -XX:MaxTenuringThreshold:设置老年代阀值的初始值和最

    大值

  • -XX:TargetSurvivorRatio:设置幸存区的目标使用率

(3)题外话,谈到jvm的运行机制,那么java到底是编译性型语言还是解释型语言呢?

我查过很多资料,说什么的都有,有人说是解释型语言,有人为了把java 跟js做对比说它是编译性语言。

最近我看了一篇博客

https://blog.csdn.net/gaosure/article/details/58252393

写的我觉得博主写的挺好。

首先,我们先看看这两种语言类型的介绍:

计算机高级语言类型主要有编译型和解释型两种:

编译型语言:在程序运行之前,有一个单独的编译过程,将程序翻译成机器语言,以后执行这个程序时,就不用再进行翻译了。

解释型语言:是在运行的时候将程序翻译成机器语言,所以运行速度相对于编译型语言要慢。

二者之间最大的区别就在于是否存下目标机器码:编译会把输入的源程序以某种单位(例如基本块/函数/方法/trace等)翻译生成目标机器码,并存下来(无论是在磁盘上或是内存中)后续执行可以复用;解释则是把源程序中的指令逐条解释执行,边解释边执行,不存下目标代码,后续执行没有可以复用的信息。

了解Java的运行过程:Java源文件(*.java),通过java编译器(javac)编译生成一个ByteCode字节码文件(*.class),字节码由java自己设计的一个计算机(即java虚拟机,JVM)解释执行,虚拟机将每一条要执行的字节码送给解释器,解释器将其翻译成特定机器上的目标机器码,然后在特定的机器上运行。

虽然Java的第一道工序是javac编译,其目标文件是ByteCode,而并非机器语言,但后续可能有三种处理方式(在这,目前对这三种处理方式不做评价,需要对jvm知识深入探讨后,再做验证):

1、运行时,ByteCode由JVM逐条送给解释器,解释器将翻译成机器码运行。(很多人说的是解释型语言也是以此为出发点的)

2、运行时,部分ByteCode可能由实时编译器(Just In Time Compiler,JIT)编译为目标机器码再执行(以method为翻译单位,还会保存起来,第二次执行就不用再翻译为机器码了),因为考虑到有些JVM是采用纯JIT编译方式实现的,其内部没有解释器,例如:JRockit、Maxine VM。

3、RTSJ,继javac之后执行AOT二次编译,生成静态的目标平台码。

有的时候,可能是以上三种方式同时在使用,至少,1和2是同时使用的,3则需要程序员手工指定。

对此,本人比较愿意接受的java是编译与解释两者之间的混合式语言。



版权声明:本文为Myuhua原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。