JVM是Java Virtual Machine(Java虚拟机)的缩写,JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
Java不仅是简简单单的计算机语言,它更是一个平台、一种文化、一个社区。
-
作为一个平台,Java虚拟机扮演着举足轻重的作用。
Groovy、Scala、 JRuby、Kotlin等都是Java平台的一部分 -
作为一种文化,Java几乎成为了“开源”的代名词。
第三方开源软件和框架。如Tomcat、Struts、MyBatis、Spring等。
就连JDK和JVM自身也有不少开源的实现,如OpenJDK、Harmony -
作为一个社区,Java拥有全世界最多的技术拥护者和开源社区支持,有数不清的论坛和资料。从桌面应用软件、嵌入式开发到企业级应用、后台服务器中间件,都可以看到Java的身影。其应用形式之复杂、参与人数之众多也令人咋舌。
作用:
Java虚拟机就是二进制字节码的运行环境,负责装载字节码到其内部,解释/编译为对应平台上的机器指令执行。每一条Java指令,Java虚拟机规范中都有详细定义,如怎么取 *** 作数,怎么处理 *** 作数,处理结果放在哪里。
- 一次编译,到处运行
- 自动内存管理
- 自动垃圾回收功能
注意:是Java具有跨平台性,JVM没有。
Java是跨平台的语言,JVM是跨语言的平台。
Java虚拟机根本不关心运行在其内部的程序到底是使用何种编程语言编写的,它只关心“字节码”文件。也就是说Java虚拟机拥有语言无关性,并不会单纯地与Java语言“终身绑定”,只要其他编程语言的编译结果满足并包含Java虚拟机的内部指令集、符号表以及其他的辅助信息,它就是一个有效的字节码文件,就能够被虚拟机所识别并装载运行。
我们平常说的java字节码,指的是用java语言编译成的字节码。准确的说任何能在jvm平台上执行的字节码格式都是一样的。所以应该统称为jvm字节码。
1.3 JVM的位置
- HotSpot VM是目前市面上高性能虚拟机的代表作之一。
- 它采用解释器与即时编译器JIT并存的架构。
- 在今天,Java程序的运行性能早己脱胎换骨,已经达到了可以和c/c++程序一较高下的地步。
我们的class字节码文件,被类加载子系统加载到内存中,生成一个大的Class对象。在运行时分为几个区,其中方法区和堆是多个线程共享的,其它是线程独有的。
1.5 Java代码的执行流程和JVM的架构模型
翻译字节码(解释执行)是保证响应时间,负责逐行对字节码进行解释执行。
JIT编译器针对字节码指令中反复执行的,这些被称为热点代码,热点代码使用JIT编译成机器指令,同时把这些机器指令缓存起来,增加性能。
JVM的整体架构:
Java编译器输入的指令流基本上是一种基于栈的指令集架构,另外一种指令集架构则是基于寄存器的指令集架构。
基于栈式架构的特点:
-
设计和实现更简单,适用于资源受限的系统;
-
避开了寄存器的分配难题:使用零地址指令方式分配。
-
指令流中的指令大部分是零地址指令,其执行过程依赖于 *** 作栈。指令集更小,编译器容易实现。
-
不需要硬件支持,可移植性更好,更好实现跨平台
基于寄存器架构的特点:
- 典型的应用是x86的二进制指令集:比如传统的PC以及Android的Davlik虚拟机。
- 指令集架构则完全依赖硬件,可移植性差
- 性能优秀和执行更高效;
- 花费更少的指令去完成一项 *** 作。
- 在大部分情况下,基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主,而基于栈式架构的指令集却是以零地址指令为主。
HotSpot就是一个基于栈的指令集架构
总结:
由于跨平台性的设计,Java的指令都是根据栈来设计的。不同平台CPU架构不同,所以不能设计为基于寄存器的。优点是跨平台,指令集小,编译器容易实现,缺点是性能下降,实现同样的功能需要更多的指令。
-
虚拟机的启动
Java虚拟机的启动是通过引导类加载器(bootstrap class loader)创建一个初始类(initial class)来完成的,这个类是由虚拟机的具体实现指定的。 -
虚拟机的执行
一个运行中的Java虚拟机有着一个清晰的任务:执行Java程序。
程序开始执行时他才运行,程序结束时他就停止。
执行一个所谓的Java程序的时候,真真正正在执行的是一个叫做Java虚拟机的进程。 -
虚拟机的退出
有如下的几种情况:
①程序正常执行结束
②程序在执行过程中遇到了异常或错误而异常终止
③由于 *** 作系统出现错误而导致Java虚拟机进程终止
④某线程调用Runtime类或System类的exit方法,或 Runtime类的halt方法,并且Java安全管理器也允许这次exit或halt *** 作。
⑤除此之外,JNI ( Java Native Interface)规范描述了用JNI Invocation API来加载或卸载Java虚拟机时,Java虚拟机的退出情况。
class文件,俗称字节码文件,由类加载器将字节码文件加载进内存,然后由执行引擎去执行字节码指令。
详图:
中文版:
字节码文件经过类加载子系统,经过加载、链接、初始化,加载会使用几个类的加载器,加载进内存。虚拟机栈和程序计数器每个线程一份,方法区和堆是线程共享的。本地方法栈是调用本地方法的接口。方法区存放的是一些类的信息,常量,方法信息等等,方法区只有hotspot才有。
- 类加载器子系统负责从文件系统或者网络中加载class文件,class文件在文件开头有特定的文件标识。
- ClassLoader只负责class文件的加载,至于它是否可以运行,则由Execution Engine决定。
- 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外,方法区中还会存放运行时常量池信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)
下面举一个“栗子”:
- Car.class存在于本地硬盘上,可以理解为设计师画在纸上的模板,而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
- Car.class通过ClassLoader加载并初始化到内存JVM中,被称为DNA元数据模板,就是上图中的Car Class,放在方法区。
- 通过Car Class的getClassLoader()方法可以获取加载此类的类加载器。
- 我们可以在内存中调用Car Class的构造器,去创建该类的对象car1、car2、car3。通过具体的一个对象,调用getClass()方法可以获取该对象是由哪个类所创建的。
- 在.class文件-> JVM->最终成为元数据模板,此过程就要一个运输工具(类装载器Class Loader),扮演一个快递员的角色。
大致的加载过程:
public class HelloLoader { public static void main(String[] args) { System.out.println("谢谢ClassLoader加载我...."); System.out.println("你的大恩大德,我下辈子再报!"); } }
要运行上面的代码,首先检查当前HelloLoader类有没有加载,如果没有加载,则会去使用对应的类加载器进行装载,如果加载的不是一个合法的字节码文件,则会抛出异常。加载成功的话,则会在内存中存在一个大的Class对象。
2.2.1 类的加载过程一:Loading加载:
1.通过一个类的全限定名获取定义此类的二进制字节流
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3.在内存中生成一个代表这个类的java.lang.class对象,作为方法区这个类的各种数据的访问入口
加载.class文件的方式
- 从本地系统中直接加载
- 通过网络获取,典型场景: web Applet
- 从zip压缩包中读取,成为日后jar、war格式的基础
- 运行时计算生成,使用最多的是:动态代理技术
- 由其他文件生成,典型场景:JSP应用
- 从专有数据库中提取.class文件,比较少见
- 从加密文件中获取,典型的防class文件被反编译的保护措施
经过Loading阶段后,已经在内存中可以生成一个大的Class实例了。
链接阶段主要包含三部分:
①验证(Verify):目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性,不会危害虚拟机自身安全。主要包含四种验证:文件格式验证、元数据验证、字节码验证、符号引用验证。
②准备(Prepare):为类变量分配内存并且设置该类变量的默认初始值,即零值。这里不包含被final修饰的static常量,因为final在编译的时候就会分配了,准备阶段会显式。这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是随着对象一起分配到Java堆中。
③解析(Resolve):将常量池内的符号引用转换为直接引用的过程。事实上,解析 *** 作往往会伴随着JVM在执行完初始化后再执行。符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或者一个间接定位到目标的句柄。解析动作主要针对类或者接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。
2.2.2 类的加载过程三:Initialization- 初始化阶段就是执行类构造器方法
()的过程。 - 此方法不需定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。如果没有类变量这些,JVM则不会生成这样的方法。
- 构造器方法中指令按语句在源文件中出现的顺序执行。
()不同于类的构造器。(关联:构造器是虚拟机视角下的 (),) - 若该类具有父类,JVM会保证子类的
()执行前,父类的 ()已经执行完毕。 - 虚拟机必须保证一个类的
()方法在多线程下被同步加锁。
public class ClassTest { static{ num = 20; } private static int num = 10; public static void main(String[] args) { System.out.println(num);// 10 } }
num在num定义之前可以赋值,是因为num在linking阶段的Prepare已经加载进内存并且赋值为0,然后在static代码块中赋值为20,然后在赋值为10.
public class DeadThreadTest { public static void main(String[] args) { Runnable r = () -> { System.out.println(Thread.currentThread().getName() + "开始"); DeadThread dead = new DeadThread(); System.out.println(Thread.currentThread().getName() + "结束"); }; Thread t1 = new Thread(r,"线程1"); Thread t2 = new Thread(r,"线程2"); t1.start(); t2.start(); } } class DeadThread{ static{ if(true){ System.out.println(Thread.currentThread().getName() + "初始化当前类"); while(true){ } } } }
一个类只会被加载一次。
2.3 类加载器分类- JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器User-Defined ClassLoader)
- 从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。也就是说,我们只分为引导类加载器和其他的类加载器,扩展类加载器和系统类加载器都是自定义类加载器。
- 无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个,如下所示:
Bootstrap Class Loader是C/C++写的,其他是Java代码写的。
查看源码:Launcher.class
public class Launcher { static class ExtClassLoader extends URLClassLoader { private static volatile Launcher.ExtClassLoader instance; public static Launcher.ExtClassLoader getExtClassLoader() throws IOException { if (instance == null) { Class var0 = Launcher.ExtClassLoader.class; synchronized(Launcher.ExtClassLoader.class) { if (instance == null) { instance = createExtClassLoader(); } } } return instance; } } }
可以看到,Launcher有几个静态内部类。
public class ClassLoaderTest { public static void main(String[] args) { // 获取系统类加载器 ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader(); System.out.println(systemClassLoader); // sun.misc.Launcher$AppClassLoader@18b4aac2 // 获取其上层:扩展类加载器 ClassLoader extClassLoader = systemClassLoader.getParent(); System.out.println(extClassLoader);// sun.misc.Launcher$ExtClassLoader@677327b6 // 获取其上层:引导类加载器 ClassLoader bootstrapClassLoader = extClassLoader.getParent(); System.out.println(bootstrapClassLoader); // null // 查看对于用户自定义类的加载器:默认使用系统类加载器 ClassLoader classLoader = ClassLoaderTest.class.getClassLoader(); System.out.println(classLoader); // sun.misc.Launcher$AppClassLoader@18b4aac2 // String类的加载器:引导类加载器 ---> Java的核心类库都是使用引导类加载器进行加载的 ClassLoader stringClassLoader = String.class.getClassLoader(); System.out.println(stringClassLoader); // null } }2.3.1 启动类加载器
- 虚拟机自带的加载器
- 启动类加载器(引导类加载器,Bootstrap ClassLoader)
- 这个类加载使用C/C++语言实现的,嵌套在JVM内部。
- 它用来加载Java的核心库(JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类
- 并不继承自java.lang.classLoader,没有父加载器。加载扩展类和应用程序类加载器,并指定为他们的父类加载器。
- 出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
System.out.println("**********启动类加载器**************"); //获取BootstrapClassLoader能够加载的api的路径 URL[] urLs = sun.misc.Launcher.getBootstrapClassPath().getURLs(); for (URL element : urLs) { System.out.println(element.toExternalForm()); } //从上面的路径中随意选择一个类,来看看他的类加载器是什么:引导类加载器 ClassLoader classLoader = Provider.class.getClassLoader(); System.out.println(classLoader); // null2.3.2 扩展类加载器
- 虚拟机自带的加载器
- 扩展类加载器(Extension ClassLoader)
- Java语言编写,由sun.misc.Launcher$ExtClassLoader实现。
- 派生于ClassLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
System.out.println("***********扩展类加载器*************"); String extDirs = System.getProperty("java.ext.dirs"); for (String path : extDirs.split(";")) { System.out.println(path); } //从上面的路径中随意选择一个类,来看看他的类加载器是什么:扩展类加载器 ClassLoader classLoader1 = CurveDB.class.getClassLoader(); System.out.println(classLoader1);//sun.misc.Launcher$ExtClassLoader@1540e19d2.3.3 应用程序类加载器(系统类加载器)
- 虚拟机自带的加载器
- 应用程序类加载器(系统类加载器,AppclassLoader)
- java语言编写,由sun.misc.Launcher$AppclassLoader实现
- 派生于classLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
- 通过classLoader#getSystemclassLoader ()方法可以获取到该类加载器
在Java的日常应用程序开发中,类的加载几乎是由上述3种类加载器相互配合执行的,在必要时,我们还可以自定义类加载器,来定制类的加载方式。
那么为什么要自定义类加载器?
①隔离加载类
②修改类加载的方式
③扩展加载源
④防止源码泄漏
用户自定义类加载器实现步骤:
1.开发人员可以通过继承抽象类java.lang.ClassLoader类的方式,实现自己的类加载器,以满足一些特殊的需求
2.在JDK1.2之前,在自定义类加载器时,总会去继承ClassLoader类并重写loadClass ()方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadclass()方法,而是建议把自定义的类加载逻辑写在findclass ()方法中。
3.在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findclass ()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
ClassLoader类,它是一个抽象类,其后所有的类加载器都继承自ClassLoader(不包括启动类加载器)
继承关系
sun.misc.Launcher它是一个java虚拟机的入口应用。
获取ClassLoader的途径:
方式一:获取当前类的ClassLoader:clazz.getClassLoader()
方式二:获取当前线程上下文的ClassLoader:Thread.currentThread().getContextLoader()
方式二:获取系统的ClassLoader:ClassLoader.getSystemClassLoader
方式四:获取调用者的ClassLoader:DriverManager.getCallerClassLoader()
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)