深入理解JVM类加载机制：从NoClassDefFoundError到双亲委派

从一次 NoClassDefFoundError 开始。应用明明在前一天还跑得好好的，改了配置重新部署后，一启动就报错，而且错误栈只出现在某个模块初始化的时候。我盯着堆栈看了半天，找不到任何业务代码的问题，最后用 -verbose:class 拉日志才定位到：同一个 org.apache.commons.logging.LogFactory 类被两个不同的类加载器各加载了一遍，其中一个加载到的版本和依赖树里另一个版本冲突了。那是我第一次意识到，JVM 类加载机制不只是面试题里“双亲委派模型”那几句话，它在线上是真的会要命的。

如果你也在维护微服务、做中间件开发，或者只是被各种 ClassNotFound、NoClassDefFound 折腾到怀疑人生，这篇文章值得往下看。我会把类加载机制讲成一个“可以复用的排查经验”，而不是从八股文里摘出来的概念。

1. 一个类到底是怎么“落到”JVM里的：加载流程中的两个关键岔路口

很多 Java 开发者对类加载的理解停留在“把 .class 文件读进内存”这一步。实际上，从字节码变成可以直接 new 的对象，中间有加载、验证、准备、解析、初始化五个阶段。类加载机制里常说的“加载”，只是这五个阶段里的第一步，而且真正复杂的逻辑发生在后面几个阶段。

1.1 加载阶段不是简单地读文件

加载阶段做的事，可以概括为三步：

1. 通过类的全限定名获取定义此类的二进制字节流；
2. 把字节流中静态存储结构转换为方法区的运行时数据结构；
3. 在堆中生成一个代表该类的 java.lang.Class 对象，作为方法区这个类各种数据的访问入口。

过去大家默认“二进制字节流”就是从 class 文件来的，实际上你可以从任意地方获得：ZIP 包、网络流、动态代理运行时生成的字节码、数据库里读出来的 byte[]、甚至用加密算法算出来的。这一点是后面所有“自定义类加载器”“打破双亲委派”的技术基础。如果你一开始就把加载等同于“读文件”，后面理解 SPI 和热部署一定会卡壳。

加载之后的验证阶段容易被忽略，但线上遇到问题时它却是关键。验证阶段会检查字节码流是否符合 ClassFile 规范、是否违反安全约束、符号引用能否被正确解析等。所以当你看到一个 VerifyError 或者 IncompatibleClassChangeError 时，通常不是类找不到，而是被加载到的类版本、父类签名、接口方法和当前代码期望的不一致。这个在排查依赖冲突时非常常见，我后面会专门讲。

1.2 初始化阶段：什么时候触发，最容易和你预想不一样

加载、验证、准备阶段都完成后，类才进入初始化阶段——执行 clinit 方法。这一步很重要，但很多人并不清楚触发时机。JVM 规范里明确了几种会立即触发类初始化的场景：

• 遇到 new、getstatic、putstatic、invokestatic 字节码指令，且目标类未被初始化；
• 对类进行反射调用；
• 初始化某个类时，发现其父类还没初始化；
• 启动虚拟机时，含有 main 方法的那个类；
• JDK 8 开始支持的 MethodHandle 与 VarHandle 相关调用。

这里有一个经典的天坑：通过子类引用父类的静态字段，不会触发子类的初始化。我见过有人把数据库驱动的注册语句写在类 B 的静态块里，然后用类 A 的静态字段初始化时误以为 B 会被初始化，结果驱动没有注册，运行到一半才暴露问题。这个不是类加载器的问题，而是对初始化时机理解不完整。排查任何类加载相关异常时，先确认这个类是否真正执行了初始化，比直接抓加载来源更重要。

类加载过程中，真正决定“谁来加载”的部分发生在加载阶段的第一步。这里引入了一个关键概念：类加载器。

1.3 三个内置类加载器，维护着一条隐形的“信任链”

JVM 自带的类加载器从顶层到底层分为三个：

在 JDK 8 中叫 Extension，JDK 9 模块化后改成了 Platform，但你只需要记住它们的核心区别：越底层的加载器，越只加载可信的核心库和扩展库；你自己写的大部分类，默认都由 Application ClassLoader 加载。

这三个类加载器之间的父子关系不是通过继承得到的，而是通过组合关系持有 parent 字段。这直接决定了双亲委派模型里“向上委托”的操作路径。

我一直建议团队新人把类加载器想象成公司里的审批流：你自己不能拍板的事，先报给上级，上级不能拍板再往上报。到了最高层还处理不了，才把单子打回给你。这种“先向上请示，再自己兜底”的顺序，就是双亲委派的运行逻辑。所谓的“双亲”，其实只是指“父加载器”。

2. 双亲委派究竟在防什么？用三个案例看清它的利益与代价

双亲委派模型的核心工作流程，官方定义只有一句话：如果一个类加载器收到了类加载请求，它首先不会自己尝试去加载这个类，而是把这个请求委派给父类加载器完成；只有当父类加载器反馈自己无法完成请求时，子加载器才会尝试自己加载。

一句话概括就是：子加载器不给力，才轮到父加载器？不对，反了——是先让父加载器做，父做不了，子才做。

2.1 为什么“先让父加载器做”是更安全的方案

JDK 1.2 开始引入双亲委派模型，核心目标不是性能，而是安全。它同时保证了两个东西：

第一，避免了核心类被覆盖。假设你没有双亲委派模型，应用代码里自己写了一个 java.lang.String，并且被 Application ClassLoader 加载了，那整个 JVM 里的字符串行为就会变得不可控。有了双亲委派，你的 java.lang.String 请求会被委派到 Bootstrap ClassLoader，然后引导类加载器发现 rt.jar 里已经有对应类，直接返回核心库的 String，你写在 classpath 下的那个冒牌货永远没机会出场。

第二，避免同一个类在不同类加载器里被重复加载，进而造成类型分裂。JVM 判断两个类是否相同的条件不是“全限定名相同”，而是“全限定名相同且由同一个类加载器加载”。如果同一个 com.foo.Bar 被两个不同类加载器各自加载，它们会被认为是两个完全不同的类型。即使其字节码完全一致，在运行时也不能互相强转，instanceof 判断也会返回 false。

这里顺带可以解释一个高频问题：为什么自定义类加载器时，要先调用 super.loadClass 而不是直接重写 findClass？因为 ClassLoader.loadClass() 方法里本身就内置了双亲委派的流程。你重写 loadClass，相当于改变了整条审批流；你只改 findClass，只是改变了父加载器失败后“自己怎么兜底”的逻辑。

2.2 一个典型的安全收益案例：防止类库被“钓鱼”

这里说一个我印象深刻的场景。某次排查一个安全扫描问题，发现 classpath 里真的存在一个伪造的 javax.management.MBeanServer 类。因为双亲委派的存在，这个类永远不可能被 Application ClassLoader 加载，所有请求都会被委派给 Bootstrap ClassLoader，加载原生的 JDK 类。安全扫描误报是这个机制的一个附带价值。

但如果某个框架非要自己写一个 javax.sql.DataSource 的实现类，那就要小心了。应用类加载器加载时发现父级没有 javax.sql.DataSource 的实现吗？事实上接口本身在核心库里，父加载器能够加载接口，但接口不是具体类。当你的 DataSource 实现类被委派到父加载器时，由于核心库里没有这个具体类，加载失败，才会回到应用类加载器自己加载。这个过程符合双亲委派，没有问题。

所以，真正的安全边界不是“不允许加载同名类”，而是“不允许绕过父加载器去加载同名类”。只要你违反了这个规则，类屏蔽和类型分裂的风险就会出现。

2.3 双亲委派模型并没有对 SPI 场景做妥协

你以为只有自己写代码时才能“打破”双亲委派？其实 JDK 自身就有一个非常著名的“被迫打破”例子：SPI（Service Provider Interface）。

回想 JDBC 的经典用法。java.sql.DriverManager 由 Bootstrap ClassLoader 加载，而数据库驱动实现类（比如 MySQL 的 com.mysql.cj.jdbc.Driver）是第三方 jar 里的，通常由应用类加载器加载。按双亲委派的逻辑，当 DriverManager 里要加载某个具体驱动类时，请求会先委托给 Bootstrap ClassLoader，引导类加载器显然找不到这个第三方类，加载失败。然后呢？如果严格走双亲委派，应用类加载器才有机会加载驱动类，但问题是：发起加载请求的人是引导类加载器加载的 DriverManager，它的“主子”是 Bootstrap ClassLoader，它并没有主动请求“子加载器”去加载外部类的能力。

为了绕开这个死结，JDK 引入了线程上下文类加载器（Thread Context ClassLoader）。DriverManager 在初始化时，通过 Thread.currentThread().getContextClassLoader() 拿到当前线程的上下文类加载器——这通常是应用类加载器——然后用它去加载具体的驱动类。整个流程相当于：父加载器发现自己搞不定，主动翻转了委派方向，让子加载器来干活。这就是“打破双亲委派”的第一种经典姿势，不是通过重写 loadClass 来破坏父优先逻辑，而是通过线程上下文临时切换加载器身份。

类似的场景包括：

• JDNI 的服务提供方（比如 jndi.properties 里指定的类）
• JAXP、XML 解析器的 FactoryFinder
• Servlet 容器里的很多扩展机制

这些接口类位于 JDK 核心库，负责加载接口的类加载器（Bootstrap）不可能依赖外部的 jar。为了做到可插拔，只能交出加载动作的控制权，让“调用线程”来决定用哪个类加载器。

每次有面试新人问我“双亲委派被破坏了吗？”，我都会反问一句：你说的“破坏”是指重写 loadClass 改变委派顺序，还是指某些场景用线程上下文绕过父加载器默认的委托方向？这两种在实现机制上完全不同，实际代码里大部分人遇到的是第二种，但并不代表他们把类加载器给改了。

3. 不得不打破双亲委派的三种场景：SPI、Web 容器和热部署的做法

这一节给代码例子。我们要搞清楚“破坏”到底是什么动作，不同场景下手段不同，但目标一致：让正确的类加载器在正确的时机去加载某个类。

3.1 场景一：JDBC 驱动通过 loadClass 注册？容易翻车

最原始的 JDBC 写法是：

java复制Class.forName("com.mysql.cj.jdbc.Driver");

这段代码本身没有错，但它容易让人误解成“是我们手动触发了驱动类的注册”。实际上驱动类里有一个静态块，会在类初始化时自动向 DriverManager 注册自己。如果你忘记了 Class.forName，驱动类不会被初始化，后面拿连接时自然报 No suitable driver。

但你真的在 Servlet 容器或者复杂的类加载环境下，上面的 Class.forName 使用的是调用者当前的类加载器。如果当前类的加载器是 Web 应用类加载器，而 DriverManager 的类加载器是 Bootstrap，它们之间看到的驱动类并不是同一个类型，虽然注册进去了，但 DriverManager 拿到的驱动类型可能不对，连接依然失败。因此许多框架和规范建议使用线程上下文类加载器来加载 SPI 实现类：

java复制ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
    classLoader = DriverManager.class.getClassLoader();
}
Class<?> driverClass = classLoader.loadClass("com.mysql.cj.jdbc.Driver");

如果 Java 服务里遇到数据库驱动加载失败，第一反应不要老是去看依赖有没有，先确认一下线程上下文类加载器和实际驱动所在的类加载器是不是一致。

3.2 场景二：Tomcat 的 WebAppClassLoader 是更彻底的破坏者

Tomcat 为了做到“隔离各个 Web 应用”，设计了多个 WebAppClassLoader，每个负责加载各自 WEB-INF/classes 和 WEB-INF/lib 下的类。Tomcat 的类加载顺序并不是严格的双亲委派：

1. 先从 JVM 的 Bootstrap 类加载器加载；
2. 如果没有，再从 System 类加载器加载；
3. 如果还没有，在 WebAppClassLoader 自己的缓存里找；
4. 再按 WEB-INF/classes、WEB-INF/lib 的顺序加载；
5. 最后才委派给父加载器。

注意这个顺序里面有一层“自底向上”的意味：Web 应用自身的类优先被 WebAppClassLoader 加载，而不是像标准双亲委派那样先让父加载器尝试，父加载器加载不到才轮到自己。

这样做的原因很简单。同一个 com.example.UserService 在应用 A 里可能是 2.0 版本，在应用 B 里可能是 3.0 版本。如果按标准双亲委派，谁先加载谁后加载会影响另一个应用的逻辑。如果都让共享的父加载器加载，两个 Web 应用就必须使用同一版本的类库，完全做不到彼此隔离。为了依赖隔离和版本互不干扰，它必须打破双亲委派。

Tomcat 最早版本还专门考虑了 SPI 类加载的问题。应用自己加载出来的驱动/类，在需要被 Tomcat 内部访问时，必须通过线程上下文类加载器转换。这就导致在许多容器环境中，正确设置 Thread.currentThread().setContextClassLoader(...) 是中间件能工作的前提。

3.3 场景三：热部署和热替换通过轮换类加载器实现“换血”

另一个会打破双亲委派的场景是热部署。这里我们说的不是 IDEA 的 JRebel 那种花大量时间讨论字节码增强的方案，而是早期许多框架使用的“每次部署新版本就新建一个类加载器来加载新类”的做法。

核心思路如下：每次你要部署一个新版本，就放弃旧的类加载器，创建一个新的类加载器实例去加载新 classpath 下的类。由于旧对象仍然引用旧类加载器，如果旧类加载器不被回收，元空间就会持续膨胀；如果 JVM 能回收掉旧的类加载器，以及它加载的所有类，那下一次请求创建新对象时，用的就会是全新加载的类。

这种方式的破坏点在于：类加载器不再遵循“父优先”，因为我们必须保证新版本代码不被父加载器里的旧版本类抢先加载。解决方案通常是：自定义类加载器里的 loadClass 方法在查找本地路径之前不委派给父加载器；也就是说，直接重写 loadClass，让它“先自己找，找不到才找父亲”。

一个最简化的热部署类加载器骨架：

java复制public class HotSwapClassLoader extends ClassLoader {

    private final Map<String, String> classPathMap;

    public HotSwapClassLoader(Map<String, String> classPathMap) {
        super(getSystemClassLoader());
        this.classPathMap = classPathMap;
    }

    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // 先尝试自定义加载
        synchronized (getClassLoadingLock(name)) {
            Class<?> loadedClass = findLoadedClass(name);
            if (loadedClass == null) {
                try {
                    loadedClass = findClass(name);
                } catch (ClassNotFoundException e) {
                    // ignore, 交给父加载器
                }
            }
            if (loadedClass == null && getParent() != null) {
                loadedClass = super.loadClass(name, false);
            }
            if (resolve) {
                resolveClass(loadedClass);
            }
            return loadedClass;
        }
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        String filePath = classPathMap.get(name);
        if (filePath == null) {
            throw new ClassNotFoundException(name);
        }
        // 读取字节码文件并调用 defineClass
        ...
    }
}

这段代码里有几个设计细节值得反复推敲：

• 为什么 loadClass 加锁？因为 ClassLoader 内部有一个 getClassLoadingLock，用来保证同一个类在同一时刻只有一个加载线程。如果你不做同步，多个线程同时触发同一个类的加载，轻则多加载几次浪费时间，重则导致不同线程拿到不同版本的 Class 对象。
• 为什么先尝试 findClass 而不是先查 parent？因为热部署的核心诉求就是“绕过本地缓存，强制加载最新目录下的字节码”。如果不重写 loadClass，只重写 findClass，父加载器一旦加载过旧版本，你永远没有机会加载新版本。
• 为什么最后还有 super.loadClass？因为像 java.lang 这些基础类必须由 Bootstrap 加载，不交给父级会引发安全问题和“类无法转换”等异常。

所以“打破”不是全盘推翻，只是有选择地改变委派顺序，在必要的边界上才绕过父亲。

4. 类加载异常排查：先分清三种报错，再用工具还原真相

网上讲双亲委派模型的文章很多，但讲怎么排查类加载问题的偏少。这节把我的排查思路完整分享出来。

4.1 三种报错：看起来像兄弟，病因完全不同

很多人把 NoClassDefFoundError 和 ClassNotFoundException 混为一谈，其实它们有明确区别。ClassNotFoundException 更像“你去仓库查货，发现压根没这个 SKU”；NoClassDefFoundError 更像是“系统里记录过有这个东西，但你要真正领用时，那个货已经没了”。

举一个很现实的例子：

java复制class A {
  private Helper helper = new Helper();
}

class Helper {
  static { int i = 1 / 0; } 
}

JVM 加载 A 时一切正常，于是把 A 归入“已加载”状态队列；等你初始化 A，才去引用 Helper，发现 Helper 初始化抛异常。之后 JVM 对 A 的某个方法调用就可能报 NoClassDefFoundError，报错信息指向前面的类——即使真正的根因是 Helper 的静态初始化抛了 ExceptionInInitializerError。所以排查 NoClassDefFoundError 时候一定要往前翻堆栈，经常能找到“初始失败”的隐藏原因。

4.2 用 -verbose:class 还原加载顺序

如果你在本地或测试环境能复现问题，最简单的方法是添加参数启动 JVM：

bash复制java -verbose:class -jar your-app.jar

这条命令会把每个类是从哪个 jar 加载的、由哪个类加载器加载的、是否触发了加载动作等关键信息完整打出来。例如：

code复制[Loaded java.lang.String from /usr/lib/jvm/jdk-11/lib/modules]
[Loaded com.example.BizService from file:/opt/app/lib/biz.jar]

当看到同一个全限定名出现了两次时，就要高度警惕，它可能被两个不同类加载器加载了；或者是同一个类加载器先加载了 A.jar 里的版本，又加载了 B.jar 里的版本，这样会导致 NoSuchMethodError 或字段定义不一致。

注意 -verbose:class 需要在你怀疑的类被加载前打开，如果在启动阶段就报了错，那就是最好的时机。如果应用已经运行了几十分钟，日志量会非常大，需要配合 grep 过滤自己要找的类名，比如：

bash复制java -verbose:class -jar yourapp.jar 2>&1 | grep com.example.Driver

4.3 用 Arthas 在已运行实例里查类加载器

线上不能重启时，我一般用 Arthas 做现场排查。它有几个命令和类加载强相关：

• classloader：列出所有类加载器、层级关系、加载的类数量；
• sc -d com.example.BizService：查看某个类的类加载器、jar 包来源；
• dump：把类的字节码 dump 出来，便于直观比较两个版本。

有次我们线上容器里出现两个版本的 com.fasterxml.jackson.databind.ObjectMapper，一个来自 Spring Boot 内嵌的 fat jar，一个来自某个业务模块自定义加载的第三方类库。通过 classloader 命令看到两个不同加载器都持有同名类，再用 sc -d 查它们的 jar 来源，最终锁定了某个模块用了“自研类加载器去加载 Spring 的依赖”，导致 ObjectMapper 类型分裂，各种强转失败。

Java 类型是否相等的判断标准：类全限定名 + 定义类加载器。 这是所有类型分裂问题的理论根源。如果你在排查中遇到“可以正常 new，但强转会 ClassCastException，或者反射访问时找不到方法”的现象，第一反应应该是检查参与方两边是不是同一类加载器。

4.4 实战案例：一次“构建失败引发类加载器疑问”的复盘

这里我想借助一个不同形态的例子：Gradle 构建时报错，比如类似热词中看到的“gradle version 6.7.1 is incompatible with the gradle jvm version”。这本质上不是双亲委派问题，但它也涉及 JVM 参数与构建工具运行时的关系，容易让人误判。

事情是这样的：有同学升级了 JDK 17，项目里的 Gradle 还是 6.7.1，运行 ./gradlew build 直接报版本不兼容。他百思不得其解：Java 代码本身是 8 写的，怎么构建就过不去？其实 Gradle 自身运行在独立的 JVM 里，JAVA_HOME 指向的 JDK 版本决定了 Gradle 的启动类加载器和模块系统能识别哪些 class。此时报错不是类加载问题，而是 Gradle 启动器在解析自身字节码时发现模块系统限制。

但换一个角度，这个案例对理解类加载依然有启发：构建工具用的 JVM、运行测试用的 JVM、最终应用部署用的 JVM 可能互相隔离。排查线上类加载问题时，不要只盯着应用服务器本身的 JVM 参数，也要确认启动脚本里 JAVA_HOME、JACARD_OPTS 等是否把同一个类路径覆盖成了不同版本。比如 Docker 容器里只改了基础镜像，从 JDK 8 换到 JDK 11，而脚本里还保留着指向 $JAVA_HOME/lib/tools.jar 的 classpath，启动时 tools.jar 根本不存在，直接导致 ClassNotFoundException，报错看起来像是 jar 缺失，其实是 JDK 模块化后路径变了。

5. 自定义类加载器避坑清单：从上下文切换到元空间泄漏

最后分享一些我多年踩坑后总结出来的实操原则，如果不是特别必要，不要轻易打破双亲委派。一旦你真的需要自定义类加载器，这几点会频繁救你命。

5.1 设置线程上下文类加载器的正确姿势

很多人只知道在代码里做下面的切换：

java复制ClassLoader original = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(targetClassLoader);
    // 业务操作
} finally {
    Thread.currentThread().setContextClassLoader(original);
}

这个模式正确，但有几个细节需要注意：

• 如果当前线程是 JVM 内部线程，getContextClassLoader() 可能返回 null。在使用前要判空。
• 切换范围一定要用 try-finally 包住，否则后续框架代码会拿着错误的加载器去加载其他类，导致非常诡异的问题。
• 在异步任务线程池中执行时，任务内部设置的线程上下文只对当前任务有效，一旦任务结束线程返回池中，线程的上下文类加载器不会自动恢复，所以必须在任务方法内做 restore。我见过不止一次因为在线程池里执行任务后没有 restore，导致下一个任务继承了一个来自 Web 应用类加载器的上下文，最终加载到错误版本的类。

5.2 从“类加载器泄漏”到元空间 OOM

自定义类加载器最大的坑是类加载器无法回收。类加载器之间是父子引用关系，而业务对象往往持有 Class 对象的引用，Class 对象又持有类加载器引用。如果有一个全局静态集合缓存了某个业务对象，这个对象的类加载器以及它加载的所有类都不会被 GC。当热部署或者频繁创建新类加载器时，元空间不断增长，最终 java.lang.OutOfMemoryError: Metaspace。

排查这个问题的核心是找到谁持有了旧类加载器。最常用的工具是 jmap -clstats <pid> 打印类加载器统计信息，看哪些类加载器的存活类数量异常多。再配合 jcmd GC.class_histogram 或 MAT 分析堆转储，找到持有 Class 对象的根路径。一般线索都指向某个静态集合、ThreadLocal、连接池，或第三方缓存。

我自己的准则是：自定义类加载器要么在一个进程里只创建一次并长期复用，要么确保每个新加载器都被尽快释放。尽量不要在一次请求里动态创建新的类加载器，这是一个灾难的起点。

5.3 “先本地后父级”的加载顺序会破坏哪些 JDK 约束

有些框架为了加载隔离，会把加载顺序写成“先加载本地路径的类，找不到再由父加载器加载”。这样快捷，但代价是连 java.lang 开头的类也会先尝试本地加载。你可以写一个与 java.lang.String 全名相同的类，通过本地文件加载，但 JVM 会直接抛出 SecurityException: Prohibited package name: java.lang。所以，即使打破了委派顺序，也要明确先过滤掉 java.*、javax.* 等核心包，至少安全校验依然有效。

真正的隔离应该限定在应用类范围，核心类库和系统类库永远不应该交给应用层类加载器负责。否则你打破的不只是双亲委派，还把 JVM 本身的结构稳定性也打破了。

5.4 面到“同包类”互访时会遇到的隐性问题

打破双亲委派后，还会出现一个很隐蔽的问题：如果两个类在同一个包下，且它们由不同类加载器加载，那么包级别的可见性和访问控制会被破坏。例如 java.base/java.lang 和某个自定义加载器也有一个 java.lang 包，虽然类加载器阻止了你冒充真的 String，但当你在同一个包内依赖包级私有成员时，可能因为类加载器不同而完全访问失败。

Java 的包作用域判断维度不是“包名相同即可”，而是“包名相同 + 类加载器相同”。因此自定义加载器隔离类库时，要留意跨加载器的包间调用是否正常，常见于反射场景或序列化框架中。

以上这些坑，无论你在做 OSGi、SPI 扩展点、还是简单的热部署插件，都会大概率遇到。它们不是靠记概念能避开的，要有意识地通过日志、Arthas、jmap 等工具把类加载现场还原出来。否则下一次 NoClassDefFoundError 依然会让你在深夜怀疑人生。