「java类加载机制」java类加载机制有哪些

本篇文章给大家谈谈java类加载机制，以及java类加载机制有哪些对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、VM 加载class文件的原理是什么?
• 2、java中反射实例类装载的步骤及简要阐述
• 3、java动态类加载机制有什么缺点
• 4、Android类加载机制
• 5、不容忽视的ClassNotFoundException
• 6、java 类加载机制有什么用

VM 加载class文件的原理是什么?

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

Java类加载器基于三个机制：委托、可见性和单一性。

（1）委托机制是指加载一个类的请求交给父类加载器，如果这个父类加载器不能够找到或加载这个类，那么再加载它。

（2）可见性的原理是子类的加载器可以看见所有的父类加载器加载的类，而父类加载器看不到子类加载器加载的类。

（3）单一性原理是指一个类仅被加载一次，这是由委托机制确保子类加载器不会再次加载父类加载器加载过的类。

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

（1）系统类

（2）扩展类

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

3. 类装载有两种方式

（1）隐式装载：

程序在运行过程中当碰到通过new等方式生成类或者子类对象、使用类或者子类的静态域时，隐式调用类加载器加载对应的的类到JVM中。

（2）显式装载：

通过调用Class.forName()或者ClassLoader.loadClass(className)等方法，显式加载需要的类。

4. 类加载的动态性体现

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

5. Java类加载器

Java中的类加载器实质上也是也是类，功能是把类加载入JVM中，值得注意的是JVM的类加载器有三个，原因有：一方面是为了分工明确，各自负责各自的区块，另一方面为了实现委托模型。

层次结构如下：

BootStrap Loader（引导类加载器） ----- 负责加载系统类

ExtClassLoader（扩展类加载器） ----- 负责加载扩展类

AppClassLoade（应用类加载器）r ----- 负责加载应用类

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

Java中有三个类加载器，碰到一个类需要加载时，Java采用委托模型机制来协调和区分该由哪个类加载器完成。简单来说就是，“类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入”，如果Parent找不到，那么才由自己依照自己的搜索路径搜索类。

java中反射实例类装载的步骤及简要阐述

java反射和类装载

反射机制：

Person p=new Person();

这是什么?当然是实例化一个对象了.可是这种实例化对象的方法存在一个问题,那就是必须要知道类名才可以实例化它的对象,这样我们在应用方面就会受到限制.那么有没有这样一种方式,让我们不知道这个类的类名就可以实例化它的对象呢?Thank Goodness!幸亏我们用的是java, java就提供了这样的机制.

1).java程序在运行时可以获得任何一个类的字节码信息,包括类的修饰符(public,static等),基类(超类,父类),实现的接口,字段和方法等信息.

2).java程序在运行时可以根据字节码信息来创建该类的实例对象,改变对象的字段内容和调用对象方法.

这样的机制就叫反射技术.可以想象光学中的反射,就像我们照镜子,镜子中又出现一个自己(比喻可能不太恰当,但是足以表达清楚意思了).反射技术提供了一种通用的动态连接程序组件的方法,不必要把程序所需要的目标类硬编码到源程序中,从而使得我们可以创建灵活的程序.

反射的实现步骤（ 不问不需要答) ，

1、获取类的常用方式有三种： a) Class.forName("包名.类名")，最常用、推荐；b) 包名.类名.class 最简捷；c) 对象.getClass 的方式获得。

2、对象的实例化,上面已经获取了类，只需要调用类的实例化方法,类.newInstance()便可。

3、获取属性和构造等，可以参考 JavaApi 的调用，类. getDeclaredFields,类. getConstructor(..)等。

Java的反射机制是通过反射API来实现的,它允许程序在运行过程中取得任何一个已知名称的类的内部信息.反射API位于java.lang.reflect包中.主要包括以下几类:

1).Constructor类:用来描述一个类的构造方法

2).Field类:用来描述一个类的成员变量

3).Method类:用来描述一个类的方法.

4).Modifer类:用来描述类内各元素的修饰符

5).Array:用来对数组进行操作.

Constructor,Field,Method这三个类都是JVM(虚拟机)在程序运行时创建的,用来表示加载类中相应的成员.这三个类都实现了java.lang.reflect.Member接口,Member接口定义了获取类成员或构造方法等信息的方法.要使用这些反射API,必须先得到要操作的对象或类的Class类的实例.通过调用Class类的newInstance方法(只能调用类的默认构造方法)可以创建类的实例.这样有局限性,我们可以先冲类的Class实例获取类需要的构造方法,然后在利用反射来创建类的一个实例.

类加载机制：



类的加载机制可以分为加载-链接-初始化三个阶段，链接又可以分为验证、准备、解析三个过程。

加载：通过类的加载器查找并加载二进制字节流的过程，在堆内存中的方法区生成 一个代表这个类的 java.lang.Class 对象，作为这个类的数据请求入口。（这里可以把上面类加载器加载文件的过程描述一下（参考版本一，不作重复））。

验证：主要是对一些词法、语法进行规范性校验，避免对 JVM 本身安全造成危害； 比如对文件格式，字节码验证，无数据验证等。但验证阶段是非必须的，可以通过参数 设置来进行关闭，以提高加载的时效。

准备：对类变量分配内存，并且对类变量预初始化，初始化成数据类型的原始值， 比如 static int a=11,会被初始化成成 a=0;如果是 static double a =11,则会被初始化成 a=0.0； 而成员变量只会成实例化后的堆中初始化。

解析：把常量池中的符号引用转换为直接引用的过程。

初始化：对类的静态变量和静态块中的变量进行初始化。（上面的准备阶段可以作为 预初始化，初始到变量类型的原值，但如果被 final 修饰会进行真正初始化）

上面加载、链接、初始化的各个阶段并不是彼此独立，而是交叉进行，这点很重要 。

***class.forName和 classloader的区别

Class.forName 和 ClassLoader 都是用来装载类的，对于类的装载一般为分三个阶段加载、链接、编译，它们装载类的方式是有区别。

首先看一下 Class.forName（..），forName（..）方法有一个重载方法 forName(className,boolean,ClassLoader)，它有三个参数，第一个参数是类的包路径，第二个参数是 boolean

类型，为 true 地表示 Loading 时会进行初始化，第三个就是指定一个加载器；当你调用class.forName(..)时，默认调用的是有三个参数的重载方法，第二个参数默认传入 true,第三个参数默认使用的是当前类加载时用的加载器。

ClassLoader.loadClass()也有一个重载方法，从源码中可以看出它默认调的是它的重载 方法 loadClass(name, false)，当第二参数为 false 时，说明类加载时不会被链接。这也是两者之间最大区别，前者在加载的时候已经初始化，后者在加载的时候还没有链接。如果你需要在加载时初始化一些东西，就要用 Class.forName 了，比如我们常用的驱动加载， 实际上它的注册动作就是在加载时的一个静态块中完成的。所以它不能被 ClassLoader 加载代替。

java动态类加载机制有什么缺点

动态类加载主要是通过反射将类对象注入进去, 优点一大堆, 很多框架底层都有用到。

缺点：没有直接掉用直观方便。有些动态注入, 类型错误只有运行时才能发现。

Android类加载机制

Android手写热修复（一）--ClassLoader

我们平时编写的 .java 文件不是可执行文件，需要先编译成 .class 文件才可以被虚拟机执行。所谓类加载是指通过 类加载器 把class文件加载到虚拟机的内存空间，具体来说是方法区。类通常是按需加载，即第一次使用该类时才加载。

首先，Java与Android都是把类加载到虚拟机内存中，然后由虚拟机转换成设备识别的机器码。但是由于二者使用的虚拟机不同，所以在类加载方面也是有所区别的。Java的虚拟机是JVM，Android的虚拟机是dalvik／art(5.0以后虚拟机是art，是对dalvik的一种升级)。 Java虚拟机运行的是class文件，而Android 虚拟机运行的是dex文件。 dex其实是class文件的集合，是对class文件优化的产物，是为了避免出现重复的class。

从上面的讲解中，我们已经知道我们平时写的类是被 类加载器 加载尽虚拟机内存才能运行。下面就通过Framework源码来为大家讲解Android中最主要的5个类加载器。

在Activity做个简单验证：

结果：

可以看出系统类由BootClassLoader加载，apk中的类由PathClassLoader加载，PathClassLoader的父类加载器是BootClassLoader。如果暂时不能理解父类加载器是什么，没关系，后面讲双亲委托机制的时候会理解的。

下面的源码解析基于 Android SDK API28 ，这几个类加载器（除了ClassLoader）没办法直接在AS上查看源码，AS搜索到的是反编译的class的内容，是不可信的，为大家推荐一个在线工具查看， 在线查看Android Framework源码 。

用来加载本地文件系统上的文件或目录，通常是用来加载apk中我们自己写的类，而像 Activity.class 这种系统的类不是由它加载。注意：这里，并不像很多网上文章说的那样只能加载apk，本地的其他目录的文件也是可以的，这一点我会在后面验证说明。

也是被用来加载 jar 、apk、dex，通常用来加载未安装到应用中的文件。注意，它需要一个应用私有的可写的目录来存放优化后的dex文件。千万不要选择外部存储路径，因为这样可能会导致你的应用遭到注入攻击。

关于dex文件优化，可能很多人还是不理解，水平有限，我简单解释一下，

构造器参数解释：

关于optimizedDirectory：

1、这是dex优化后的路径，它必须是一个应用私有的可写的目录否则会存在注入攻击的风险；

2、这个参数在API 26（8.0）之前是有值的，之后的话，这个参数已经没有影响了，因为在调用父构造器的时候这个参数始终为null，也就是说Android 8.0 以后DexClassLoader和PathClassLoader基本一样的来；

3、在加载app的时候，apk内部的dex已经执行过优化了，优化之后放在系统目录/data/dalvik-cache下。

这个构造器的关键是初始化了一个DexPathList对象，这个是后面加载class的关键类。

这个构造方法等关键是通过 makeDexElements() 方法来获取Element数组，这个Element数组非常关键，后面查找class就会用到它，也是热修复的关键点之一。

splitDexPath(dexPath) 方法是把dexPath目录下的所有文件转换成一个File集合，如果是多个文件的话，会用 : 作为分隔符。

makeDexElements()

小结一下，这个方法就是把指定目录下的文件apk／jar／zip／dex按不同的方式封装成Element对象，然后按顺序添加到Element[]数组中。

DexPathList#loadDexFile()

可以看到 DexFile 最终是调用了openDexFile、native方法openDexFileNative去打开Dex文件的，如果outputName为空，则自动生成一个缓存目录，具体来说是 /data/dalvik-cache/xxx@classes.dex 。openDexFileNative这个native方法就不具体分析了，主要是对dex文件进行了优化操作，将优化后得odex文件通过mmap映射到内存中。感兴趣的同学可以参考：

《DexClassLoader和PathClassLoader加载Dex流程》

现在在回头看看DexClassLoader与PathClassLoader的区别。DexClassLoader可以指定odex的路径，而PathClassLoader则采用系统默认的缓存路径，在8.0以后没有区别。

ClassLoader是一个抽象类，有3个构造方法，最终调用的还是第一个构造方法，主要功能是保存实现类传入的parent参数，也就是父类加载器。ClassLoader的实现类主要有2个，一个是前面讲过的BaseDexClassLoader，另一个是BootClassLoader。

BootClassLoader是ClassLoader的内部类，而且继承了ClassLoader。

这是加载一个类的入口，流程如下：

1、 先检查这个类是否已经被加载，有的话直接返回Class对象；

2、如果没有加载过，通过父类加载器去加载，可以看出parent是通过递归的方式去加载class的；

3、如果所有的父类加载器都没有加载过，就由当前的类加载器去加载。

通常我们自己写的类是通过当前类加载器调用 findClass 方法去加载的，但是在 ClassLoader 中这是个空方法，具体的实现在它的子类 BaseDexClassLoader 中。

BaseDexClassLoader # findClass

可以看到是通过pathList去查找class的，这个对象其实之前讲过，它是在BaseDexClassLoader 的构造方法中初始化的，它实际上是一个 DexPathList 对象。

DexPathList # findClass()

对Element数组遍历，再通过Element对象的 findClass 方法去查找class，有的话就直接返回这个class，找不到则返回null。 这里可以看出获取Class是通过DexFile来实现的，而各种类加载器操作的是Dex。Android虚拟机加载的dex文件，而不是class文件。

1、加载一个类是通过双亲委托机制来实现的。

2、如果是第一次加载class，那是通过 BaseDexClassLoader 中的findClass方法实现的；接着进入 DexPathList 中的findClass方法，内部通过遍历Element数组，从Element对象中去查找类；Element实际上是对Dex文件的包装，最终还是从dexfile去查找的class。

3、一般app运行主要用到2个类加载器，一个是PathClassLoader：主要用于加载自己写的类；另一个是BootClassLoader：用于加载Framework中的类；

4、热修复和插件化一般是利用DexClassLoader来实现。

5、PathClassLoader和DexClassLoader其实都可以加载apk／jar／dex，区别是 DexClassLoader 可以指定 optimizedDirectory ，也就是 dex2oat 的产物 .odex 存放的位置，而 PathClassLoader 只能使用系统默认位置。但是在8.0 以后二者是没有区别的，只能使用系统默认的位置了。

这张图来源于：

Android虚拟机框架：类加载机制

在类加载流程分析中，我们已经知道，查找class是通过DexPathList来完成的，实际上DexPathList最终还是遍历其Element数组，获取DexFile对象来加载Class文件。 由于数组是有序的，如果2个dex文件中存在相同类名的class，那么类加载器就只会加载数组前面的dex中的class。如果apk中出现了有bug的class，那只要把修复的class打包成dex文件并且放在 DexPathList 中Element数组`的前面，就可以实现bug修复了 。下一篇为大家带来的手写热修复。

Android类加载机制的细枝末节

从JVM到Dalivk再到ART（class,dex,odex,vdex,ELF）

类加载机制系列2——深入理解Android中的类加载器

Android 热修复核心原理，ClassLoader类加载

不容忽视的ClassNotFoundException

相信很多Java开发人员都对这个常见却不招人待见的java.lang.ClassNotFoundException并不陌生。出现这个异常的原因大家都清楚（classpath路径下缺少class文件或者jar包了，或者是类加载器委派的问题等），不过对于它给JVM带来的性能影响可能就不了解了。这个异常可能会严重影响应用程序的响应时间和可伸缩性。

大型的J2EE企业级应用，可能会同时部署有多个应用，由于同时运行着多个类加载器，就很容易导致这类问题。除非发现有业务确实受到影响或者日志监控比较详细，否则很有可能出现了ClassNotFoundException你也不知道，这导致的结果是：JVM类加载的IO开销和线程间的锁竞争给系统带来的性能问题。

本文及文中的示例程序将会告诉你，应当谨慎对待生产系统中出现的ClassNotFoundException异常，并正确的解决它。

想要正确理解这个性能问题，首先你得明白Java类加载模型的机制。ClassNotFoundException意味着JVM无法找到或者加载某个Java类：

Class.forName()方法

ClassLoader.findSysteClass()方法

ClassLoader.loadClass()方法

尽管在JVM的生命周期内，你的应用程序里面的Java类应该只会加载一次，但有些应用可能会依赖于动态的类加载机制。

不管怎么说，不停地加载失败总是很影响性能的，尤其是JDK中默认的java.lang.ClassLoader进行加载的时候。事实上，1.7以上版本的JDK，为了向下兼容，同一个类不能同时被加载，除非这个类加载器被标记为“支持并发”的。你要时刻牢记，同步操作是在类这一级实现的，由于多个Java线程并发地加载，同一个类不停的加载失败会引发线程间的锁竞争。如果是JDK1.6以前则情况更糟糕，因为同步操作是在类加载器这一层完成的。

由于这个原因，像JBoss WildFly8等JavaEE容器都使用了它们内部的并发类加载器来完成应用程序的类加载。这些类加载器都在更细粒度上进行加锁，这样同一个类加载器的实例可以同时加载多个不同的类。这和JDK1.7的优化不谋而和，它支持的并发的自定义类加载器也是防止类加载器出现死锁的现象。

不过，像java.*的系统级别的类，它们的加载还是会由JDK默认的类加载器来完成。这意味着连续的类加载失败还是可能会引发严重的线程锁竞争。这也正是本文接下来要重现并演示的场景。

为了重现并模拟这个问题，我们按照以下的规范写了一个简单的程序：

一个JAX-RS WEB服务执行Class.forName()来加载一个系统包下不存在的类：

JRE: HotSpot JDK 1.7 64位

Java EE容器：JBoss WildFly8

压测工具：Apache JMeter

Java监控工具：JVisualVM

Java故障分析：JVM Thread Dump

JAX-RS服务同时有20个线程在并发的执行。每一次调用都会触发一个ClassNotFoundException。为了减少IO的影响，日志也完全关闭了，我们只关注类加载的竞争冲突。

现在我们来看下JVisualVM在半分钟到一分钟内的监测结果。可以很明显的看到，很多线程都阻塞住了，在等待获取一个对象锁。

分析JVM的threaddump很容易就能定位出问题：线程锁竞争。从运行栈的跟踪信息可以看到，JBoss把类加载的任务委派给了JDK的类加载器。为什么？这是因为这个不存在的java类被认为是属于系统类路径底下，因此JBoss会把它的加载委派给系统的类加载器。这样因为这个类触发了系统级的同步，其它线程只能等待获取锁才能加载它。

很多线程都在等待获取0x00000000ab84c0c8的锁：

这个线程是罪魁祸首——default task 20

现在我们把要加载类的名字更换到应用程序的包下面并重新运行这段程序。

可以看到，不再有阻塞的线程出现了。为什么？我们来看下JVM的thread dump来更好的理解下为什么会出现这个变化。

由于类名不再认为属于Java系统包下，不会发生类加载委派，也就没有同步操作。

由于JBoss认为JDK1.7是一个”安全“的JDK，它会使用ConcurrentClassLoader.performLoadClassUnchecked()方法，也就不会触发对象监视器锁。

没有同步也就不会产生线程锁竞争，也就不会出现没完没了的ClassNotFoundException异常。

值得注意的是JBoss在防止线程锁竞争方面做出了很大的改进，不过重复的类加载的尝试仍然会在一定程度上影响应用的性能，因为搜索JAR包查找Java类会有一定的IO开销，因此也仍需要采取正确的手段进行处理。

希望你能喜欢这篇文章并且对类加载可能会带来的性能影响也有了更好的了解。JDK1.7和现代的Java EE容器都在类加载方面做了很多的优化，比如死锁和锁竞争方面，但是还是会存在潜在的问题。因此，我强烈建议你能密切的关注你的应用程序的表现，记录日志并确保类加载相关的异常比如java.lang.ClassNotFoundException和java.lang.NoClassDefFoundError都能够正确的处理。

java 类加载机制有什么用

AVA类加载机制详解

“代码编译的结果从本地机器码转变为字节码，是存储格式发展的一小步，却是变成语言发展的一大步”，这句话出自《深入理解JAVA虚拟机》一书，后面关于jvm的系列文章主要都是参考这本书。

JAVA源码编译由三个过程组成：

1、源码编译机制。

2、类加载机制

3、类执行机制

我们这里主要介绍编译和类加载这两种机制。

一、源码编译

代码编译由JAVA源码编译器来完成。主要是将源码编译成字节码文件（class文件）。字节码文件格式主要分为两部分：常量池和方法字节码。

二、类加载

类的生命周期是从被加载到虚拟机内存中开始，到卸载出内存结束。过程共有七个阶段，其中到初始化之前的都是属于类加载的部分

加载----验证----准备----解析-----初始化----使用-----卸载

系统可能在第一次使用某个类时加载该类，也可能采用预加载机制来加载某个类，当运行某个java程序时，会启动一个java虚拟机进程，两次运行的java程序处于两个不同的JVM进程中，两个jvm之间并不会共享数据。

1、加载阶段

这个流程中的加载是类加载机制中的一个阶段，这两个概念不要混淆，这个阶段需要完成的事情有：

1）通过一个类的全限定名来获取定义此类的二进制字节流。

2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3）在java堆中生成一个代表这个类的Class对象，作为访问方法区中这些数据的入口。

由于第一点没有指明从哪里获取以及怎样获取类的二进制字节流，所以这一块区域留给我开发者很大的发挥空间。这个我在后面的类加载器中在进行介绍。

2、准备阶段

这个阶段正式为类变量（被static修饰的变量）分配内存并设置类变量初始值，这个内存分配是发生在方法区中。

1、注意这里并没有对实例变量进行内存分配，实例变量将会在对象实例化时随着对象一起分配在JAVA堆中。

2、这里设置的初始值，通常是指数据类型的零值。

private static int a = 3;

这个类变量a在准备阶段后的值是0，将3赋值给变量a是发生在初始化阶段。

3、初始化阶段

初始化是类加载机制的最后一步，这个时候才正真开始执行类中定义的JAVA程序代码。在前面准备阶段，类变量已经赋过一次系统要求的初始值，在初始化阶段最重要的事情就是对类变量进行初始化，关注的重点是父子类之间各类资源初始化的顺序。

java类中对类变量指定初始值有两种方式：1、声明类变量时指定初始值；2、使用静态初始化块为类变量指定初始值。

初始化的时机

1）创建类实例的时候，分别有：1、使用new关键字创建实例；2、通过反射创建实例；3、通过反序列化方式创建实例。

new Test();

Class.forName(“com.mengdd.Test”);

2）调用某个类的类方法（静态方法）

Test.doSomething();

3）访问某个类或接口的类变量，或为该类变量赋值。

int b=Test.a;

Test.a=b;

4）初始化某个类的子类。当初始化子类的时候，该子类的所有父类都会被初始化。

5）直接使用java.exe命令来运行某个主类。

除了上面几种方式会自动初始化一个类，其他访问类的方式都称不会触发类的初始化，称为被动引用。

1、子类引用父类的静态变量，不会导致子类初始化。

public class SupClass

{    public static int a = 123;

static

{

System.out.println("supclass init");

}

}public class SubClass extends SupClass

{    static

{

System.out.println("subclass init");

}

}public class Test

{    public static void main(String[] args)

{

System.out.println(SubClass.a);

}

}

执行结果：

supclass init123

2、通过数组定义引用类，不会触发此类的初始化

public class SupClass

{    public static int a = 123;

static

{

System.out.println("supclass init");

}

}public class Test

{    public static void main(String[] args)

{

SupClass[] spc = new SupClass[10];

}

}

执行结果：

3、引用常量时，不会触发该类的初始化

public class ConstClass

{    public static final String A=  "MIGU";

static

{

System.out.println("ConstCLass init");

}

}public class TestMain

{    public static void main(String[] args)

{

System.out.println(ConstClass.A);

}

}

执行结果：

MIGU

用final修饰某个类变量时，它的值在编译时就已经确定好放入常量池了，所以在访问该类变量时，等于直接从常量池中获取，并没有初始化该类。

初始化的步骤

1、如果该类还没有加载和连接，则程序先加载该类并连接。

2、如果该类的直接父类没有加载，则先初始化其直接父类。

3、如果类中有初始化语句，则系统依次执行这些初始化语句。

在第二个步骤中，如果直接父类又有直接父类，则系统会再次重复这三个步骤来初始化这个父类，依次类推，JVM最先初始化的总是java.lang.Object类。当程序主动使用任何一个类时，系统会保证该类以及所有的父类都会被初始化。

java类加载机制的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java类加载机制有哪些、java类加载机制的信息别忘了在本站进行查找喔。