深入Java类加载器

最新推荐文章于 2024-08-06 16:39:47 发布

coderbean

最新推荐文章于 2024-08-06 16:39:47 发布

阅读量421

点赞数

分类专栏： Java 文章标签： java

本文链接：https://blog.csdn.net/coderbean/article/details/48032035

版权

Java 专栏收录该内容

38 篇文章 0 订阅

订阅专栏

深入Java类加载器

类加载器原理

类加载器的作用
- 将class文件字节码内容加载到内存中，并将这些静态数据转化成方法区中的运行时数据结构，在堆中生成一个代表这个类的java.lang.Class对象，作为方法取类数据的访问入口
类缓存
- 标准的Java SE类加载器可以按照要求加载类，但一旦某个类被加载到类加载器中，它将维持一段时间（缓存）。不过，JVM垃圾收集器可以回收这些Class对象

类加载器层次结构（树状结构）

引导类加载器（bootstrap class loader）
- 它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar, 或sun.boot.class.path路径下的内容），是用原生代码实现的，并不继承自java.lang.ClassLoader
- 加载扩展类加载器和应用程序类加载器，并指定他们的父类加载器。
扩展类加载器（extensions class loader）
- 用来加载 Java 的扩展库(JAVA_HOME/jre/ext/*.jar, 或 java.ext.dirs 路径下的内容)。java 虚拟机的实现会提供一个扩展库目录。该类加载器在该目录中查找并加载 Java 类。
- 由 sun.misc.Launcher$ExtClassLoader 实现
应用程序类加载器（application class loader）
- 它根据 Java 应用的类路径( class , java.class.path 路径下的内容)，一般来说 java 应用的类都是由它来完成加载的
- 由 sun.misc.Launcher$AppClassLoader 实现
自定义类加载器
- 开发人员可以通过继承 java.lang.ClassLoader 类的方式实现自己的类加载器，以满足一些特殊的需求

图示：（并不是继承关系，而是组合）

java.lang.ClassLoader 类介绍

作用：
- java.lang.ClassLoader 类的基本职责就是根据一个指定类的名称，找到或者生成其对应的字节代码，让后从这些字节代码中定义出一个 Java 类，即 java.lang.ClassLoader 的一个实例。
- 除此之外，ClassLoader 还负责加载 Java 应用所需要的资源，如图像文件和配置文件等。
相关方法：
- 参阅 JDK 文档
  - 对于这些方法表示类名称的 name 参数的值是二进制名称。需要注意的是内部类的表示。如：com.sample.Sample$1 和 com.sample.Sample$Inner等表示方式

类加载器的代理模式

代理模式
- 交给其他加载器来加载指定的类
双亲委托机制
- 就是某一个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次追溯，直到最高的爷爷辈的，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成加载任务时，才自己去加载
- 双亲委托机制是为了保证 Java 核心库的安全。
  - 这种机制就保证不会出现用户自己能定义 java.lang.Object 类的情况
- 类加载器除了用于加载类，也是安全的最基本屏障。
双亲委托机制是代理模式的一种
- 并不是所有的类加载器都采用双亲委托机制。
- Tomcat 服务器类加载器也使用代理模式，所不同的是它是首先去尝试加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。

自定义类加载器（文件、网络、加密）

自定义类加载器流程：

继承 java.lang.ClassLoader
首先检查请求的类型是否已经被这个类加载器加载到命名空间中去了，如果已经装载，直接返回；
委托类加载请求给父类加载器，如果父类加载器能够完成，则返回父类加载器加载的 Class 实例；
调用本类加载器的 findClass(...) 方法，试图获取对应的字节码，如果获取的到，则调用 defineClass(...) 导入类型到方法区；如果获取不到对应的字节码或者其他原因导致失败，返回异常给 loadClass(...) ， loadClass(....) 转抛异常，终止加载过程
注意：被两个加载器加载的同一个类，JVM 不认为是相同的类
文件系统类加载器代码：

package com.coderbean.test;

import java.io.ByteArrayOutputStream;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;

/**
 * 自定义文件系统类加载器
 * @author chang
 *
 */
public class FileSystemClassLoader extends ClassLoader {
   private String rootDir;
   public FileSystemClassLoader(String rootDir){
       this.rootDir = rootDir;
   }

   @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
    Class<?> c = findLoadedClass(name);
    //首先查询有没有加载过这个类。如果已经加载，则直接返回加载好的类。如果没有，则加载新的类
    if(null != c){
        return c; 
    }else{
        ClassLoader parent = this.getParent();
        try {
        c = parent.loadClass(name); //委派给父类加载器加载指定类
        } catch (Exception e) {
        // TODO Auto-generated catch block
        //e.printStackTrace();
        }
        if(null != c){
        return c;
        }else{
        byte[] classData = getClassData(name);
        if(null == classData){
            throw new ClassNotFoundException();
        }else{
//          System.out.println(classData.length);
            c = defineClass(name, classData, 0, classData.length);
        }
        }
    }
    return c;
    }
   private byte[] getClassData(String classname){
       String path = this.rootDir + "/" + classname.replace('.', '/') + ".class";
//       System.out.println(path);
       InputStream is = null;
       ByteArrayOutputStream baos = new ByteArrayOutputStream();
       try {
       is = new FileInputStream(path);

       byte[] buffer = new byte[1024];
       int temp = 0;
       while(-1!=(temp = is.read(buffer))){
           baos.write(buffer, 0, temp);
       }

       return baos.toByteArray();
        } catch (FileNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
            return null;
        } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
        return null;
    }finally{
            if(null != is){
            try {
            is.close();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
            }
            if(baos != null)
            {
            try {
            baos.close();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
            }
        }

   }
}

线程上下文加载器

双亲委托机制以及类加载器的问题

一般情况下，保证同一个类中所关联的其他类都是由当前类的类加载器加载的。比如ClassA本身在Ext下找到，那么他里面 new 出来的一些类也只能 Ext 去查找了（不会低一个级别），所以有些明明 App 可以找到的，却找不到了
JDBC API 他有实现的 driven 部分（sqlserver / mySql），我们的JDBC API 都是由Boot 或者 Ext 来载入的，但是 JDBC driven 却是由 Ext 和 App 来载入的，那么就有可能找不到 driven 了。在 Java领域中，其实只要分成这种API + SPI（Service Provided Interface，特定厂商提供）的，都会遇到这种问题。
常见的SPI有JDBC、JCE、JNDI、JAXP、和 JBI 等。这些 SPI 的接口由JAVA核心库提供，如 JAXP 的 SPI 接口定义包含在javax.xml.parsers 包中。SPI接口是JAVA核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器无法找到 SPI 的实现类，因为它只加载 Java 的核心库。
通常你需要动态加载资源的时候，你至少有三个 ClassLoader 可以选择：
1. 系统类加载器（或者叫应用类加载器）System ClassLoader 或 Application ClassLoader
2. 当前类加载器
3. 当前线程类加载器
线程类加载器是为了抛弃双亲委派加载链模式。
- 每一个线程都有一个关联的线程上下文类加载器。如果你使用new Thread() 方式生成新的线程，新线程将继承其父线程的上下文类加载器。如果程序对于线程上下文类加载器没有任何改动的话，程序中所有的线程都将使用系统类加载器作为上下文类加载器
- Thread.currentThread().getContextClassLoader()
- Thread.currentThread().setContextClassLoader()
线程上下文类加载器测试代码：

package com.coderbean.test;
/**
 * 线程上下文类加载器测试
 * @author chang
 *
 */
public class Demo05 {
    public static void main(String[] args) throws ClassNotFoundException {
    ClassLoader loader = Demo05.class.getClassLoader();
    System.out.println(loader);

    ClassLoader loader2 = Thread.currentThread().getContextClassLoader();
    System.out.println(loader2);

    Thread.currentThread().setContextClassLoader(new FileSystemClassLoader("/home/chang/Documents/test"));
    System.out.println(Thread.currentThread().getContextClassLoader());

    Class<?> c  = Thread.currentThread().getContextClassLoader().loadClass("HelloWorld");
    System.out.println(c);
    System.out.println(c.getClassLoader());
    }
}

服务器加载原理和OSGI介绍

TOMCAT 服务器的类加载机制

一切为了安全
- TOMCAT 不能使用系统默认的类加载器。
  - 如果TOMCAT跑你的Web项目使用系统的类加载器是十分危险的，你可以直接肆无忌惮的操作系统的各个目录
  - 对于运行在 Java EE 容器中的Web应用来说，类加载器的实现方式与一般的 Java 应用不同。
  - 每个 Web 应用都有一个对应的类加载器的实例。该类加载也使用代理模式（不同于双亲委派机制），不同的是他首先尝试去加载某个类，如果找不到再代理给父类加载器，这与一般类加载器的顺序是相反的。但也是为了保证安全，这样核心库就不在查询范围之内。
为了安全 TOMCAT 需要自己实现类加载器
- 我可以限制你只把类写在指定的地方，否则不给你加载！

OSGi 原理介绍

OSGI (Open Service Gateway Initative) 是面向Java的动态模块系统。它为开发人员提供了面向服务和基于组件的运行环境，并提供标准的方式用来管理软件的生命周期
OSGi 已经被实现和部署在很多产品上，在开源社区也得到了广泛的支持。Eclipse 就是基于 OSGi 技术来构建的。
原理：
- OSGi 中的每个模块（bundle）都包含 Java 包和类。模块可以声明他所以来的需要导入（import）的其他模块的 Java 包和类（通过 Import-Package），也可以声明导出（export）自己的包和类，供其他模块使用（通过 Export-Package）。也就是说需要能够隐藏和共享一个模块中的某些 Java 包和类。这是通过 OSGi 特有的类加载器机制来实现的。 OSGi 中的每个模块都有对应的一个类加载器。它负责加载模块自己包含的 Java 包和类。 当它需要加载 Java 核心库的类时（以 java 开头的包和类），它会代理给父类加载器（通常是启动类加载器）来完成。当它需要加载所导入的Java类时，它会代理给导出此 Java 类的模块来完成加载。模块也可以显式的声明某些 Java 包和类，必须由父类加载器加载。只需要设置系统属性 org.osgi.framework.bootdelegation 的值即可`