java 不采用静态或动态链接的概念，所有类均在运行时由类加载器动态加载；依赖是否“打包进 jar”仅影响资源来源位置，不改变动态加载本质。
java 不采用静态或动态链接的概念，所有类均在运行时由类加载器动态加载；依赖是否“打包进 jar”仅影响资源来源位置，不改变动态加载本质。
在 Java 生态中，“链接（linking）”一词并不适用——JVM 从不进行传统 C/C++ 意义上的编译期静态链接或运行时动态链接。取而代之的是 按需、延迟、动态的类加载（class loading）机制。无论你使用 java -jar app.jar、java -cp lib/* MyApp，还是通过 Maven Shade 插件生成“fat jar”，底层行为始终一致：类只在首次被引用时才由 ClassLoader 加载，且加载源可任意定制。
类加载器如何定位并加载类？
Java 应用启动时，JVM 会初始化一个系统类加载器（System ClassLoader），它依据 ClassPath 查找 .class 文件。ClassPath 并非路径列表，而是一组资源定位规则，支持三种形式：
- 目录路径（如 ./classes）→ 按包结构查找 com/example/App.class 对应的 ./classes/com/example/App.class
- JAR 文件路径（如 lib/commons-lang3.jar）→ 在该 JAR 内部按 ZIP 路径查找 /com/example/App.class
- 通配符路径（如 'lib/*'）→ 展开为 lib/a.jar, lib/b.jar 等（不递归子目录）
⚠️ 注意：* 必须原样传递给 JVM（Linux/macOS 下需单引号包裹，避免 shell 展开）；Windows 可直接写 lib/*。
当执行 java com.example.App 时，JVM 首先尝试加载 com.example.App 类：
立即学习“Java免费学习笔记（深入）”；
- 将类名 com.example.App 转为资源路径 /com/example/App.class；
- 依次遍历 ClassPath 中每个条目，检查该路径是否存在；
- 首个匹配即命中并加载（后续同名类将被忽略）；
- 加载后若引用新类（如 new ArrayList()），则重复此过程——整个过程完全惰性、可插拔。
-jar 模式下的 ClassPath 规则（关键！）
使用 java -jar myapp.jar 时，环境变量 CLASSPATH 和 -cp 参数将被完全忽略。JVM 改为读取 JAR 包内 META-INF/MANIFEST.MF 中的 Class-Path 属性：
Manifest-Version: 1.0 Main-Class: com.example.App Class-Path: libs/gson.jar libs/logback-core.jar
- Class-Path 值为空格分隔的相对路径，基准目录是当前运行 JAR 所在目录；
- 实际 ClassPath = myapp.jar + libs/gson.jar + libs/logback-core.jar（顺序即搜索顺序）；
- 因此部署结构应清晰分离：
/myapp/ ├── myapp.jar # 含上述 MANIFEST └── libs/ ├── gson.jar └── logback-core.jar此时无论你在 /home/user 还是 /tmp 目录下执行 java -jar /myapp/myapp.jar，均可正常运行。
关于 “Shaded JAR”（Fat JAR）的真相
Maven Shade Plugin 生成的 shaded JAR（如 myapp-shaded.jar）本质是：将所有依赖字节码解压、重命名（可选）、再重新打包进单个 JAR。它之所以能“独立运行”，是因为：
- META-INF/MANIFEST.MF 中声明了 Main-Class；
- 所有依赖类已物理存在于该 JAR 内，ClassPath 只需包含自身即可命中。
但这不等于“静态链接”——它只是把多个 JAR 的内容合并到一个 ZIP 容器中，类仍由标准 ClassLoader 动态加载，只是来源变成了同一个 ZIP 文件。
✅ 优势：部署简单，适合容器化或受限环境（如无权写入 libs/ 目录）。
❌ 缺陷：
- 体积膨胀（重复依赖、无法共享 JVM 级缓存）；
- 版本冲突难调试（如两个依赖间接引入不同版本的 slf4j-api，shade 后可能静默覆盖）；
- 违反模块化原则，不利于增量更新（改一个依赖需重发整个 JAR）。
推荐的生产部署实践
优先采用 “thin JAR + 显式 Class-Path” 方案：
<!-- Maven pom.xml 示例：配置 maven-jar-plugin 自动生成 Class-Path -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<classpathPrefix>libs/</classpathPrefix>
<mainClass>com.example.App</mainClass>
</manifest>
</archive>
</configuration>
</plugin>构建后，target/myapp.jar 的 MANIFEST.MF 自动包含：
Class-Path: libs/gson-2.10.1.jar libs/logback-core-1.4.11.jar
配合标准目录结构部署，即可实现：
? 单点启动（java -jar myapp.jar）
? 依赖隔离（替换 libs/ 下指定 JAR 即可升级）
? 网络/CDN 友好（各 JAR 可独立缓存、校验、灰度发布）
? 补充：对于终端用户分发，应使用 jlink + jpackage 构建自包含运行时镜像（含 JRE），而非依赖用户本地 Java 环境——这才是现代 Java 桌面/服务端应用的标准交付方式。
总之：Java 的“依赖管理”本质是资源发现与加载策略问题，而非链接模型问题。理解 ClassLoader 与 ClassPath 的协作逻辑，比纠结“静态/动态”标签更能帮你写出可维护、可部署的 Java 应用。
