system类不提供获取类加载器的方法，所有类加载器获取操作均由classloader类承担：1. classloader.getsystemclassloader()获取系统类加载器；2. class.getclassloader()返回加载该类的类加载器；3. thread.currentthread().getcontextclassloader()获取当前线程上下文类加载器。
System 类本身不提供直接获取类加载器的方法。Java 中获取类加载器的操作，全部由 ClassLoader 类及其静态/实例方法承担，System 类仅负责系统级基础功能（如标准输入输出、属性管理、时间戳等），不参与类加载机制。
真正可用的类加载器获取入口都在 ClassLoader 类中
以下是实际有效且常用的方式，全部来自 ClassLoader 类或与之强关联的上下文：
-
ClassLoader.getSystemClassLoader()：获取系统类加载器（即应用类加载器，AppClassLoader），它是默认加载应用程序类的加载器，也是自定义类加载器未指定父加载器时的默认父级。 -
Class.getClassLoader()：通过任意已加载的类（如String.class或YourClass.class）调用该方法，返回加载该类的实际类加载器；注意：String.class.getClassLoader()返回null，因为启动类加载器（Bootstrap）由 JVM 本地代码实现，Java 层不可见。 -
Thread.currentThread().getContextClassLoader()：获取当前线程的上下文类加载器，常用于框架（如 Tomcat、Spring）中打破双亲委派，实现插件或模块隔离；该值可被用户显式设置，不一定等于系统类加载器。
为什么 System 类没有相关方法？
这是设计上的明确分工：
- 类加载属于 JVM 运行时子系统的核心行为，由
ClassLoader及其子类（如AppClassLoader、URLClassLoader）统一建模和实现； -
System类定位是“系统资源桥梁”，只暴露in/out/err、currentTimeMillis()、getProperties()等底层能力，不介入类生命周期管理； - 所有类加载器的创建、委托、资源查找逻辑都封装在
ClassLoader抽象类中，包括getResource()、getResources()、getParent()等关键方法。
典型使用场景参考
比如加载配置文件或动态类，常见写法都是基于 ClassLoader 实例，而非 System：
- 读取 classpath 下的
config.properties：ClassLoader.getSystemClassLoader().getResource("config.properties") - 加载运行时字节码：
MyClassLoader cl = new MyClassLoader(); cl.loadClass("com.example.DynamicClass"); - 确保跨模块资源可见（尤其在容器环境）：
Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/MANIFEST.MF")
简言之，想查类加载器，就找 ClassLoader —— 它是唯一权威入口，System 类里没有、也不该有这类方法。
