在某次线上部署过程中，我们遇到了一个十分诡异的问题：同样的应用，在 ext3 文件系统下运行正常，但部署到 ext4 文件系统下却出现了如下异常：
The method's class, com.ctc.wstx.io.StreamBootstrapper, is available from the following locations:
jar:file:/.../woodstox-core-asl-4.1.2.jar
jar:file:/.../woodstox-core-5.3.0.jar
问题分析
这是一个典型的 类加载冲突问题：JVM 在 classpath 中找到了两个版本的同一个类，而由于加载顺序的不确定性，错误地使用了老版本或结构不兼容的类，导致运行时异常。
为什么 ext3 正常，ext4 异常？
这是文件系统差异导致的：
ext4 使用 hash 索引管理目录项，文件读取顺序和创建顺序无关；
ext3 更接近线性 inode 分配，文件遍历顺序较为稳定。
换句话说：文件系统影响了 classpath 中 JAR 的读取顺序，从而触发类加载冲突。
复现场景
lib/
├── woodstox-core-asl-4.1.2.jar
├── woodstox-core-5.3.0.jar
├── ...
命令启动：
java -cp "lib/*" com.example.Main
这两个 jar 都包含了 com.ctc.wstx.io.StreamBootstrapper 类。
排查过程
1. 使用 -verbose:class 查看加载顺序
java -verbose:class -cp lib/* ...
输出类似：
[Loaded com.ctc.wstx.io.StreamBootstrapper from file:/.../woodstox-core-asl-4.1.2.jar]
2. 使用 jarscan 工具查找重复类
jarscan -d lib -class com.ctc.wstx.io.StreamBootstrapper
输出：
woodstox-core-asl-4.1.2.jar
woodstox-core-5.3.0.jar
解决方案
1. 删除冗余旧版 jar
rm lib/woodstox-core-asl-4.1.2.jar
2. 显式调整 classpath 顺序
java -cp "lib/woodstox-core-5.3.0.jar:lib/*" ...
3. 使用 Maven/Gradle 管理依赖版本
mvn dependency:tree
ext4 为什么更容易触发异常？
JAR 加载顺序
当执行如下命令启动一个 Java 应用：
java -cp lib/* com.example.Main
或使用 Spring Boot、Tomcat 等框架启动，JVM 会
1.解析 classpath
比如：
lib/*
这个 * 会在 shell 层或 JVM 内部展开为具体 JAR 文件列表，例如：
lib/a.jar lib/b.jar lib/c.jar
但这里的关键点是：
文件系统决定了
lib/*展开顺序！
不同文件系统（ext3 vs ext4）或不同挂载参数（如 dir_index、hashdir）下，目录中文件的顺序不固定。
2.类加载器按顺序遍历这些 JAR
JVM 默认使用的是 双亲委派模型 的类加载器（AppClassLoader），按 classpath 顺序从每个 JAR 中查找 class。
一旦在第一个 jar 中找到了目标类（如 com.ctc.wstx.io.StreamBootstrapper），就不会继续向下找，也不会报冲突，除非：
类在多个 JAR 中结构不同（会导致
ClassCastException、LinkageError）某个 jar 是 shadow jar，打包了全部依赖（容易冲突）
ext4 文件系统具备：
目录 hash 索引（dir_index）
延迟分配（delalloc）
inode 分配是非顺序的
这导致：
ls lib/*.jar
看到的是 a.jar → b.jar → c.jar，但 JVM 实际读取 classpath 时可能顺序是：
c.jar → a.jar → b.jar
而 ext3 则往往顺序更“稳定”或“接近创建时间顺序”。
因此：
在 ext3 下
woodstox-core-5.3.0.jar先被加载，应用正常；而 ext4 下先加载了旧版的woodstox-core-asl-4.1.2.jar，导致类冲突或兼容问题。
三、类加载冲突排查工具推荐
| 工具 | 用途 | 示例 |
|---|---|---|
verbose:class | 显示类被加载来源 | java -verbose:class -cp lib/* com.xxx.Main |
jarscan | 扫描 class 冲突 | jarscan -d lib -class com.ctc.wstx.io.StreamBootstrapper |
jdeps | 查看 jar 的依赖关系 | jdeps lib/woodstox-core-5.3.0.jar |
mvn dependency:tree | Maven 工程依赖树分析 | mvn dependency:tree -Dverbose |
jclasslib | 查看 class 文件详细结构（版本差异） | GUI 工具 |
jar tf | 查看 jar 内容 | jar tf woodstox-core-*.jar |
四、如何彻底避免这类问题？
1. 保持依赖库的唯一性（避免重复类）
手动或使用构建工具（Maven/Gradle）排查依赖冲突。
2. 显式指定 classpath 顺序（优先加载指定 jar）
java -cp "lib/woodstox-core-5.3.0.jar:lib/*" ...
或者打成一个 fat jar。
3. 使用类隔离机制（如 OSGi、ClassLoader 层级）
特别适合插件型应用。
4. 显式移除老旧 jar
如你场景中：
rm lib/woodstox-core-asl-4.1.2.jar
 ✨ | Pokedex（宝可梦图鉴）)
