一.类加载器的分类:
1.系统提供的类加载器
1.BootStarp(引导类加载器):负责加载java核心类库,不继承自ClassLoader加载器;
2.Extension(扩展类加载器):负责加载java扩展库(例如sun公司专门为连接数据库设计的JDBC的一组API)
3.Application(系统类加载器): 负责加载普通用户编写的java应用类
备注:1.BootStrap加载器是由原生代码(C++)编写而成的,因此不继承自ClassLoader加载器,其他的类加载都必须继承自 ClassLoader加载器
2.以上三个加载器是从表面理念上来说是父子关系,但事实并非继承关系,而是组合的关系
2.自定义类加载器:必须继承自ClassLoader加载器
例如:Tomcat里面的web加载器
二.类加载器内部加载机制的分类:
1 .J2SE:采用的是全盘委托机制(也称双亲委派机制)
机制:双亲委派机制
结构:.树状结构
备注:加载一个类的时候:自下而上检查,在上而下加载
2.J2EE:
1.在Tomcat中 抛弃了双亲委派机制,而是自定义了web加载器,采用的也是代理模式,在加载一个类的时候:自下而上检查,自下而上加载
2.每个文本应用项目都对应自己独立的一个web类加载器
三.由于java编程的设计思想是面向接口编程,
接口+实现
1.sun公司都是某个功能的设计者:SPI接口 sun公司自己设计的接口属于核心库,必须由BootStrap类加载器加载
2.其他公司才是这个功能的实现者:SPI实现类 实现公司写的实现类属于普通java应用类,必须由Application类加载加载
备注:由于双亲委派机制一般都设计为同一个类中所关联的其他类都要让当前类的加载器加载,所以和上面的这种设计理念又发生了冲突,所以提出了
线程上下文类加载器的概念,果断抛弃了双亲委派机制,让其同时加载接口和实现类
代码:Thread.currentThread().setClassLoader(自定义类加载器); 自定义加载器就可以随意改为自己的加载模式了
四.OSGI(Open Service Gateway Initative)面向java的动态模块的系统
1.系统提供的类加载器
1.BootStarp(引导类加载器):负责加载java核心类库,不继承自ClassLoader加载器;
2.Extension(扩展类加载器):负责加载java扩展库(例如sun公司专门为连接数据库设计的JDBC的一组API)
3.Application(系统类加载器): 负责加载普通用户编写的java应用类
备注:1.BootStrap加载器是由原生代码(C++)编写而成的,因此不继承自ClassLoader加载器,其他的类加载都必须继承自 ClassLoader加载器
2.以上三个加载器是从表面理念上来说是父子关系,但事实并非继承关系,而是组合的关系
2.自定义类加载器:必须继承自ClassLoader加载器
例如:Tomcat里面的web加载器
二.类加载器内部加载机制的分类:
1 .J2SE:采用的是全盘委托机制(也称双亲委派机制)
机制:双亲委派机制
结构:.树状结构
备注:加载一个类的时候:自下而上检查,在上而下加载
2.J2EE:
1.在Tomcat中 抛弃了双亲委派机制,而是自定义了web加载器,采用的也是代理模式,在加载一个类的时候:自下而上检查,自下而上加载
2.每个文本应用项目都对应自己独立的一个web类加载器
三.由于java编程的设计思想是面向接口编程,
接口+实现
1.sun公司都是某个功能的设计者:SPI接口 sun公司自己设计的接口属于核心库,必须由BootStrap类加载器加载
2.其他公司才是这个功能的实现者:SPI实现类 实现公司写的实现类属于普通java应用类,必须由Application类加载加载
备注:由于双亲委派机制一般都设计为同一个类中所关联的其他类都要让当前类的加载器加载,所以和上面的这种设计理念又发生了冲突,所以提出了
线程上下文类加载器的概念,果断抛弃了双亲委派机制,让其同时加载接口和实现类
代码:Thread.currentThread().setClassLoader(自定义类加载器); 自定义加载器就可以随意改为自己的加载模式了
四.OSGI(Open Service Gateway Initative)面向java的动态模块的系统