JVM 类加载机制

java文件的生命过程

一 类加载

类从被加载到虚拟机内存中开始，到卸载出内存为止，生命周期如下：

1. 加载

2. 验证

3.准备

4. 解析

5.初始化

有且只有5种情况必须立即对类进行“初始化”

1. 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初 始化，则需要先触发其初始化。
2. 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化， 则需要先触发其初始化。
3. 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父 类的初始化。
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个 类），虚拟机会先初始化这个主类。
5. 当使用JDK 1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后
   的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄 所对应的类没有进行过初始化，则需要先触发其初始化。

这5种场景中的行为称为对一个类进行主动引用。除此之外，所有引用类的方式都 不会触发初始化，称为被动引用。

被动引用

1. 通过其子类来引用父类中定义的静 态字段，只会触发父类的初始化而不会触发子类的初始化。
2. 通过数组定义来引用类，不会触发此类的初始化
3. 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

二 类加载器

类加载阶段中的“==通过一个类的全限定名来获取描述此类的二进制字 节流”==这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的 类。实现这个动作的代码模块称为“类加载器”。

比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意 义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类 加载器不同，那这两个类就必定不相等。

双亲委派模型

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己 去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是 如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈 自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自 己去加载。

被破坏的双亲委派模型

OSGI 热部署

类加载及执行子系统的案例

Class 文件以何种格式存储，类型何时加载、如何连接，以及虚拟机如何执行字节码指令等都是由 虚拟机直接控制的行为，用户程序无法对其进行改变。能通过程序进行操作的，主要是字节 码生成与类加载器这两部分的功能

主流的Java Web服务器，如Tomcat、Jetty、WebLogic、WebSphere或其他的服务器，都实现了自己定义的类加载器（一般都不止一个）

一个功能健全的Web服 务器，要解决如下几个问题：

1. 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。
2. 部署在同一个服务器上的两个Web应用程序所使用的Java类库可以互相共享
3. 服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。
4. 支持JSP应用的Web服务器，大多数都需要支持HotSwap功能。

Tomcat:正统的类加载器架构

在Tomcat目录结构中，有3组目录（“/common/”、“/server/”和“/shared/”）可以存放 Java类库，另外还可以加上Web应用程序自身的目录“/WEB-INF/”，一共4组.

放置在/common目录中：类库可被Tomcat和所有的Web应用程序共同使用。
放置在/server目录中：类库可被Tomcat使用，对所有的Web应用程序都不可见。 放置在/shared目录中：类库可被所有的Web应用程序共同使用，但对Tomcat自己不可 见。
放置在/WebApp/WEB-INF目录中：类库仅仅可以被此Web应用程序使用，对Tomcat和其 他Web应用程序都不可见。

对于Tomcat的6.x版本，只有指定了tomcat/conf/catalina.properties配置文件的server.loader 和share.loader项后才会真正建立CatalinaClassLoader和SharedClassLoader的实例，否则会用到 这两个类加载器的地方都会用CommonClassLoader的实例代替，而默认的配置文件中没有设 置这两个loader项，所以Tomcat 6.x顺理成章地把/common、/server和/shared三个目录默认合 并到一起变成一个/lib目录，这个目录里的类库相当于以前/common目录中类库的作用。

OSGi:灵活的类加载器架构

OSGi在Java程序员中最著名的应用案例就是Eclipse IDE
OSGi中的每个模块（称为Bundle）之间的依赖关系从传统的上层模 块依赖底层模块转变为平级模块之间的依赖.除了更精确的模块划分和可见性控制外，引入OSGi的另外一个重要理 由是，基于OSGi的程序很可能（只是很可能，并不是一定会）可以实现模块级的热插拔功 能，当程序升级更新或调试除错时，可以只停用、重新安装然后启用程序的其中一部分
OSGi的Bundle类 加载器之间只有规则，没有固定的委派关系。

在OSGi里面，加载器之间的关系不再是双亲委派模型的树形结 构，而是已经进一步发展成了一种更为复杂的、运行时才能确定的网状结构。
OSGi在提供强大功能的同时，也引入了额外的复杂度，带来了线 程死锁和内存泄漏的风险。