Java安全——JVM类加载器，2024年最新网络安全屏幕适配很难嘛其实也就那么回事

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

类关系问题第一次遇到还是在分析Shiro反序列化的时候，当时使用Tomcat容器启动的Shiro应用，在具体调试过程中发现WebappClassLoaderBase这个Classloader子类继承了URLClassLoader，一开始对于这种想象是不能够理解的。于是对ClassLoader、URLClassLoader、AppClassLoader等概念产生了混淆，笔者根据之前师傅们的研究总结了他们之间的关系，如下图所示

URLClassLoader是类加载机制双亲委托机制中最靠近子类的父类。ExtClassLoader、AppClassLoader、WebappClassLoaderBase等都继承自URLClassLoader。

public class Mytest{

public static void main(String[] arg){

ClassLoader classloader = Mytest.class.getClassLoader();

System.out.println(classloader);

ClassLoader classloader1 = classloader.getParent();

System.out.println(classloader1);

ClassLoader classloader2 = classloader1.getParent();

System.out.println(classloader2);

}

}

运行结果如下所示，我们可以发现ExtClassLoader的父类加载器为null，原因是BootStrapClassLoader由C实现，无法载Java代码中体现其类之间的关系，但是在实际使用过程中ExtClassLoader确实会委托顶级类加载器BootStrapClassLoader进行类加载，代码实现如下

查看ClassLoader类中的loadClass方法，其中有一块逻辑判断了parent是否为null，如果为null就直接调用findBootstrapClassOrNull方法。

0x2 类方法及属性

在ClassLoader及其子类中有几个比较重要的方法以及属性。ClassLoader中主要实现了loadClass方法，该方法采用双亲委派机制。

public abstract class ClassLoader {

private final ClassLoader parent;

public Class<?> loadClass(String name) throws ClassNotFoundException {}

protected Class<?> findClass(String name) throws ClassNotFoundException {}

protected final Class<?> findLoadedClass(String name) {}

protected final Class<?> defineClass(byte[] b, int off, int len){}

protected final void resolveClass(Class<?> c) {}

}

1.loadClass(String)方法加载指定的类，不建议用户重写

2.findLoadedClass(String) 方法检查这个类是否被加载过

3.findClass(String) 方法用来加载类

4.defineClass(byte[] b,int off,int len)方法是用来将byte字节流解析成JVM能够识别的Class对象

5.resolveClass(Class) 方法用来链接指定的类，主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用

public class URLClassLoader extends SecureClassLoader implements Closeable {

private final URLClassPath ucp;

}

URLClassLoader类中的ucp属性一般存放类加载路径，在双亲委派机制中每一个ClassLoader类都会对应它负责的加载路径。再者比较重要的是ClassLoader类中的关于类加载的方法。

0x03 双亲委派机制

---

双亲委派机制是Java类加载的核心，该机制一定程度的保证了类加载的安全性。简单来讲这个机制就是“当有载入类的需求时，类加载器会先请示父加载器帮忙载入，如果没有父加载器那么就使用BootStrapClassLoader进行加载，如果所有的父加载器都找不到对应的类，那么才由自己依照自己的搜索路径搜索类，如果还是搜索不到，则抛出ClassNotFoundException

0x1 双亲委派结构

在Java JDK中的类加载器结构如下图所示，BootstrapClassLoader为根加载器、ExtClassLoader为扩展类加载器、AppClassLoader为应用类加载器。其结构如下所示，需要注意的是他们这几个类之间的关系为依赖关系，并不是继承关系。

其中User1ClassLoader可以为应用自己设计的类加载器，并设置AppClassLoader为父加载器，这样就可以使用双亲委派机制。

0x2 代码实现

那么关于双亲委派机制代码上的实现也很简单，根据功能描述写对应的if else分支即可。一般在ClassLoader子类中

protected Class<?> loadClass(String name, boolean resolve)

throws ClassNotFoundException

{

synchronized (getClassLoadingLock(name)) {

// First, check if the class has already been loaded

Class<?> c = findLoadedClass(name);

if (c == null) { //判断是否已经加载该类

long t0 = System.nanoTime();

try {

if (parent != null) {//如果有父类，尝试让父类去加载

c = parent.loadClass(name, false);

} else {

c = findBootstrapClassOrNull(name);//如果没有父类，尝试使用根装载器加载

}

} catch (ClassNotFoundException e) { }

if (c == null) {

// If still not found, then invoke findClass in order

// to find the class.

long t1 = System.nanoTime();

c = findClass(name);//这块需要自定义，比如自己写的类装载器就可以在这里实现类装载功能

// this is the defining class loader; record the stats

sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);

sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);

sun.misc.PerfCounter.getFindClasses().increment();

}

}

if (resolve) {

resolveClass©;//链接已经装载的类

}

return c;

}

}

0x04 自定义类加载器

---

同一个类代码如果被不同的类加载器加载，那么在当前JVM中他们是两个不同的类。

0x1 遵循双亲委派机制

1.继承java.lang.ClassLoader

2.重写父类的findClass方法

loadClass方法已经实现了双亲委派功能，如果我们再去覆盖loadClass函数就会破坏双亲委派机制。并且JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，所以我们只需重写该方法即可。

0x2 破坏双亲委派机制

双亲委派机制主要依赖于ClassLoader类中的loadclass函数实现逻辑，如果直接在子类中重写loadClass方法，就可以破坏双亲委派机制。目前存在的一些组件，其类加载机制不符合双亲委派也很正常。那么可能有小伙伴就很迷糊了，到底是要遵守还是要破坏呢？应该根据需求，特殊情况特殊对待，大佬们也总结过几种应用场景，梳理如下

1. Tomcat类加载机制

首先说明双亲委派机制的缺点是，当加载同个jar包不同版本库的时候，该机制无法自动选择需要版本库的jar包。特别是当Tomcat等web容器承载了多个业务之后，不能有效的加载不同版本库。为了解决这个问题，Tomcat放弃了双亲委派模型。

当时分析Shiro反序列化的时候，遇到了Tomcat的类加载器重写了loadClass函数，从而没有严格按照双亲委派机制进行类加载，这样才能实现加载多个相同类，相当于提供了一套隔离机制，为每个web容器提供一个单独的WebAppClassLoader加载器。

Tomcat加载机制简单讲，WebAppClassLoader负责加载本身的目录下的class文件，加载不到时再交给CommonClassLoader加载，这和双亲委派刚好相反。

2. OSGI模块化加载机制

不再是双亲委派的树桩结构，而是网状结构，没有固定的委派模型，只有具体使用某个package或者class时，根据package的导入导出的定义来构造bundle之间的委派和依赖。这块内容也打算单独写，vCenter部署及类加机制很大程度上依赖该技术，这里先挖个坑。

3. JDBC类加载机制

这里双亲委派的缺点是父加载器无法使用子加载器加载需要的类，这个使用场景就在JDBC中出现了。

以往JDBC的核心类在rt.jar中，由根加载器加载，然而现在核心类在不同厂商实现的jar包中，根据类加载机制，如果A类调用B类，则B类由A类的加载器加载，这也就意味着根加载器要加载jar包下的类，很显然这一操作违背了双亲委派机制。

为了让父加载器调用子加载器加载需要的类，JDBC使用了Thread.currentThread().getContextClassLoader()得到线程上下文加载器来加载Driver实现类。

0x3 加载加密字节码

为了更深入的了解ClassLoader的工作流程，打算自己写一个加载Class密文件。首先编写加解密函数，将编译好的class文件通过encryptfile函数加密。

package myclassloadertest;

import javax.crypto.Cipher;

import javax.crypto.spec.IvParameterSpec;

import javax.crypto.spec.SecretKeySpec;

import java.io.*;

public class FileUtils {

private static final int ZERO = 0;

private static final int ONE = 1;

private static String derectory ;

private static String key = “aaaabbbbccccdddd”;

private static String ivParameter = “AAAABBBBCCCCDDDD”;

public FileUtils (String path){

derectory = path;

}

public static byte[] doFile(int code, File file, String key, String ivParameterm, String filename) throws Exception {

BufferedInputStream bis = new BufferedInputStream(new FileInputStream(

file));

byte[] bytIn = new byte[(int) file.length()];

bis.read(bytIn);

bis.close();

byte[] raw = key.getBytes(“ASCII”);

SecretKeySpec skeySpec = new SecretKeySpec(raw, “AES”);

Cipher cipher = Cipher.getInstance(“AES/CBC/PKCS5Padding”);

IvParameterSpec iv = new IvParameterSpec(ivParameterm.getBytes());

if (0 == code) {

cipher.init(Cipher.ENCRYPT_MODE, skeySpec, iv);

} else if (1 == code) {

cipher.init(Cipher.DECRYPT_MODE, skeySpec, iv);

}

byte[] bytOut = cipher.doFinal(bytIn);

File outfile = new File(derectory + “/” + filename);

BufferedOutputStream bos = new BufferedOutputStream(

new FileOutputStream(outfile));

bos.write(bytOut);

bos.close();

return bytOut;

}

public static void encryptfile(File file, String key, String ivParameter, String filename) throws Exception {

doFile(ZERO, file, key, ivParameter, filename);

}

public static byte[] decryptfile(File file, String key, String ivParameter, String filename) throws Exception {

return doFile(ONE, file, key, ivParameter, filename);

}

public static byte[] loadfile(String name) throws Exception {

File file = new File(derectory + name.replace(‘.’, ‘/’) + “.class”);

return decryptfile(file, key, ivParameter, “decrypt_tmp_file”);

}

public static void main(String[] args) {

try {

File file = new File(derectory + “myclassloadertest/Test.class”);

String fileName = “myclassloadertest/TestCrypt.class”;

给大家的福利

零基础入门

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

因篇幅有限，仅展示部分资料

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

g.csdnimg.cn/img_convert/95608e9062782d28f4f04f821405d99a.png)

同时每个成长路线对应的板块都有配套的视频提供：

因篇幅有限，仅展示部分资料

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）
[外链图片转存中…(img-f60Yia3d-1713335673834)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！