不算。同一个类名被不同类加载器加载后，JVM视为两个无关类，因类身份由“类名+类加载器”共同决定；导致类型不兼容、ClassCastException等典型问题。
同一个类名被不同类加载器加载后，算不算同一个类？
不算。哪怕 com.example.User 的字节码完全一样、包名类名全对，只要由不同的 ClassLoader 实例加载，JVM 就认为它们是两个完全无关的类 —— 类型不兼容、无法强转、instanceof 返回 false，连 Class.equals() 都是 false。
这是 JVM 类型系统的底层规则：类的“身份”由 类名 + 类加载器 共同决定，缺一不可。很多 NPE 或 ClassCastException 的根源就在这儿。
- 常见错误现象：
java.lang.ClassCastException: com.example.User cannot be cast to com.example.User—— 看似荒谬，实则典型 - 典型场景：OSGi 插件、Spring Boot 的 devtools 热替换、自定义
URLClassLoader加载 jar 包时反复 new 实例 - 关键点：
ClassLoader实例本身是命名空间边界，不是类路径或 jar 文件
双亲委派被绕过时，为什么容易触发类冲突？
双亲委派机制默认让子加载器先委托父加载器尝试加载，保证核心类（如 java.lang.String）唯一且可信。一旦绕过（比如重写 loadClass() 并去掉 super.loadClass() 调用），子加载器就可能重复加载父已加载过的类，造成命名空间污染。
这时候 JVM 不报错，但运行时行为不可控：静态字段不共享、初始化顺序混乱、getClassLoader() 返回不一致。
立即学习“Java免费学习笔记（深入）”；
- 容易踩的坑：在自定义
ClassLoader中直接调用defineClass()而不查缓存、不委派，尤其加载javax.*或org.springframework.*这类跨模块依赖的类 - 参数差异：
findClass(String name)是安全扩展点；而直接重写loadClass(String name, boolean resolve)且忽略委派逻辑，风险极高 - 性能影响：绕过委派会导致重复解析、校验、链接，还可能触发多次
<clinit></clinit>执行
如何判断两个 Class 对象是否来自同一命名空间？
最直接的方式是比对它们的类加载器引用是否相等，而不是看类名或字节码内容：
if (obj1.getClass().getClassLoader() == obj2.getClass().getClassLoader()) {
// 在同一命名空间
}
注意不能用 equals() 比较加载器，因为有些框架（如 Tomcat）会重写 equals()，但 JVM 内部只认引用相等。
- 调试技巧：打印
obj.getClass().getClassLoader()和obj.getClass().getName()，一起看才有效 - 兼容性影响：JDK 9+ 的模块系统进一步强化了这种隔离，
ModuleLayer和Module也会参与类型可见性控制 - 别依赖
Class.getCanonicalName()或toString()判断——它们不体现加载器信息
Web 应用里为什么 WebAppClassLoader 和 AppClassLoader 加载的同名类不能互通？
Tomcat 等容器为每个 webapp 创建独立的 WebAppClassLoader 实例，并将其作为该应用的顶层加载器（打破双亲委派，优先本地加载）。它和 JVM 启动时的 AppClassLoader 属于不同实例，天然形成隔离。
这意味着：放在 WEB-INF/lib 里的 fastjson-1.2.83.jar 和放在 $JAVA_HOME/jre/lib/ext 里的同版本 jar，即使类完全一样，也属于两个命名空间。
- 典型问题：SPI 服务（如
java.sql.Driver）被多个 classloader 注册，导致DriverManager查不到或重复加载 - 解决思路：把共享依赖提到容器级（
lib/目录），并确保 webapp 的web.xml或context.xml中配置loaderDelegate="true"（慎用） - 容易被忽略的地方：线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）常被框架切换，它不等于当前类的getClassLoader()
