6. 通过demo分析自定义类加载器以及Launcher源码分析

Posted 2021-03-16 duguxiaobiao

目录

• 1. 先创建自定义类加载器
• 2. demo程序
  • 2.1 最初版程序
  • 2.2 第二版---使用命令行执行，设置指定的类加载器作为系统类加载器
• 3. Launcher源码分析
  • 3.1 分析入口在哪里---ClassLoader官方文档
  • 3.2 有些人就要问了，为什么直接锁定入口就是在ClassLoader.getSystemClassLoader()呢
  • 3.3 系统类加载器和扩展类加载器是如何创建和初始化的
  • 3.4 如何将自定义类加载器作为默认的系统类加载器的
    • 3.4.1 通过 SystemClassLoaderAction 构造方法将默认的系统类的类加载器，后续通过判断看是否返回
    • 3.4.2 判断是否配置了自定义系统类加载器
    • 3.4.3 根据传入的自定义系统类加载器类全名，来实例化该类加载
• 4. 添加构造方法，完善程序
  • 4.1 在自定义类加载器CustomClassLoader中添加构造方法
  • 4.2 也许有人会问 为什么类Test17(当前类)为什么不是被当前默认的自定义系统类加载器所加载，而是还是被jvm的AppClassLoader所加载？
• 5. 也许有人会问，如何验证以上的说法是正确的，如何证明我们自定义的系统类加载器能够使用？
  • 5.1 我们调整一下demo，添加一个加载指定类的操作，代码如下：
  • 5.2 添加参数 -Djava.system.class.loader=com.lonely.jvmstudy.examples.CustomClassLoader
  • 5.3 删除项目中Test14编译后的class文件
  • 5.4 也许有人会问，为什么路径是这个呢。

1. 先创建自定义类加载器

在之前的demo中，已经存在该自定义类加载代码，避免再次寻找，这里再次输出出来

package com.lonely.jvmstudy.examples;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.text.MessageFormat;
import java.util.Optional;

public class CustomClassLoader extends ClassLoader {

    /**
 * 类加载器名称
  */
  private String classLoaderName;

/**
 * 类加载器根目录,默认D盘
  */
private String path = "D:/";

    private static final String suffixName = ".class";

    /**
 * 默认以systemClassLoader为父类加载器
  *
 * @param classLoaderName
  */
  public CustomClassLoader(String classLoaderName) {
        super();
        this.classLoaderName = classLoaderName;
    }

    /**
 * 使用传入的classlaoder作为其双亲
  *
 * @param parent
  * @param classLoaderName
  */
  public CustomClassLoader(ClassLoader parent, String classLoaderName) {
        super(parent);
        this.classLoaderName = classLoaderName;
    }

    /**
 * Finds the class with the specified <a href="#name">binary name</a>.
 * This method should be overridden by class loader implementations that * follow the delegation model for loading classes, and will be invoked by * the {@link #loadClass <tt>loadClass</tt>} method after checking the
 * parent class loader for the requested class.  The default implementation * throws a <tt>ClassNotFoundException</tt>.
 * * @param name The <a href="#name">binary name</a> of the class * @return The resulting <tt>Class</tt> object * @throws ClassNotFoundException If the class could not be found
 * @since 1.2
 */  @Override
  protected Class<?> findClass(String name) throws ClassNotFoundException {
        System.out.println("findClass..");
        byte[] bytes = this.loadClassData(name);
        return this.defineClass(name, bytes, 0, bytes.length);
    }

    /**
 * 加载指定className对应的文件，返回对应的数据,这里注意使用 read()读取class文件内容时，只能一个一个字节的读取，不能一次多个。
  *
 * @param className
  * @return
  */
  private byte[] loadClassData(String className) {
        className = className.replace(".", "/");
        byte[] readDatas = null;
        try (ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
             FileInputStream fileInputStream = new FileInputStream(new File(Optional.ofNullable(this.path).orElse("") + className + suffixName));) {

            int result;
            while ((result = fileInputStream.read()) != -1) {
                byteArrayOutputStream.write(result);
            }

            /*byte[] datas = new byte[1];
 while (fileInputStream.read(datas) != -1) { byteArrayOutputStream.write(datas); }*/  readDatas = byteArrayOutputStream.toByteArray();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return readDatas;
    }

    @Override
    public String toString() {
        return this.getClass().toString();
    }

    public void setPath(String path) {
        this.path = path;
    }
}

2. demo程序

2.1 最初版程序

package com.lonely.jvmstudy.examples;

/**
 * @author ztkj-hzb
 * @Date 2019/12/26 16:52
 * @Description 分析自定义类加载器，使用参数设置自定义类加载器，分析Launcher源码
  */
public class Test17 {

    public static void main(String[] args) {

        //获取指定属性值
  System.out.println(System.getProperty("java.system.class.loader"));

        //输出当前类加载器
  System.out.println(Test17.class.getClassLoader());


        //输出应用类加载器
  System.out.println(ClassLoader.getSystemClassLoader());

    }

}

执行后，得到以下结果：

null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2

分析结果：
1.首先 "java.system.class.loader" 该属性是用来使用指定的自定义类加载来覆盖默认的系统类加载器(AppClassLoader),因为这里是直接启动，没有为该参数赋值，所以返回null
2.因为当前程序还是使用的最初的系统类加载器，因此下面的结果都是系统类加载器，没疑问。

2.2 第二版---使用命令行执行，设置指定的类加载器作为系统类加载器

使用以下命令，指定自定义类加载器位置，注意这里的包路径写法，注意！
[使用java命令运行class文件提示“错误：找不到或无法加载主类“的问题分析][https://www.cnblogs.com/guohu/p/11101285.html]
[https://www.cnblogs.com/guohu/p/11101285.html]: https://www.cnblogs.com/guohu/p/11101285.html "使用java命令运行class文件提示“错误：找不到或无法加载主类“的问题分析"

D:workspace_demojvm-study	argetclasses>java -Djava.system.class.loader=com.lonely.jvmstudy.examples.CustomClassLoader com.lonely.jvmstudy.examples.Test17
Error occurred during initialization of VM
java.lang.Error: java.lang.NoSuchMethodException: com.lonely.jvmstudy.examples.CustomClassLoader.<init>(java.lang.ClassLoader)
        at java.lang.ClassLoader.initSystemClassLoader(Unknown Source)
        at java.lang.ClassLoader.getSystemClassLoader(Unknown Source)
Caused by: java.lang.NoSuchMethodException: com.lonely.jvmstudy.examples.CustomClassLoader.<init>(java.lang.ClassLoader)
        at java.lang.Class.getConstructor0(Unknown Source)
        at java.lang.Class.getDeclaredConstructor(Unknown Source)
        at java.lang.SystemClassLoaderAction.run(Unknown Source)
        at java.lang.SystemClassLoaderAction.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.lang.ClassLoader.initSystemClassLoader(Unknown Source)
        at java.lang.ClassLoader.getSystemClassLoader(Unknown Source)

分析以上结果：
1.首先，在这里使用属性 "java.system.class.loader" 指定了自定义类加载器路径，从异常结果中可以看到确实加载了该类。
2.结果中提示我们自定义的类加载器缺少一个带以ClassLoader为入参的构造方法，我们再次查看我们的自定义类加载器，发现确实没有该种情况的构造方法。那么问题来了，为什么需要这样一个构造方法。我们开始分析其源码，go~~

3. Launcher源码分析

3.1 分析入口在哪里---ClassLoader官方文档

我们进入类 ClassLoader.getSystemClassLoader()方法，打开其官方文档，发现会有这么一段话

If the system property "<tt>java.system.class.loader</tt>" is defined
when this method is first invoked then the value of that property is
taken to be the name of a class that will be returned as the system
class loader.  The class is loaded using the default system class loader
and must define a public constructor that takes a single parameter of
type <tt>ClassLoader</tt> which is used as the delegation parent.  An
instance is then created using this constructor with the default system
class loader as the parameter.  The resulting class loader is defined
to be the system class loader.

翻译后，就是

如果在首次调用此方法时定义了系统属性“ java.system.class.loader”，则该属性的值将作为要作为系统类加载器返回的类的名称。该类使用默认的系统类加载器加载，并且必须定义一个公共构造函数，该构造函数采用单个类型为ClassLoader的参数作为委托父级。然后使用此构造函数创建一个实例，并使用默认系统类加载器作为参数。结果类加载器定义为系统类加载器。

从文档中，我们就可以看出我们刚才使用的属性，以及为什么需要这么一个以ClassLoader为参数的构造方法了。虽然说一切学习以官方文档为准，但是还是要真正看到如何实现才放心，下面就开始验证这部分文档的代码寻找之旅，go~~~

3.2 有些人就要问了，为什么直接锁定入口就是在ClassLoader.getSystemClassLoader()呢

首先，该结论我也不知道，哈哈，曾经看教程时看到的，在jvm启动时启动类加载器会初始化ClassLoader类，以及扩展类加载器，系统类加载器。但是启动类加载器不是java类，看不到代码，因此，只能使用一个小demo来测试，表示在程序的最开始就会调用ClassLoader.getSystemClassLoader()。

package com.lonely.jvmstudy.examples;

/**
 * @author ztkj-hzb
 * @Date 2020/1/9 11:23
 * @Description
  */
public class Test18 {

    public static void main(String[] args) {

        System.out.println("----------------------start---------------------");

        System.out.println(ClassLoader.getSystemClassLoader());

        System.out.println("-----------------------end----------------------");

    }

}

我们断点启动该类，且在ClassLoader.getSystemClassLoader()方法中加断点，启动程序后就会发现，首先进入到ClassLoader的断点中，执行在程序的第一行输出之前，且可以使用调试工具，向上执行，可以发现在System类中会调用该类。因此，首先可以确定一点，ClassLoader.getSystemClassLoader()会在很早之前执行。

3.3 系统类加载器和扩展类加载器是如何创建和初始化的

我们进入到ClassLoader.getSystemClassLoader()方法的源码中

public static ClassLoader getSystemClassLoader() {
    //初始化系统类加载器
    initSystemClassLoader();
    if (scl == null) {
        return null;
    }
    SecurityManager sm = System.getSecurityManager();
    if (sm != null) {
        checkClassLoaderPermission(scl, Reflection.getCallerClass());
    }
    return scl;
}

这段代码，我们只需要分析 initSystemClassLoader()方法，进入其中

private static synchronized void initSystemClassLoader() {
    if (!sclSet) {
        if (scl != null)
            throw new IllegalStateException("recursive invocation");
        sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
        if (l != null) {
            Throwable oops = null;
            scl = l.getClassLoader();
            try {
                scl = AccessController.doPrivileged(
                    new SystemClassLoaderAction(scl));
            } catch (PrivilegedActionException pae) {
                oops = pae.getCause();
                if (oops instanceof InvocationTargetException) {
                    oops = oops.getCause();
                }
            }
            if (oops != null) {
                if (oops instanceof Error) {
                    throw (Error) oops;
                } else {
                    // wrap the exception
  throw new Error(oops);
                }
            }
        }
        sclSet = true;
    }
}

该段代码主要任务：

1. Launcher类的初始化，该类会初始化扩展类加载器以及默认的系统类加载器
2. 判断是否由自定义类加载器作为系统类加载器

sun.misc.Launcher l = sun.misc.Launcher.getLauncher();

这段代码 调用了Launcher的静态方法getLauncher(),属于主动调用，会导致该类的初始化，所以进入该类，分析其构造方法，源码如下：

public Launcher() {
    Launcher.ExtClassLoader var1;
    try {
        var1 = Launcher.ExtClassLoader.getExtClassLoader();
    } catch (IOException var10) {
        throw new InternalError("Could not create extension class loader", var10);
    }

    try {
        this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
    } catch (IOException var9) {
        throw new InternalError("Could not create application class loader", var9);
    }

    Thread.currentThread().setContextClassLoader(this.loader);
    String var2 = System.getProperty("java.security.manager");
    if (var2 != null) {
        SecurityManager var3 = null;
        if (!"".equals(var2) && !"default".equals(var2)) {
            try {
                var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();
            } catch (IllegalAccessException var5) {
                ;
            } catch (InstantiationException var6) {
                ;
            } catch (ClassNotFoundException var7) {
                ;
            } catch (ClassCastException var8) {
                ;
            }
        } else {
            var3 = new SecurityManager();
        }

        if (var3 == null) {
            throw new InternalError("Could not create SecurityManager: " + var2);
        }

        System.setSecurityManager(var3);
    }

}

该段代码，首先使用 Launcher.ExtClassLoader.getExtClassLoader(); 初始化扩展类加载器，进入该方法中，查看是如何初始化的

public static Launcher.ExtClassLoader getExtClassLoader() throws IOException {
    if (instance == null) {
        Class var0 = Launcher.ExtClassLoader.class;
        synchronized(Launcher.ExtClassLoader.class) {
            if (instance == null) {
                instance = createExtClassLoader();
            }
        }
    }

    return instance;
}

private static Launcher.ExtClassLoader createExtClassLoader() throws IOException {
    try {
        return (Launcher.ExtClassLoader)AccessController.doPrivileged(new PrivilegedExceptionAction<Launcher.ExtClassLoader>() {
            public Launcher.ExtClassLoader run() throws IOException {
                //从属性 java.ext.dirs 中加载对应的jar包文件
                File[] var1 = Launcher.ExtClassLoader.getExtDirs();
                int var2 = var1.length;

                for(int var3 = 0; var3 < var2; ++var3) {
                    MetaIndex.registerDirectory(var1[var3]);
                }

                return new Launcher.ExtClassLoader(var1);
            }
        });
    } catch (PrivilegedActionException var1) {
        throw (IOException)var1.getException();
    }
}

private static File[] getExtDirs() {
    String var0 = System.getProperty("java.ext.dirs");
    File[] var1;
    if (var0 != null) {
        StringTokenizer var2 = new StringTokenizer(var0, File.pathSeparator);
        int var3 = var2.countTokens();
        var1 = new File[var3];

        for(int var4 = 0; var4 < var3; ++var4) {
            var1[var4] = new File(var2.nextToken());
        }
    } else {
        var1 = new File[0];
    }

    return var1;
}

这段代码主要意思就是：创建一个扩展类加载器，且从指定路径中：java.ext.dirs 获取jar包，class文件，由扩展类加载器加载到内存中。

下面以同样的方式初始化默认的系统类加载器，稍微有点区别

1. 系统类加载器是从路径：java.class.path 中获取
2. 系统类加载器以扩展类加载器作为其父级加载器，这里就体现了双亲模式的建立。

3.4 如何将自定义类加载器作为默认的系统类加载器的

针对方法initSystemClassLoader()，刚才模块3.3主要分析了如何初始化扩展类加载器以及系统类加载器，现在，就刚才的后面继续分析，如何将自定义的类加载器作为默认的系统类加载器的
ClassLoader.initSystemClassLoader()#
scl = AccessController.doPrivileged(new SystemClassLoaderAction(scl));
这段代码就介绍了如何使用自定义类加载器作为默认的系统类加载器，同时说明了使用自定义类加载器需要定义一个以ClassLoader作为参数的构造方法。废话不多说，go

class SystemClassLoaderAction
    implements PrivilegedExceptionAction<ClassLoader> {
    private ClassLoader parent;

    SystemClassLoaderAction(ClassLoader parent) {
        this.parent = parent;
    }

    public ClassLoader run() throws Exception {
        String cls = System.getProperty("java.system.class.loader");
        if (cls == null) {
            return parent;
        }

        Constructor<?> ctor = Class.forName(cls, true, parent)
            .getDeclaredConstructor(new Class<?>[] { ClassLoader.class });
        ClassLoader sys = (ClassLoader) ctor.newInstance(
            new Object[] { parent });
        Thread.currentThread().setContextClassLoader(sys);
        return sys;
    }
}

3.4.1 通过 SystemClassLoaderAction 构造方法将默认的系统类的类加载器，后续通过判断看是否返回

SystemClassLoaderAction(ClassLoader parent) {
    this.parent = parent;
}

3.4.2 判断是否配置了自定义系统类加载器

通过属性 java.system.class.loader 的值来判断是否需要替换默认的系统类加载器。如果没有值，则返回传入的默认的系统类加载器。如果有值，那么进入下一步

3.4.3 根据传入的自定义系统类加载器类全名，来实例化该类加载

Constructor<?> ctor = Class.forName(cls, true, parent).getDeclaredConstructor(new Class<?>[] { ClassLoader.class });
ClassLoader sys = (ClassLoader) ctor.newInstance(new Object[] { parent });
Thread.currentThread().setContextClassLoader(sys);

这段代码是什么意思呢，就是首先通过反射根据全类名获取对应的Class对象，然后获取其中以ClassLoader为参数的构造方法，将默认的系统类加载器作为其父类加载传入，来构建对象。这就解释了，为什么使用我们自定义系统类加载器执行代码时会提示缺少一个以ClassLoader为参数的构造方法了。

4. 添加构造方法，完善程序

4.1 在自定义类加载器CustomClassLoader中添加构造方法

/**
 * 添加带参构造方法
  * @param parent
  */
public CustomClassLoader(ClassLoader parent){
    super(parent);
}

首先在idea执行，不输入参数 java.system.class.loader 输出结果如下：

null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2

出现这些结果，在我们意料之中，这里不在重复说明，下面使用cmd控制台 执行，添加参数，控制台命令如下：

D:workspace_demojvm-study	argetclasses>java -Djava.system.class.loader=com.lonely.jvmstudy.examples.CustomClassLoader com.lonely.jvmstudy.examples.Test17

输出结果如下：

com.lonely.jvmstudy.examples.CustomClassLoader
sun.misc.Launcher$AppClassLoader@18b4aac2
class com.lonely.jvmstudy.examples.CustomClassLoader

从结果中可以看出，jvm默认的系统类加载器变成了我们指定的自定义系统类加载器了。

4.2 也许有人会问 为什么类Test17(当前类)为什么不是被当前默认的自定义系统类加载器所加载，而是还是被jvm的AppClassLoader所加载？

从源码中，我们可以看到下面这一部分

public ClassLoader run() throws Exception {
    String cls = System.getProperty("java.system.class.loader");
    if (cls == null) {
        return parent;
    }

    Constructor<?> ctor = Class.forName(cls, true, parent)
        .getDeclaredConstructor(new Class<?>[] { ClassLoader.class });
    ClassLoader sys = (ClassLoader) ctor.newInstance(
        new Object[] { parent });
    Thread.currentThread().setContextClassLoader(sys);
    return sys;
}

这里将原来的jvmApp系统类加载器作为了自定义系统类加载的父加载器，即保留了双亲委托的机制，这也是本文章核心，为什么需要添加一个以ClassLoader为参数的构造方法。根据双亲委托机制，加载Test17.class，会首先交于父类AppClassLoader来加载，而类Test17能被AppClassloader加载，所以输出的是AppClassLoader。

5. 也许有人会问，如何验证以上的说法是正确的，如何证明我们自定义的系统类加载器能够使用？

5.1 我们调整一下demo，添加一个加载指定类的操作，代码如下：

package com.lonely.jvmstudy.examples;

/**
 * @author ztkj-hzb
 * @Date 2019/12/26 16:52
 * @Description 分析自定义类加载器，使用参数设置自定义类加载器，分析Launcher源码
  */
public class Test17 {

    public static void main(String[] args) throws ClassNotFoundException {

        //获取指定属性值
  System.out.println(System.getProperty("java.system.class.loader"));

        //输出当前类加载器
  System.out.println(Test17.class.getClassLoader());

        //输出应用类加载器
  System.out.println(ClassLoader.getSystemClassLoader());

        //使用默认系统类加载器加载Test14
  Class<?> aClass = ClassLoader.getSystemClassLoader().loadClass("com.lonely.jvmstudy.examples.Test14");
        System.out.println(aClass.getClassLoader());

    }

}

执行以上代码，结果如下：

null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2

注意：大家可能执行的时候会报错，因为你们的项目中可能没有最后我添加的Test14那个类，所以这里这是参考我的项目
以上结果，因为没有配置参数，所以结果不难获取。

5.2 添加参数 -Djava.system.class.loader=com.lonely.jvmstudy.examples.CustomClassLoader

我们添加参数，再次执行，看看结果

com.lonely.jvmstudy.examples.CustomClassLoader
sun.misc.Launcher$AppClassLoader@18b4aac2
class com.lonely.jvmstudy.examples.CustomClassLoader
sun.misc.Launcher$AppClassLoader@18b4aac2

对比5.1 结果，在获取应用类加载器这里结果有点不同，但是根据4.x模块以及解释了这种情况，这种情况可以表示我们自定义的系统类加载器已经生效。但是由于AppClassLoader类加载器的存在，项目中的业务类都会被它加载，不能很明确的证明我们的自定义类加载器能否正确读取、加载、运行Class对象，下面，就来看我们如何实现它。

5.3 删除项目中Test14编译后的class文件

首先在编辑器中，不配置参数执行程序，得出以下结果：

null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.ClassNotFoundException: Test14
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at com.lonely.jvmstudy.examples.Test17.main(Test17.java:24)

因为Test14.class文件已经被我们删除了，所以使用AppClassLoader来加载Test14根据找不到，所以会提示类找不到异常。这里就能体现出目前使用的是AppClassLoader来加载。

现在，我们配置参数，指定自定义系统类加载器位置，然后将我们的编译后的Test14.class文件放到磁盘 D:comlonelyjvmstudyexamples中，再次执行程序，得到以下结果：

com.lonely.jvmstudy.examples.CustomClassLoader
sun.misc.Launcher$AppClassLoader@18b4aac2
class com.lonely.jvmstudy.examples.CustomClassLoader
findClass..
class com.lonely.jvmstudy.examples.CustomClassLoader

从结果上看，对比上面未删除class之前的结果，可以看出最后Test14类是由我们的自定义系统类加载器加载。

5.4 也许有人会问，为什么路径是这个呢。

1. 首先观察一下我们的自定义类加载器，指定了默认的path路径是 D:/，这是什么意思呢。就是如果我们不指定从哪个路径下找class文件，就使用默认的D:/，这个跟jvm的默认配置路径，例如默认的AppClassLoader是从路径：java.class.path来加载class文件。
2. 那么又有人会问了，那么创建的文件夹应该也是 D:/,那么为什么需要的创建的路径是 D:comlonelyjvmstudyexamples 呢。其实 com.lonely.jvmstudy.examples是我们的类的包路径，因此创建的路径需要带上包路径。
3. 最后，也许还有人会问，那么我们将自定义的类加载器的path字段，设置为带上包名的全路径，在加载的时候，只要写上类名就行了，这样行吗。

现在，稍稍修改一下程序，

1. 修改我们的自定义系统类加载器，将path修改成以下路径：

private String path = "D:/com/lonely/jvmstudy/examples/";

1. 修改我们的测试类，修改Class.forname()方法的路径为如下：

Class<?> aClass = ClassLoader.getSystemClassLoader().loadClass("Test14");

然后带上参数，执行程序，得到以下结果：

Exception in thread "main" java.lang.NoClassDefFoundError: Test14 (wrong name: com/lonely/jvmstudy/examples/Test14)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:642)
    at com.lonely.jvmstudy.examples.CustomClassLoader.findClass(CustomClassLoader.java:71)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at com.lonely.jvmstudy.examples.Test17.main(Test17.java:24)
com.lonely.jvmstudy.examples.CustomClassLoader
sun.misc.Launcher$AppClassLoader@18b4aac2
class com.lonely.jvmstudy.examples.CustomClassLoader
findClass..

事实证明，不行。至于原因，因为该段代是native方法，看不到源码，所以暂时也就这么理解吧。

private native Class<?> defineClass1(String name, byte[] b, int off, int len,ProtectionDomain pd, String source);

最后，由于我也是刚刚接触jvm类加载器，写这篇文章只是为了记下笔记，以后忘记了，还可以看看记录，不喜勿喷，谢谢！