java多线程与并发（八）——java类加载器与OSGi加载_oshi是那个类加载器加载的-优快云博客

本文链接：https://blog.youkuaiyun.com/u010843421/article/details/81237371

本文详细介绍了Java类加载机制的过程，包括加载、验证、准备、解析和初始化等阶段，以及类加载器的种类与双亲委派机制。此外还介绍了OSGi框架及其模块化特性，展示了如何实现动态模块管理和类加载。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

参考https://blog.youkuaiyun.com/u010126792/article/details/65940064

一、java类加载器机制

jvm想执行.class文件第一步就是把class文件装载进内存。
java类加载器的作用是在运行时加载类。

Java类加载机制指的是将java编译后生成的.class文件中的二进制数据读入到内存中，将其放到jvm构造的运行时数据区内存的方法区中，在heap堆区创建对应的描述Class结构的原信息对象，通过该元数据对象可以获取Class结构的众多信息，用户可以通过此Class信息调用class对象的功能。类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口，这就是虚拟机的类加载机制。
简单来说，Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的加载机制。

二、类加载的过程

包括了装载、链接（验证、准备、解析）、初始化五个阶段。五个阶段中加载，验证，准备和初始化发生的顺序是确定的，解析过程则不确定。运行时才知道最终对象的引用，所以解析阶段可能发生在初始化阶段之后。虽然这几个阶段是按顺序开始的，但他们不是按顺序执行的，也就是说他们的执行和完成的时间不分先后，通常都是相互交叉进行。

（1）装载阶段：查找并加载类的二进制数据

类加载的第一个阶段，jvm虚拟机需要完成下面三个重要工作：
1、通过一个类的全限定名来获取其定义的二进制字节流。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

（2）连接阶段：进行验证、准备和解析

1）验证阶段：此阶段主要为保证加载类的正确性。

文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。

元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。

字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。

符号引用验证：确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

2）准备阶段：为类型分配内存并初始化为默认值

准备阶段为类的静态变量分配内存（在方法区内存中，此处只考虑方法区存在的情况，注：jdk1.7将方法区一部分移到了堆中，jdk1.8元数据区替代了原来的永久代），并将其初始化为默认值，而不是代码中赋予的初始值，初始值的赋予则是在java类初始化阶段完成。对于基本类型的静态变量一般被赋予0，对于引用的静态类型，一般被赋予null，但是如果被final修饰，准备阶段就会被赋予代码中的初始值，此时已经将变量值放入了方法区的常量池中。注：类的实例变量内的分配随着对象的实例化在堆中分配内存。

3）解析阶段：将字符引用解析为直接饮用

把类中的符号引用转化为直接引用，虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行，在此之前的符号引用仅仅是一个标识。

（3）初始化阶段：

初始化，为类的静态变量赋予正确的初始值（上个阶段已经赋值（默认值）），JVM负责对类进行初始化，主要对类变量进行初始化。

JVM初始化步骤
1、假如这个类还没有被加载和连接，则程序先加载并连接该类
2、假如该类的直接父类还没有被初始化，则先初始化其直接父类
3、假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化的时机：
1.创建类的实例
2.访问类的静态变量，或静态变量的赋值
3.调用类的静态方法
4.使用反射获取类的信息，强制创建类的实例对象
5.初始化某个类的子类时
6.直接使用java.exe运行某个类的主类

三、类加载器

JVM利用类加载器ClassLoader来完成类的加载，Java虚拟机中的类加载器分为两种：原始类加载器（primordial class loader）和类加载器对象（class loaderobjects）。原始类加载器是Java虚拟机实现的一部分，类加载器对象（java编写）是运行中的程序的一部分。

类加载器利用命名空间进行区分，子加载器的命名空间包含所有父加载器的命名空间。因此子加载器加载的类能看见父加载器加载的类。例如系统类加载器加载的类能看见根类加载器加载的类。由父加载器加载的类不能看见子加载器加载的类。如果两个加载器之间没有直接或间接的父子关系，那么它们各自加载的类相互不可见。

类加载器可以分为启动类加载器：BootstrapClassLoader，扩展类加载器：ExtensionClassLoader，应用程序类加载器：Application ClassLoader。第一种属于前文的原始类加载器，后两种成为类加载器对象。

类加载有三种方式：
1、命令行启动应用时候由JVM初始化加载
2、通过Class.forName()方法动态加载
3、通过ClassLoader.loadClass()方法动态加载

java类加载基于三个机制：
1、双亲委派：
如果一个类加载器接收到了类加载的请求，它首先把这个请求委托给他的父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载请求都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它在搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
2、可见性原理
3、单一性

为什么要自定义类加载器：

简单的原因就是因为系统提供的类加载器无法满足实际某些场景的应用，

类似javaWeb服务器，可能在一个服务器上部署了多个网站，每个网站会用到一些相同的类库，如果只利用系统的类加载器则只能存在一种类库，对于不同版本的类库则不能同时存在；jsp热替换的支持， JSP最终要编译成.class文件才能由虚拟机执行，但JSP运行时修改的概率远远大于第三方类库或自身.class文件，而且JSP这种网页应用也把修改后无须重启作为一个很大的优势看待，这些系统提供的加载器都无法完全满足，需要自己定义加载器。

Java中的类加载器，有启动类加载器(Bootstrap Classloader)、扩展类加载器（Launcher$$ExtClassLoader）、应用程序类加载器（Launcher$AppClassLoader），用户还可以实现自定义的类加载器.。
类加载的这种关系称为双亲委派模式，需要注意的是他们之间不是继承关系，而是组合关系，在执行类加载的动作时，首先都是交给父类去加载，如果父类无法加载再交给子类去完成，直到调用用户自定义的类加载器去加载，如果全部都无法加载，就会抛出ClassNotFoundException。

OSGi加载

参考https://blog.youkuaiyun.com/u012712901/article/details/78080987

一、OSGi是什么？

是面向Java的动态模型系统，是Java动态化模块化系统的一系列规范。
OSGi服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGi技术提供一种面向服务的架构，它能使这些组件动态地发现对方。

二、OSGi的结构是怎样的

既然OSGi是动态模型系统，那么它的结构又是怎样的呢。

OSGI规范的核心组件是OSGI框架。这个框架为应用程序（被叫做组件（bundle））提供了一个标准环境。整个框架可以划分为一些层次：

L0：运行环境
L1：模块
L2：生命周期管理
L3：服务注册
还有一个无处不在的安全系统渗透到所有层。
这里写图片描述

（1）L0运行环境
L0层执行环境是Java环境的规范。Java2配置和子规范，像J2SE，CDC，CLDC，MIDP等等，都是有效的执行环境。OSGi平台已经标准化了一个执行环境，它是基于基础轮廓和在一个执行环境上确定了最小需求的一个小一些的变种，该执行环境对OSGi组件是有用的。

(2)L1模块层
L1模块层定义类的装载策略。OSGi框架是一个强大的具有严格定义的类装载模型。它基于Java之上，但是增加了模块化。在Java中，正常情况下有一个包含所有类和资源的类路径。OSGi模块层为一个模块增加了私有类同时有可控模块间链接。模块层同安全架构完全集成，可以选择部署到部署封闭系统，防御系统，或者由厂商决定的完全由用户管理的系统。

(3)L2生命周期层
L2生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles。这些bundles依赖于于具有类装载功能的模块层，但是增加了在运行时管理这些模块的API。生命周期层引入了正常情况下不属于一个应用程序的动态性。扩展依赖机制用于确保环境的操作正确。生命周期操作在安全架构保护之下，使其不受到病毒的攻击。

(4)L3服务注册层
L3层增加了服务注册。服务注册提供了一个面向bundles的考虑到动态性的协作模型。bundles能通过传统的类共享进行协作，但是类共享同动态安装和卸载代码不兼容。服务注册提供了一个在bundles间分享对象的完整模型。定义了大量的事件来处理服务的注册和删除。这些服务仅仅是能代表任何事物的Java对象。很多服务类似服务器对象，例如HTTP服务器，而另一些服务表示的是一个真实世界的对象，例如附近的一个蓝牙手机。这个服务模块提供了完整安全保障。该服务安全模块使用了一个很聪明的方式来保障bundles之间通信安全。