Java jlink 怎样只打包应用需要的模块

Java jlink 只会把指定的根模块及其传递依赖放进自定义运行时，关键不是手工猜一串模块名，而是先用 jdeps --print-module-deps 观察依赖，再把应用模块和确实需要的 JDK 模块交给 --add-modules。这样得到的镜像比携带完整 JDK 更容易分发，也更容易复核。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/specs/man/jlink.html

先算出依赖，再决定根模块

先确认编译产物、应用模块名和入口。例如应用模块是 com.example.app，模块路径放在 build/mods，JDK 自带模块在 $JAVA_HOME/jmods。模块化应用不需要把所有 JDK 模块都写进列表，requires 关系会参与解析；服务加载、反射和本地库则要单独留意。

# 先观察 JAR 需要哪些 JDK 模块，输出只作为候选清单
jdeps --ignore-missing-deps --print-module-deps build/app.jar

# 假设输出为下面这组 JDK 模块
java.base,java.logging

最终的根模块可以写成 com.example.app,java.base,java.logging。如果应用已经是规范的模块化 JAR，先确认 module-info.class 和 requires 是否完整，比盲目追加模块更可靠。

用 jlink 生成只包含必要模块的运行时

下面的命令把应用模块目录和 JDK 模块目录合并为模块路径，再用应用模块作为根。--launcher 会生成一个稳定的启动命令；三个裁剪选项去掉调试信息、头文件和手册，--compress=2 对资源做 ZIP 压缩。

# 以应用模块为根，jlink 会解析它的传递依赖
jlink --module-path build/mods:"$JAVA_HOME/jmods" \
  --add-modules com.example.app,java.base,java.logging \
  --strip-debug --no-header-files --no-man-pages --compress=2 \
  --launcher app=com.example.app/com.example.Main \
  --output build/runtime

# 生成后从自定义运行时启动应用
build/runtime/bin/app

选模块时可以按这个边界判断：

生成运行时后，按清单和入口复核

不要把“jlink 命令成功退出”当成应用完整可用。先列出镜像里的模块，再启动真实入口；如果应用通过 ServiceLoader、反射、JNI 或配置文件加载类，必须把对应场景放进验收用例。

# 查看自定义运行时实际包含的模块
build/runtime/bin/java --list-modules

# 使用镜像自带的启动器运行最小验收场景
build/runtime/bin/app

--bind-services 会把服务提供者模块及其依赖纳入链接结果，适合确实依赖服务发现的程序；不需要服务绑定时不要为了“保险”默认打开。另一个常见误区是用 --limit-modules 过早收窄可观察模块，应该在依赖和服务边界确认后再使用。

一份可执行的裁剪检查清单

• 入口：确认 --launcher 的模块名和主类与 module-info.java 一致。
• 服务：检查 uses、provides 和实际服务提供者，必要时再加 --bind-services。
• 资源：验证 locale、字体、配置文件和 SPI 实现没有被构建流程遗漏。
• 分发：自定义运行时不会自动替你升级，发布时要建立 JDK 安全更新和镜像重建流程。

因此，最稳妥的做法是把 jdeps 当作依赖发现工具，把 jlink 当作确定性组装工具，最后用模块清单和真实启动场景确认裁剪结果，而不是追求一个看起来最小但无法运行的目录。

相关问题

只写 java.base 是否就够了

只有应用确实只依赖 java.base 时才够。日志、网络、XML、桌面或其他 API 会引入额外模块，应以模块声明和依赖分析为准。

为什么加了 bind-services 后镜像变大

因为它会把可绑定的服务提供者模块及其依赖纳入运行时。服务发现是必要能力时保留，否则先关闭并用测试验证。

jlink 能否直接解决反射找不到类

不能保证。jlink 解析的是模块图，运行时反射还受模块开放关系、配置文件和框架约定影响，需要把反射路径加入实际验收。