本文深入探讨java模块系统在`jlink`构建自定义运行时镜像时的模块添加机制。`jlink`默认以模块为单位进行添加，确保运行时配置的可靠性，但可能导致镜像包含不必要的组件。文章将解释为何无法直接裁剪模块内部包，并介绍如何通过graalvm的ahead-of-time编译与“tree-shaking”技术，实现更极致的运行时镜像瘦身与优化。
Java模块系统与jlink概述
Java平台模块系统（JPMS），自Java 9引入，旨在通过模块化来提高应用程序的可靠性、可维护性和性能。它强制了更强的封装性，并允许开发者声明模块间的明确依赖关系。jlink工具是JPMS的核心组件之一，它允许开发者根据应用程序的实际需求，创建一个只包含所需模块的自定义JRE（Java Runtime Environment）。这种机制能够显著减小部署包的体积，特别适用于微服务、容器化部署以及嵌入式系统。
通过jlink，我们可以将应用程序及其依赖的Java平台模块打包成一个独立的运行时镜像，例如：
jlink --module-path $JAVA_HOME/jmods --add-modules java.desktop --output mycustomrt
上述命令创建了一个名为mycustomrt的自定义运行时镜像，其中包含了java.desktop模块及其所有传递性依赖。
jlink的模块添加机制：整体性原则
在使用jlink添加模块时，一个核心问题是：是否可以只添加模块中所需的部分（例如特定的包），而不是整个模块？答案是：不可以。jlink以及Java模块系统中的requires声明，都遵循模块整体性原则。这意味着当你添加一个模块时，整个模块及其所有声明的导出包和传递性依赖都会被包含进来。
立即学习“Java免费学习笔记（深入）”；
以java.desktop模块为例，如其API文档所示，它包含了大量的包，如java.applet、java.awt、javax.swing、javax.sound等。即使一个简单的Spring Boot应用可能只需要java.desktop中极少的功能（例如，某些底层图形或系统交互能力，即使没有直接的UI），jlink也会将整个java.desktop模块及其所有相关的子系统（如AWT、Swing、音频处理等）全部包含到运行时镜像中。这无疑会增加镜像的体积，因为其中包含了大量应用根本不需要的代码。
这种整体性设计是Java模块系统为了提供可靠配置所必需的。如果允许开发者随意裁剪模块内部的包，那么在运行时可能会因为缺少某个看似不相关的包而导致ClassNotFoundException或NoSuchMethodError。模块系统通过强制包含整个模块来避免此类运行时错误，确保模块之间的依赖关系始终是完整且一致的。
运行时镜像瘦身的局限性与挑战
jlink虽然在减小运行时体积方面迈出了一大步，但其模块级别的粒度限制了更极致的优化。对于那些包含大量功能但应用只使用其中一小部分的“胖”模块，jlink的优化能力显得不足。例如，一个非UI应用仅仅因为某个深层依赖间接引入了java.desktop模块，就不得不承担整个桌面环境模块的体积，这显然不是最优解。
高级优化策略：GraalVM AOT编译与Tree-Shaking
当jlink的优化能力无法满足对极致运行时镜像体积和启动速度的需求时，可以考虑更高级的优化手段，特别是利用GraalVM Native Image提供的Ahead-Of-Time (AOT) 编译和Tree-Shaking技术。
Ahead-Of-Time (AOT) 编译: GraalVM Native Image可以将Java应用程序及其所有依赖（包括JDK模块）编译成一个独立的、原生的可执行文件。与传统的JIT（Just-In-Time）编译不同，AOT编译在程序运行之前就完成了代码的机器码转换。这意味着生成的本地镜像无需JVM即可运行，启动速度极快，并且通常具有更低的内存占用。
Tree-Shaking（摇树优化）: 这是GraalVM Native Image实现极致瘦身的关键技术。在AOT编译过程中，GraalVM会进行深度静态分析，遍历应用程序的所有代码路径，识别并移除所有在运行时确定不会被调用的类、方法和字段。这种优化是跨越模块和库边界的，它甚至可以精确到模块内部的包和方法级别。例如，即使java.desktop模块被包含进来，如果应用确实没有调用任何AWT或Swing相关的代码，Tree-Shaking就会将这些未使用的部分从最终的本地可执行文件中剔除。
如何使用GraalVM Native Image进行优化：
首先，需要安装GraalVM。然后，通常通过以下方式将一个JAR包编译为本地镜像：
native-image -jar your-application.jar -H:Name=your-native-app
这将生成一个名为your-native-app的本地可执行文件。
注意事项：
尽管GraalVM Native Image提供了强大的优化能力，但它并非没有挑战。由于AOT编译是在构建时进行静态分析，对于Java中广泛使用的反射、动态代理、JNI等运行时特性，可能需要提供额外的配置（如reflection-config.json、proxy-config.json等），以确保GraalVM能够在编译时正确识别并包含这些动态加载的代码。这通常需要更深入的配置和测试工作。
总结与展望
jlink是Java模块系统提供的一个强大工具，用于创建轻量级的自定义JRE，其模块添加遵循整体性原则，以确保运行时环境的可靠性。然而，对于追求极致体积优化和启动速度的应用，jlink的模块级别粒度可能不够。
此时，GraalVM Native Image及其AOT编译和Tree-Shaking技术提供了更激进的解决方案。它能够将Java应用编译为体积更小、启动更快、内存占用更低的本地可执行文件，通过深度静态分析移除所有未使用的代码，无论其来源。
开发者应根据项目的具体需求、对运行时性能和镜像大小的权衡，以及开发团队的技术栈和对新技术的接受度，来选择最适合的运行时优化策略。对于大多数场景，jlink已能提供足够的优化；而对于对资源极其敏感的场景（如Serverless函数、微服务冷启动优化等），GraalVM Native Image则是一个值得投入的强大选项。
