如何利用参数追踪类加载明细定位启动阶段无用三方包的大量无效加载-java教程-PHP中文网

直接用-verbose:class参数可识别“白忙活”的三方包：大量同类jar类密集加载但自动配置报告无匹配，或多个版本同名库仅一方被使用，结合debug=true报告和mvn dependency:tree可精准定位并裁剪冗余依赖。

如何利用参数追踪类加载明细定位启动阶段无用三方包的大量无效加载

直接用 -verbose:class 参数就能看到每个类从哪个 JAR、由哪个类加载器加载，再结合启动日志里的耗时分布，一眼识别出哪些三方包在“白忙活”——它们被加载了，但后续根本没被 Spring 扫描或实例化。

启动时加上该 JVM 参数后，控制台会逐行打印类似：

[Loaded org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration from file:/BOOT-INF/lib/spring-boot-autoconfigure-3.2.5.jar]

[Loaded com.google.common.base.Preconditions from file:/BOOT-INF/lib/guava-31.1-jre.jar]

[Loaded io.netty.buffer.PooledByteBufAllocator from file:/BOOT-INF/lib/netty-buffer-4.1.100.Final.jar]

重点不是“有没有加载”，而是关注三类信号：

大量来自同一 jar（如 guava-*.jar、netty-*.jar）的类密集出现，但后续自动配置报告（debug=true 输出）里完全没提它——说明这个包只是被动加载，未参与任何 Bean 构建或条件判断；
某个 jar 的类集中在启动前半段刷屏式加载，但之后再无关联 Bean 或配置类被触发（比如没看到 xxxAutoConfiguration 或 @Component 类加载）；
多个版本的同名库并存（如 okhttp-3.14.9.jar 和 okhttp-4.12.0.jar），但只有一方的类被实际使用，另一方纯属冗余占用内存和 I/O。

debug=true 在 application.properties 中启用后，Spring Boot 会在启动末尾输出完整的自动配置报告。这份报告才是真正反映“哪些依赖被用上了”的依据：

在 Positive matches 里出现的 auto-configuration 类，说明对应 starter 或 jar 的功能已激活；
在 Negative matches 里看到某配置项因 @ConditionalOnClass 不满足而跳过，再回头查 -verbose:class 日志——如果连它的基础类（如 RedisConnectionFactory）都没加载过，那整个 spring-boot-starter-data-redis 就是空载；
如果某 jar 的所有类都加载了，但报告中既没匹配也没拒绝任何相关配置，基本可判定：它只是被 classpath 拖进来的“背景板”。

确认某个包无效后，别急着删，先查它是谁带进来的：

运行 mvn dependency:tree -Dincludes=groupId:artifactId（例如 -Dincludes=com.squareup.okhttp3:okhttp），快速定位引入路径；
若发现是某个 starter 的传递依赖（如 spring-cloud-starter-openfeign 带入了整套 okhttp，但项目实际用的是 HttpClient），就在该 starter 下加 <exclusion></exclusion> 排除；
对明确不用的模块（如 spring-boot-starter-thymeleaf 却没写任何模板），直接从 pom 中移除，避免它触发额外的资源扫描与 EL 表达式解析器加载。

根据实测数据，类加载阶段占 Spring Boot 启动总耗时超 50%。如果某个三方包贡献了大量 [Loaded xxx] 日志，却没带来任何 BeanDefinition 注册或 @Configuration 处理，它就是在拖慢启动：

对比不同环境（如本地 vs 测试服）的 -verbose:class 输出行数，若某环境多出上万行来自 org.apache.logging.log4j 的类加载，而日志框架实际只用 SLF4J 绑定，说明 Log4j2 被误加载；
注意那些只加载接口、抽象类、测试工具类（如 org.junit.jupiter.api.Test）的 jar——它们本不该出现在生产 classpath 中，属于构建配置疏漏。