Java类加载过程(3)

线程上下文类加载器


双亲委托机制以及类加载问题
一般情况下，同一个类中所关联的其他类都是由当前类的类加载器所加载
比如A类在Ext下找到的，则A里面new出来的一些类只能由Ext去查找(不会低于一个级别),所以有些明明App可以找到的，却找不到
JDBC API，有实现的driver部分，JDBC API都是由Boot或者Ext来载入的，但是JDBC driver却是由Ext或App来载入，那么就有可能找不到dirver，在Java领域中，其实只要分成这种API+SPI（Service Provide Interface，特定厂商提供）
常见的SPI有JDBC,JCE,JNDI,JAXP和JBI等，这些SPI接口由Java核心库来提供，如JAXP的SPI接口定义包含在javax.xml.parser包中，SPI的接口是Java核心库的一部分，是用引导类加载来加载；SPI实现的Java类一般是由系统类加载器来加载的，引导类加载器是无法找到SPI的实现类的，因为它只加载Java的核心库


通常需要动态加载资源的时候，至少有三个ClassLoader可以选择：
1 系统类加载器或称为应用类加载器
2 当前类加载器
3 当前线程类加载器


线程类加载器市委类抛弃双亲委派加载链模式
每个线程都有一个关联的上下文类加载器，如果你使用new Thread()方式生成新的线程，新线程将继承其父线程的上下文类加载器，如果程序对线程上下文类加载器没有任何改动的话，程序中所有的线程都适用系统类加载器作为上下文类加载器


获取线程上下文类加载器：
Thread.currentThread().getContextClassLoader()


TOMCAT服务器的类加载机制
TOMCAT不能使用系统默认的类加载器
如果TOMCAT运行WEB项目使用系统的类加载器是危险的，因为这样可以不设限的操作系统的各个目录
对于运行Java EE容器中的Web应用，类加载器实现方式与一般的Java应用有所不同
每个Web应用都有一个对应的类加载器实例，该类加载器也使用代理模式，所不同的事它首先尝试加载某个类，如果找不到在代理给父类加载器，这与一般类加载的顺序是相反的，但也是为了保证安全，这样核心库就不在查询范围内


OSGI(Open Service Gateway Initative)是面向Java的动态模块系统，它为开发人员提供了面向服务和基于组件的运行环境，并提供标准的方式来管理软件的生命周期
原理：
OSGI中的每个模块都包含Java包和类，模块可以声明它所依赖的需要导入的其他模块的Java包和类，也可以声明导出自己的包和类，供其他模块使用，也就是说需要能够隐藏和共享一个模块中的某些Java包和类，这是通过OSGI特有的类加载器机制来实现的，OSGI中的每个模块都有对应的一个类加载器，它负责加载模块自己包含的Java包和类，当它需要加载Java核心库时（以java开头的包和类），它会代理给父类加载器（通常是启动类加载）来完成，当它需要加载所导入的Java类时，它会代理给导出Java类的模块来完成加载，模块也可以显式声明某些Java包和类，必须由父类加载器来加载