JVM 类加载机制
JVM 类加载机制分为五个部分：加载、验证、准备、解析、初始化，下面我们分别看一下这五个过程。
加载
加载是类加载过程中的一个阶段，。注意这里不一定非得要从一个 Class 文件获取，这里既可以从 ZIP 包中读取（比如从 jar 包和 war 包中读取），也可以在运行时计算生成（动态代理），也可以由其它文件生成（比如将 JSP 文件转换成对应的 Class 类）。
验证
这一阶段的主要目的是为了，并且不会危害虚拟机自身的安全。
准备
准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即。注意这里所说的初始化概念，比如一个变量定义为：
public static int v = 8080;但是注意如果声明为：
public static final int v = 8080;在编译阶段会为 v 生成 ConstantValue 属性，在。
解析
解析阶段是指。符号引用就是 class 文件中的：
- CONSTANT_Class_info
- CONSTANT_Field_info
- CONSTANT_Method_info
等类型的常量。
使用
符号引用
符号引用与虚拟机实现的布局无关，，但是它们能够接收的符号引用必须是一直的，因为符号引用以字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。
直接引用
直接引用可以。如果有了直接引用，。
初始化
初始化阶段是类加载最后一个阶段，经过前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由 JVM 主导。到了初始阶段。才开始真正执行类中定义的 Java 程序代码。
类构造器 client
初始化阶段。 client 方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。虚拟机会保证子 client 方法执行之前，父亲的 client 方法已经执行完毕，。
注意一下几种情况不会执行类初始化：
- 通过子类引用父类的静态字段，只会触发父亲的初始化，而不会触发子类的初始化。
- 定义对象数组，不会触发该类的初始化。
- 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
- 通过类名获取 Class 对象，不会触发类的初始化。
- 通过 Class.forName 加载指定类时，如果指定参数 initialize 为 false 时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
- 通过 Class.Loader 默认的 loadClass 方法，也不会触发初始化动作。
类加载器
虚拟机设计团队把加载动作放到 JVM 外部实现，以便让应用程序决定如何获取所需的类，JVM 提供了 3 中类加载器。
启动类加载器（BootStrap ClassLoader）
负责加载 目录中的，或通过 -Xbootclasspath 参数指定路径中的，且被虚拟机认可（按文件识别，如 rt.jar）的类。
扩展类加载器（Extension ClassLoader）
负责加载 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库。
应用程序类加载器（Application ClassLoader）
负责加载。JVM 通过双亲委派模型进行类的加载，当然我们也可以通过继承 java.lang.ClassLoader 实现自定义的类加载器。
双亲委派
，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载中，。采用双亲委派的一个好处是，比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了。
OSGI（动态模型系统）
OSGI（Open Service Gateway Initiative），是面向 Java 的动态模型系统，是 Java 动态模块化系统的一系列规范。
动态改变构造
OSGI 服务平台提供在多种网络设备上无需重启的动态改变构造的功能。为了最小化耦合度和促使这些耦合度可管理，OSGI 技术提供一种面向服务的架构，他能使这些组件动态的发现对方。
模块化编程域热插拔
OSGI 旨在为实现 Java 程序的模块化编程提供基础条件，基于 OSGI 的程序很可能可以，当程序升级更新时，可以只停用、重新安装然后启动程序的其中一部分，这对企业级程序开发来说是非常具有诱惑力的特性。
OSGI 描绘了一个很美好的模块化开发目标，而且定义了实现这个目标的所需要服务与架构，同时也有成熟的框架进行实现支持。但并非所有的应用都适合采用 OSGI 作为基础架构，它在提供强大功能同时，也引入了额外的复杂度，因为它不遵守类加载的双亲委托模型。