loadClass()负责双亲委派逻辑，是类加载入口；findClass()是子类实现的钩子，仅负责查找字节码并调用defineClass()。重写loadClass()易破坏委派机制，正确做法是只重写findClass()。

ClassLoader 的 loadClass() 和 findClass() 有什么区别？

关键在于职责分离：loadClass() 是类加载的入口，负责双亲委派逻辑；findClass() 是留给子类实现的钩子，只做“找字节码”这件事。

如果你重写 loadClass() 却没调用 super.loadClass()，就等于绕过了双亲委派，容易引发 ClassNotFoundException 或重复定义异常；而正确做法是只重写 findClass()，并在里面用 defineClass() 把 byte[] 转成 Class 对象。

• loadClass("com.example.Foo") 会先委托父加载器，失败后才调用本类的 findClass("com.example.Foo")
• findClass() 必须抛出 ClassNotFoundException，不能返回 null
• 自定义加载器中，defineClass() 的第二个参数（offset）和第三个参数（length）必须匹配实际字节数，否则抛 ClassFormatError

为什么 new MyClassLoader().loadClass("X") 后 newInstance() 会报 IllegalAccessException？

不是访问权限问题，而是类加载器隔离导致的类型不兼容：即使两个 Class 对象名字、字节码完全一样，只要由不同 ClassLoader 实例加载，JVM 就视为不同类型。

典型场景是 Web 容器或 OSGi 中热替换类时，旧类实例还在堆里，新加载的类无法强转为旧类类型。

• 错误写法：

  Class> c = loader1.loadClass("Foo");  
  Object o = c.getDeclaredConstructor().newInstance();  
  Foo f = (Foo) o; // ClassCastException，因为 Foo 是 AppClassLoader 加载的

• 解决思路：避免跨加载器强制转型；改用反射调用方法，或统一使用接口 + SPI 机制解耦
• 注意 Thread.currentThread().getContextClassLoader() 可能和当前类的 getClassLoader() 不同，尤其在框架回调中

URLClassLoader 怎么加载 jar 包里的类？路径写错会怎样？

URLClassLoader 是最常用的可扩展加载器，但它的路径必须是合法 file:// 或 jar:// URL，且 jar 文件需存在、可读、未被占用。

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

常见错误是传入相对路径字符串（如 "lib/my.jar"），它不会自动转成 file: 协议，结果加载时静默失败或抛 IOException。

• 正确构造方式：

  File jarFile = new File("lib/my.jar");  
  URL url = jarFile.toURI().toURL();  
  URLClassLoader cl = new URLClassLoader(new URL[]{url});

• 如果 jar 包里有依赖的其他 jar，URLClassLoader 默认不递归加载，需手动把所有依赖 URL 都加进去
• Windows 下路径含空格会导致 MalformedURLException，必须用 toURI().toURL() 而非 new URL("file://...")

自定义 ClassLoader 时，getResourceAsStream() 返回 null 的原因

这不是类没找到，而是资源查找路径和类路径不一致 —— getResourceAsStream() 搜索的是 classpath，而自定义加载器的 findResource() 默认只查自己加载的类所在位置，不自动代理父加载器。

如果你重写了 findResource() 却没调用 super.findResource()，或者没覆盖 getResources()，就会漏掉 classpath 下的标准资源（比如 META-INF/MANIFEST.MF 或配置文件）。

• 推荐写法：重写 findResource(String name) 时，先尝试从自定义来源加载，失败后再 return super.findResource(name)
• 注意 name 是斜杠分隔的路径（如 "com/example/config.properties"），不含前导 /；带前导 / 会被截掉
• IDE 运行时 classpath 和打包后 jar 内路径行为可能不同，建议用 class.getResourceAsStream("/xxx") 测试真实环境

双亲委派不是语法糖，是 JVM 层硬约束；任何绕过它的操作都会让类的可见性、唯一性和初始化时机变得不可控。真正难的不是写对 defineClass()，而是理清谁该加载什么、什么时候该触发初始化、以及如何让资源和类在多个加载器间协同工作。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南