Spring Boot アプリケーションは、spring-boot-maven-plugin
を使用して迅速にパッケージ化し、 実行可能ファイルを構築できます。瓶。 Spring Boot には埋め込みコンテナーがあり、アプリケーションは java -jar
コマンドを通じて直接起動できます。
これは単純な起動コマンドですが、その背後には多くの知識が隠されています。今日は、FAT JAR のスタートアップの背後にある原則を探っていきます。この記事は主に次の部分で構成されています:
JAR とは。 java -jar
が何をするのかを知る前に、まず、jar とは何かを理解する必要があります。
FatJar との違いは何ですか。 Spring Boot が提供する実行可能 jar と通常の jar の違いは何ですか?
起動時のクラスロードの原則。クラスローダーは起動時に何をしますか? Spring Boot は、カスタム クラス ローダーを介した埋め込みパッケージの読み込みの問題をどのように解決しますか。
プロセス全体が開始されました。最後に、前の 3 つの部分の内容を統合し、ソース コードを分析して起動を完了する方法を確認します。
JAR ファイル (Java アーカイブ、英語: Java AR#) # #chive) は、Java プラットフォーム アプリケーション ソフトウェアまたはライブラリを配布するために、多数の Java クラス ファイル、関連メタデータ、およびリソース (テキスト、画像など) ファイルを 1 つのファイルに集約するために通常使用されるソフトウェア パッケージ ファイル形式です。簡単に説明すると、これは圧縮パッケージです。圧縮パッケージなので、JAR ファイルの内容を抽出するには、標準的な解凍解凍ソフトウェアを使用して内容を抽出できます。または、Java 仮想マシンに付属のコマンド jar -xf foo.jar を使用して、対応する jar ファイルを解凍します。
JAR は、
非実行可能 JAR の 2 つのカテゴリに単純に分類できます。パッケージ化する場合、main-class を指定する必要はなく、実行することもできません。通常の jar パッケージは、他のプロジェクトが依存するために使用できます。
実行可能 JAR。 jar パッケージをビルドする場合、main-class クラスが指定されており、
java -jar xxx.jar を通じて main-class
の main# を実行できます。
コマンド。##方法は、jar パッケージを実行します。実行可能な jar パッケージ は、他のプロジェクトから
依存することはできません。
ディレクトリ (メタデータ) と package
ディレクトリ (コンパイルされたクラス)。この通常の jar にはサードパーティの依存関係パッケージは含まれておらず、アプリケーション独自の構成ファイル、クラスなどのみが含まれています。 <div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:plain;">.
├── META-INF
│ ├── MANIFEST.MF #定义
└── org # 包路径(存放编译后的class)
└── springframework</pre><div class="contentsignin">ログイン後にコピー</div></div>
説明ファイル MANIFEST.MF
フォルダー内の MANIFEST.MF
ファイルです。 主な構成情報
は次のとおりです:
#Created-By: ファイルのジェネレーターを宣言します。通常、この属性は jar コマンド ライン ツールによって生成されます (例: Created-By: Apache Ant 1.5.1
## Signature-Version: jar ファイルの署名バージョンを定義します。
通常の jar パッケージ
、 も存在します。 mian- class や start-class などの属性。外部の jar パッケージに依存する場合、lib パスおよびその他の情報も MF ファイルで構成されます。 詳細情報参照: Maven を使用して MANIFEST.MF ファイルにコンテンツを追加する方法
実行可能な jar パッケージ
および 通常の jar パッケージのディレクトリについては、 特に決まった構造はありませんが、つまり、どのような構造であっても、.MF ファイルに jar パッケージの情報を設定すれば、通常通り jar パッケージを使用することができます。
FatJar の違いは何ですか。FatJar とは何ですか? 通常の jar には、現在の jar に関する情報のみが含まれ、サードパーティの jar は含まれません。内部的にサードパーティの jar に依存している場合、直接実行するとエラーが報告されます。この場合、サードパーティの jar を実行可能 jar に埋め込む必要があります。
jar とそれに依存するサードパーティの jar を 1 つのパッケージに入れます。このパッケージは FatJar です。Spring Boot埋め込み jar の問題を解決するために、
jar を定義する一連の FatJar ソリューションが提供されています。構造体。実行可能 jar のコンパイルと生成に基づいて、Spring Boot 実行可能パッケージ標準 repackage
に従って spring-boot-maven-plugin を使用して、実行可能 Spring Boot jar を取得します。 実行可能jarの種類により、実行可能jarと実行可能warの2種類に分かれます。
spring-boot-maven-plugin パッケージ化プロセス
#新しく作成された空の SpringBoot プロジェクトのどこにも、関連クラスの明示的な導入や記述がないためです。実際、新しく作成された SpringBoot プロジェクトごとに、pom.xml ファイルに次のプラグインが含まれています。
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>
这个是SpringBoot官方提供的用于打包FatJar的插件,org.springframework.boot.loader
下的类其实就是通过这个插件打进去的;
下面是此插件将 loader 相关类打入 FatJar 的一个执行流程:
org.springframework.boot.maven#execute-> org.springframework.boot.maven#repackage -> org.springframework.boot.loader.tools.Repackager#repackage-> org.springframework.boot.loader.tools.Repackager#writeLoaderClasses-> org.springframework.boot.loader.tools.JarWriter#writeLoaderClasses
最终的执行方法就是下面这个方法,通过注释可以看出,该方法的作用就是将 spring-boot-loader 的classes 写入到 FatJar 中。
/** * Write the required spring-boot-loader classes to the JAR. * @throws IOException if the classes cannot be written */ @Override public void writeLoaderClasses() throws IOException { writeLoaderClasses(NESTED_LOADER_JAR); }
Spring Boot项目被编译以后,在targert
目录下存在两个jar文件:一个是xxx.jar
和xxx.jar.original
。
其中xxx.jar.original
是maven编译后的原始jar文件,即标准的java jar。该文件仅包含应用本地资源。 如果单纯使用这个jar,无法正常运行,因为缺少依赖的第三方资源。
因此spring-boot-maven-plugin
插件对这个xxx.jar.original
再做一层加工,引入第三方依赖的jar包等资源,将其 "repackage"
为xxx.jar
。可执行Jar的文件结构如下图所示:
. ├── BOOT-INF │ ├── classes │ │ ├── application.properties # 用户-配置文件 │ │ └── com │ │ └── glmapper │ │ └── bridge │ │ └── boot │ │ └── BootStrap.class # 用户-启动类 │ └── lib │ ├── jakarta.annotation-api-1.3.5.jar │ ├── jul-to-slf4j-1.7.28.jar │ ├── log4j-xxx.jar # 表示 log4j 相关的依赖简写 ├── META-INF │ ├── MANIFEST.MF │ └── maven │ └── com.glmapper.bridge.boot │ └── guides-for-jarlaunch │ ├── pom.properties │ └── pom.xml └── org └── springframework └── boot └── loader ├── ExecutableArchiveLauncher.class ├── JarLauncher.class ├── LaunchedURLClassLoader$UseFastConnectionExceptionsEnumeration.class ├── LaunchedURLClassLoader.class ├── Launcher.class ├── MainMethodRunner.class ├── PropertiesLauncher$1.class ├── PropertiesLauncher$ArchiveEntryFilter.class ├── PropertiesLauncher$PrefixMatchingArchiveFilter.class ├── PropertiesLauncher.class ├── WarLauncher.class ├── archive │ ├── # 省略 ├── data │ ├── # 省略 ├── jar │ ├── # 省略 └── util └── SystemPropertyUtils.class
META-INF: 存放元数据。MANIFEST.MF 是 jar 规范,Spring Boot 为了便于加载第三方 jar 对内容做了修改;
org: 存放Spring Boot 相关类,比如启动时所需的 Launcher 等;
BOOT-INF/class: 存放应用编译后的 class 文件;
BOOT-INF/lib: 存放应用依赖的 JAR 包。
Spring Boot的MANIFEST.MF
和普通jar有些不同:
Spring-Boot-Version: 2.1.3.RELEASE Main-Class: org.springframework.boot.loader.JarLauncher Start-Class: com.rock.springbootlearn.SpringbootLearnApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Build-Jdk: 1.8.0_131
Main-Class: 是java -jar
启动引导类,但这里不是项目中的类,而是Spring Boot内部的JarLauncher。
Start-Class: 这个才是正在要执行的应用内部主类
所以java -jar
启动的时候,加载运行的是JarLauncher。Spring Boot内部如何通过JarLauncher 加载Start-Class 执行呢?为了更清楚加载流程,我们先介绍下java -jar
是如何完成类加载逻辑的。
这里简单说下java -jar
启动时是如何完成记载类加载的。Java 采用了双亲委派机制,Java语言系统自带有三个类加载器:
Bootstrap CLassloder: 最顶层的加载类,主要加载核心类库
Extention ClassLoader: 扩展的类加载器,加载目录%JRE_HOME%/lib/ext
目录下的jar包和class文件。 还可以加载-D java.ext.dirs选项指定的目录。
AppClassLoader: 是应用加载器。
默认情况下通过java -classpath
,java -cp
,java -jar
使用的类加载器都是AppClassLoader。 普通可执行jar通过java -jar
启动后,使用AppClassLoader加载Main-class
类。 如果第三方jar不在AppClassLoader里,会导致启动时候会报ClassNotFoundException。
例如在Spring Boot可执行jar的解压目录下,执行应用的主函数,就直接报该错误:
Exception in thread "main" java.lang.NoClassDefFoundError: org/springframework/boot/SpringApplication
at com.glmapper.bridge.boot.BootStrap.main(BootStrap.java:13)
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.SpringApplication
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 1 more
从异常堆栈来看,是因为找不到SpringApplication
这个类;这里其实还是比较好理解的,BootStrap
类中引入了SpringApplication
,但是这个类是在BOOT-INF/lib
下的,而java指令在启动时未指明classpath
,依赖的第三方jar无法被加载。
Spring Boot JarLauncher启动时,会将所有依赖的内嵌 jar (BOOT-INF/lib 目录下) 和class(BOOT-INF/classes 目录)都加入到自定义的类加载器LaunchedURLClassLoader中,并用这个ClassLoder去加载MANIFEST.MF配置Start-Class,则不会出现类找不到的错误。
LaunchedURLClassLoader是URLClassLoader的子类, URLClassLoader会通过URL[] 来搜索类所在的位置。Spring Boot 则将所需要的内嵌文档组装成URL[],最终构建LaunchedURLClassLoader类。
有了以上知识的铺垫,我们看下整个 FatJar 启动的过程会是怎样。为了以便查看源码和远程调试,可以在 pom.xml 引入下面的配置:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-loader</artifactId> </dependency>
简单概括起来可以分为几步:
java -jar 启动,AppClassLoader 则会加载 MANIFEST.MF 配置的Main-Class, JarLauncher。
JarLauncher启动时,注册URL关联协议。
获取所有内嵌的存档(内嵌jar和class)
根据存档的URL[]构建类加载器。
然后用这个类加载器加载Start-Class。 保证这些类都在同一个ClassLoader中。
以上がSpringboot の FatJar と Jar とは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。