Lazy解析按需触发，首次访问才解析符号，加快类加载启动但有运行时延迟；Eager解析在类加载阶段一次性完成全部符号解析，启动慢但运行期无抖动、利于JIT优化。
符号解析发生在类加载的“解析”阶段，是将常量池中的符号引用（如类名、字段名、方法名）转换为直接引用（内存地址或句柄）的过程。这个阶段的执行时机，直接受限于后续是否真正用到该符号——而 Lazy 与 Eager 解析，正是对这一“是否提前处理”的不同策略选择。
Lazy 解析：按需触发，推迟到首次使用
Lazy 解析不急于在类加载初期就完成全部符号解析，而是等到某段代码**第一次主动访问某个类、字段或方法时**，才去解析对应符号。例如：
- 调用一个未解析过的方法时，JVM 才去解析其方法符号；
- 首次读取某个静态字段，才解析该字段的符号引用；
- 子类首次初始化时，才解析父类中尚未解析的符号（若之前未触发过）。
这种策略减少了类加载初期的计算负担，加快了类加载启动速度，尤其适合大型应用中存在大量未被实际使用的类或 API 的场景。但代价是：首次访问时可能有微小延迟，且若多个线程并发首次访问不同符号，可能带来轻微同步开销。
Eager 解析：类加载时一并完成
Eager 解析要求在类加载的解析阶段，就将常量池中所有能解析的符号引用尽可能转为直接引用。这包括：
- 所有已知的类、接口、字段、方法；
- 即使这些成员在当前阶段完全不会被调用；
- 部分 JVM 实现还会预解析继承链和接口实现关系。
结果是类加载过程更重、更慢，尤其在含大量依赖或反射调用的类中（比如 Spring Bean 定义类、HarmonyOS 中 import * 大量模块的类）。但好处是运行期更“干净”——后续任意访问都不再触发解析动作，避免了运行时抖动，也利于 JIT 编译器做更激进的优化。
对变量类加载速度的实际影响
变量本身不触发符号解析，但变量的声明类型、初始化表达式、所在类的静态块或构造逻辑，会牵涉到类、字段、方法的符号引用。因此影响体现在三方面：
-
静态变量：若其类型是尚未加载的类（如
static MyClass obj;），Eager 解析会立即尝试加载并解析MyClass；Lazy 则等到真正赋值或访问obj时才触发； -
实例变量：其类型解析通常延迟到该类实例化时（属于类初始化阶段），但若变量初始化语句含方法调用（如
int x = helper.getValue();），Eager 解析会提前解析helper.getValue符号； -
import 或 module 引用：像 HarmonyOS 中大量使用
import *，会强制 JVM 在解析阶段扫描并尝试解析所有导出项的符号，显著拖慢 Instantiate 阶段——这本质就是 Eager 解析倾向带来的开销。
实测显示，在资源密集型前端框架或鸿蒙应用中，将关键模块的导入从 import * 改为按需 import { A, B }，可减少 30% 以上的类解析耗时，因为编译器能剔除未引用的符号，JVM 也就无需解析它们。
如何判断当前环境采用哪种解析策略
JVM 默认采用混合策略：对类和接口的符号引用多为 Lazy 解析；但对某些核心类（如 java.lang.*）或启用 -XX:+EagerJVMCI 等参数时，会增强 Eager 行为。可通过以下方式观察：
- 添加
-XX:+TraceClassLoading和-XX:+PrintGCDetails，查看类加载日志中解析动作是否集中发生； - 用 JFR（Java Flight Recorder）录制启动过程，筛选 “vm.class.resolve” 事件的时间分布；
- 在 HarmonyOS 开发中，通过 hdc 工具分析 abc 文件的 Instantiate 阶段耗时占比，高占比往往暗示 Eager 倾向过重。
本质上，Lazy 解析让类加载“轻启动、稳运行”，Eager 解析则追求“重启动、零抖动”。选哪一种，取决于你更在意冷启动速度，还是运行期确定性。
