Java模块化应用：jlink构建与模块解析

## Java模块化应用：jlink构建与模块解析详解 本文深入解析了Java模块化应用中`jlink`工具的使用，以及为何其构建自定义运行时镜像时，以整个模块而非特定包为单位进行添加。这种设计旨在保障运行时配置的可靠性，避免因依赖缺失导致的运行时错误。对于追求极致镜像大小的开发者，除了精确选择`jlink`模块外，还可以探索GraalVM Native Image等AOT编译技术，通过“摇树”机制实现更细粒度的代码剪裁，从而生成更小、启动更快的本地可执行文件。理解Java模块系统与`jlink`的工作原理，能帮助开发者更有效地构建和优化Java应用程序，尤其是在云原生和微服务架构中，减小镜像体积具有重要意义。

在使用`jlink`工具构建Java自定义运行时镜像时，模块系统默认以整个模块为单位进行添加，而非按需选择特定包。这种设计确保了运行时配置的可靠性，避免了因缺失依赖而导致的运行时错误。对于追求极致镜像大小优化的场景，可以考虑利用GraalVM Native Image等AOT编译技术，通过“摇树”（tree-shaking）机制实现更细粒度的代码剪裁。

理解Java模块系统与jlink

Java模块系统（Jigsaw项目）旨在提高应用程序的可靠性、安全性、性能和可维护性。它将JDK本身以及应用程序分解为离散的模块，每个模块明确声明其依赖关系和导出的API。jlink工具是JDK提供的一个强大功能，允许开发者根据应用程序的需求，创建只包含所需模块的自定义运行时镜像。这对于部署小型、自包含的Java应用程序尤其有用，因为它能显著减小部署包的大小。

例如，为一个非模块化的Spring Boot应用创建自定义运行时，可能需要添加java.desktop模块，即使应用本身并非桌面应用：

jlink --module-path $JAVA_HOME/jmods --add-modules java.desktop --output mycustomrt

这条命令会创建一个名为mycustomrt的运行时镜像，其中包含了java.desktop模块及其所有传递性依赖。

模块添加的粒度：为什么是整个模块？

在Java模块系统中，当通过--add-modules选项添加一个模块时，如java.desktop，系统会包含该模块的全部内容，包括其声明导出的所有包。开发者可能会注意到，像java.desktop这样的模块包含大量与桌面UI、音频等相关的包（如java.awt、javax.swing、javax.sound等），而这些包对于一个纯后端或命令行应用来说是完全不必要的。

核心原因在于模块系统的“可靠配置”原则。 Java模块系统设计的目标之一是提供一个可靠且一致的运行时环境。如果允许开发者随意排除模块中的特定包，将可能导致以下问题：

1. 运行时错误： 模块的内部实现或其依赖的其它模块可能在运行时需要某个被错误排除的包。在编译时或链接时，这种细粒度的排除很难被精确检测，从而在运行时抛出ClassNotFoundException或NoClassDefFoundError。
2. 打破模块封装性： 模块的module-info.java文件明确声明了它导出的所有包。允许部分导出或排除，会使得模块的边界模糊，破坏其封装性和可预测性。
3. 复杂性增加： 管理模块内部的包级别依赖和排除规则将极大地增加模块系统的复杂性，使其难以理解和使用。

因此，为了确保模块系统提供的可靠性保证，jlink在添加模块时，始终以整个模块为单位进行操作。这意味着一旦一个模块被包含，其所有导出的包及其传递性依赖都会被纳入运行时镜像中。

进一步优化镜像大小的策略

尽管jlink在模块层面进行操作，但对于追求极致镜像大小的场景，仍有其他高级优化手段：

1. 精确选择模块： 在使用jlink时，最直接的优化是只添加应用程序真正需要的最小模块集。这通常需要对应用程序的依赖进行深入分析。对于非模块化应用，可以通过工具（如jdeps）来分析其类路径依赖，从而推断出所需的JDK模块。
2. GraalVM Native Image： 这是目前实现Java应用极致瘦身最有效的方案之一。GraalVM Native Image是一种 ahead-of-time (AOT) 编译器，可以将Java应用程序编译成独立的本地可执行文件。其核心优化机制包括：
   • “摇树”（Tree-shaking）： 在编译阶段，Native Image会进行深度分析，只包含应用程序实际执行路径中用到的类、方法和字段，从而排除所有未使用的代码。这比jlink的模块级别剪裁更为精细，能够达到包甚至类/方法级别的优化。
   • 静态链接： 生成的本地可执行文件通常不依赖外部JVM，而是将运行时组件静态链接到可执行文件中，进一步减小部署体积并提高启动速度。

通过GraalVM Native Image，即使是像java.desktop这样庞大的模块，如果应用程序只使用了其中极少数的类（例如，仅仅是为了某个特定的配置或系统属性查询，而不是完整的UI框架），Native Image也能智能地只包含这些被实际使用的部分，从而大幅度减小最终可执行文件的大小。

总结

Java模块系统通过jlink工具提供了构建自定义运行时镜像的能力，但其模块添加的粒度是整个模块，而非细化到包级别。这一设计决策是为了维护模块系统的可靠性和一致性，避免潜在的运行时错误。对于希望进一步减小应用部署体积的开发者，除了精确选择jlink模块外，更高级的解决方案是探索像GraalVM Native Image这样的AOT编译技术，它能够通过“摇树”等机制实现更深层次的代码优化，从而生成更小、启动更快的本地可执行文件。

到这里，我们也就讲完了《Java模块化应用：jlink构建与模块解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！