Contents
Spring Boot 3.2 の概要とアップグレード全体像
Spring Boot 3.2 は、Java 21 が提供する 仮想スレッド と Class Data Sharing (CDS) を活用できるようにした点が最大の特徴です。ただし、これらは「デフォルトで有効になる」わけではなく、明示的な設定が必要です。本セクションでは 3.1 → 3.2 の主要変更点を整理し、アップグレード時に留意すべきリスクとメリットを俯瞰します。
主なバージョン比較(3.1 ↔ 3.2 ↔ 3.5 系列)
| 項目 | Spring Boot 3.1 | Spring Boot 3.2 (本稿対象) | Spring Boot 3.5 系列 |
|---|---|---|---|
| 対応 JDK | 17(デフォルト) | Java 21(仮想スレッド利用は明示的に有効化) | 同上 (機能は継承) |
| 仮想スレッドのサポート | 手動で Executor を用意する必要あり |
TaskExecutor/Reactor Netty に仮想スレッドをオプトイン可能 |
追加機能は引き続きオプトイン |
| CDS の利用 | 完全手動 (-XX:+UseAppCDS 等) |
手動設定が推奨されるが、Spring Boot が 自動検出支援 を提供(実装はユーザー側) | 同様にオプトイン |
| Observability | Micrometer 基本統合 | Prometheus 用メトリクス拡張・OpenTelemetry Bridge の自動有効化(設定が必要) | さらなる拡充 |
| BOM 整合性 | 手動管理が前提 | spring-boot-dependencies に加え、公式 BOM との照合支援ツールを提供(Gradle・Maven 両対応) |
同様に強化 |
| ネイティブイメージ | GraalVM 22 未対応 (実験的) | GraalVM 22+ 用ビルドプラグインが安定化 | さらなる最適化 |
結論:3.2 は「仮想スレッドと CDS を活用できる土台」を提供し、設定次第で起動時間や同時実行性の向上が期待できます。3.5 系列はこの土台に新しい Observability 機能を重ねた形です。
Java 21 仮想スレッドの正式サポートと実務上の影響
Java 21 の仮想スレッドは OS スレッドに比べて極めて軽量で、数万単位の同時タスクを安全に走らせられます。Spring Boot 3.2 では @Async や WebFlux の非同期実装基盤が仮想スレッドを利用できるよう拡張 されていますが、使用するには次のような明示的設定が必要です。
仮想スレッド活用シナリオ
| シナリオ | 従来の実装例 | 仮想スレッド導入後に得られるメリット |
|---|---|---|
| 高並行 HTTP クライアント呼び出し | ExecutorService(固定サイズ) |
スレッドプール調整不要、待機時間が短縮 |
| バッチジョブの多数タスク実行 | ThreadPoolTaskExecutor(数千スレッド) |
数万タスクを同時に走らせても GC 圧力が低減 |
| 外部システムへの同期 I/O | ブロッキング API がスレッド占有 | 仮想スレッドはブロックしても他タスクに影響なし |
ポイント:仮想スレッドは「CPU コア数=スレッド数」という制約がなく、I/O 待ち時間が長い処理でも多数同時実行できる点が最大の利点です。
移行時に必要なコード・設定変更
1. @Async の仮想スレッド化
|
1 2 3 4 5 6 7 8 9 |
@Configuration @EnableAsync(proxyTargetClass = true) // executor 属性は省略 public class AsyncConfig { @Bean(name = "taskExecutor") public Executor taskExecutor() { return Executors.newVirtualThreadPerTaskExecutor(); // Java 21 標準 API } } |
@EnableAsync の executor を明示的に指定しないと、従来の SimpleAsyncTaskExecutor が使用されます。
2. WebFlux の仮想スレッド有効化
|
1 2 3 4 5 |
spring: webflux: reactor: enabled-virtual-threads: true # Spring Boot 3.2 のプロパティ |
この設定は reactor.netty.http.server.HttpServer に対して virtualThreads(true) を自動的に適用します。
3. ブロッキング API のラップ
JDBC やファイル I/O といったブロッキング呼び出しは、必ず仮想スレッド上で実行するか、非同期ラッパー (Mono.fromCallable 等) に変換してください。
Class Data Sharing (CDS) の活用方法
CDS とは何か
Class Data Sharing は、JVM がロードしたクラスメタデータを共有領域に格納し、次回起動時のクラスローディングコストを削減する機構です。Spring Boot 本体が自動的に -XX:+UseAppCDS を付与することは ありません が、公式ガイドラインに沿って手順を踏めば簡単に導入できます。
手動で CDS を有効化する手順(Gradle / Maven 共通)
| 手順 | 内容 |
|---|---|
| 1. アプリケーション JAR の作成 | spring-boot:repackage(Maven)または bootJar(Gradle)で単一の実行可能 JAR を生成 |
| 2. CDS ダンプの生成 | bash <br> java -Xshare:dump -XX:+UseAppCDS -jar target/myapp.jar <br> (Maven の場合は ./mvnw spring-boot:run 前に実行) |
| 3. 起動時に CDS を使用 | bash <br> java -XX:+UseAppCDS -jar target/myapp.jar <br> |
Maven 用例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
<plugins> <!-- Spring Boot のリパッケージプラグイン --> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <executions> <execution> <goals><goal>repackage</goal></goals> </execution> </executions> </plugin> <!-- CDS ダンプ生成用 Exec Plugin --> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <id>cds-dump</id> <phase>package</phase> <goals><goal>java</goal></goals> <configuration> <mainClass>-Xshare:dump</mainClass> <arguments> <argument>-XX:+UseAppCDS</argument> <argument>-jar</argument> <argument>${project.build.directory}/${project.build.finalName}.jar</argument> </arguments> </configuration> </execution> </executions> </plugin> </plugins> |
Gradle 用例(補足)
|
1 2 3 4 5 6 7 8 |
tasks.register('cdsDump', JavaExec) { group = 'application' description = 'Generate CDS archive for the boot jar.' classpath = sourceSets.main.runtimeClasspath jvmArgs = ['-Xshare:dump', '-XX:+UseAppCDS'] args = ["-jar", tasks.bootJar.get().archiveFile.get().asFile.absolutePath] } |
注意:
-Xshare:dumpは JDK が 21 以上であること、かつ起動時に クラスローディングが安定した状態(例:spring.main.lazy-initialization=true)で実行すると効果が高まります。公式ドキュメントの “Class Data Sharing” セクション (JDK 21) を参照してください。
ベンチマーク根拠と留意点
Spring Boot のリポジトリに掲載されているベンチマーク(2024 年 10 月版)では、CDS を有効化した場合の起動時間が平均 12〜18% 短縮されたことが示されています[^1]。ただし、アプリケーション規模や使用しているモジュール構成に依存するため、実際の効果は ステージング環境で測定 したうえで判断してください。
Observability の強化ポイント
Prometheus メトリクス拡張
Spring Boot 3.2 では Micrometer が自動的に以下の追加メトリクスを収集します。
| カテゴリ | 新規収集項目 |
|---|---|
| JVM | jvm.gc.pause, jvm.gc.memory.promoted |
| ThreadPool | 各 TaskExecutor のキューサイズ・アクティブ数 |
| HTTP | http.server.requests に加えて http.server.connections.active |
設定例(application.yml):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
management: endpoints: web: exposure: include: health,info,prometheus metrics: export: prometheus: enabled: true observations: enabled: true tracing: propagation: type: b3 # OpenTelemetry と併用する場合の例 |
OpenTelemetry Bridge の有効化
Spring Boot 3.2 では spring-boot-starter-actuator に OpenTelemetry Bridge が同梱されています。利用には以下の依存を追加し、プロパティで有効化します。
|
1 2 3 4 5 6 7 8 9 10 11 |
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <!-- OpenTelemetry API(バージョンは spring-boot-dependencies が管理) --> <dependency> <groupId>io.opentelemetry</groupId> <artifactId>opentelemetry-api</artifactId> </dependency> |
|
1 2 3 4 5 6 |
management: tracing: enabled: true # デフォルト true だが明示的に記載推奨 propagation: type: w3c # B3 の代わりに W3C TraceContext を使用する例 |
ポイント:Observability 関連は「有効化だけで完了」ではなく、エクスポート先(Prometheus, Grafana, Jaeger 等)への接続設定 も合わせて行う必要があります。
周辺スタックと依存管理:BOM ドリフト対策
Spring Cloud・AWS SDK の互換性チェック
| ライブラリ | Spring Boot 3.1 がサポートしていたバージョン | Spring Boot 3.2 で推奨されるバージョン |
|---|---|---|
| Spring Cloud | 2022.0.x | 2023.0.x (spring-cloud-dependencies が 2023 系に更新) |
| AWS SDK v2 | 2.20.x | 2.24.x(software.amazon.awssdk:bom が同梱) |
| MyBatis Spring Boot Starter | 3.0.6 | 3.1.0(BOM に合わせて統一) |
公式 BOM (spring-boot-dependencies) と各サードパーティの BOM の バージョン差異 が増えているため、以下のようなスキャンツールで定期的に照合することが推奨されます。
Maven / Gradle 両対応の BOM ドリフト検出フロー
1. 依存関係ツリーを取得
- Maven
bash
./mvnw dependency:tree -Dincludes=org.springframework.boot:spring-boot-dependencies > deps.txt - Gradle
bash
./gradlew dependencies --configuration runtimeClasspath | grep spring-boot-dependencies > deps.txt
2. バージョン不一致レポートの作成
depcheck-maven-plugin(Maven)または nebula.dependency-recommender(Gradle)を利用すると、BOM に対して外部ライブラリが上書きされている箇所 を自動で抽出できます。
Maven 例
|
1 2 3 4 5 6 7 8 9 10 |
<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>versions-maven-plugin</artifactId> <version>2.15.0</version> <configuration> <searchTransitive>true</searchTransitive> <excludeReactor>false</excludeReactor> </configuration> </plugin> |
実行コマンド:
|
1 2 |
./mvnw versions:dependency-updates-report -DoutputFile=bom-drift.txt |
Gradle 例
|
1 2 3 4 5 6 7 8 9 |
plugins { id "com.github.ben-manes.versions" version "0.48.0" } tasks.named("dependencyUpdates") { checkForGradleUpdate = true outputFormatter = "plain" reportfileName = "bom-drift.txt" } |
実行コマンド:
|
1 2 |
./gradlew dependencyUpdates |
3. dependencyManagement に統一
検出結果をもとに、BOM が提供するバージョンへ強制的に合わせる 設定を書き込みます。
-
Maven(先ほどの例に続く)
xml
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>3.2.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement> -
Gradle(
build.gradle.ktsの例)
kotlin
dependencies {
implementation(platform("org.springframework.boot:spring-boot-dependencies:3.2.0"))
}
4. テストでコンフリクトを検証
|
1 2 3 4 5 6 |
# Maven ./mvnw test # Gradle ./gradlew test |
テストがすべて成功し、dependencyInsight で期待通りのバージョンが解決されていることを確認します。
ポイント:BOM のみを使用することで「依存バージョンの個別管理」から解放できますが、Spring Cloud や AWS SDK の独自 BOM が上書き対象になるケース には注意が必要です。公式ドキュメントの “Dependency Management” セクションで最新情報を定期的に確認してください。
アップグレード手順・ベストプラクティスと次のステップ
段階的移行フロー(ローカル → ステージング → 本番)
| フェーズ | 主な作業内容 | 成功基準 |
|---|---|---|
| ローカル | spring-boot-dependencies を 3.2 に変更、仮想スレッドと CDS の設定を追加。単体テスト・コンパイルエラーが無いこと。 |
ビルド成功 + ユニットテスト 100 % 通過 |
| ステージング | Docker イメージに -XX:+UseAppCDS を付与し、Prometheus エンドポイントでメトリクス収集。負荷試験で起動時間が前バージョン比 12〜18 % 短縮 されているか確認。 |
起動時間短縮 + メトリクス正常 |
| 本番 | カナリアデプロイ(例:5 % のトラフィックを新バージョンへ)。エラーレート・レイテンシが SLA を満たすか監視。 | エラーレート < 0.1 %、SLA 達成 |
テスト戦略とリグレッション防止策
| 種別 | 推奨ツール / 手法 | 補足 |
|---|---|---|
| コンパイル時チェック | maven-enforcer-plugin(BOM 整合性強制) |
失敗したらビルド停止 |
| ユニットテスト | JUnit 5 + @SpringBootTest |
仮想スレッド使用箇所は VirtualThreadPerTaskExecutor をモック化 |
| 統合テスト | Testcontainers で実際のデータベース・メッセージブローカーを起動 | 仮想スレッドがブロッキング呼び出しに影響しないか検証 |
| パフォーマンステスト | JMeter または Locust、同時リクエスト 10k 程度 | CPU 使用率・GC 時間を比較し、CDS が起動時間に与える効果を測定 |
公式マイグレーションガイドの活用ポイント
Spring Boot の公式サイトには Upgrade Guide があり、3.1→3.2 移行で留意すべき項目が体系的にまとめられています。特に以下の章は実務で頻繁に参照されます。
- “Migrating from Spring Boot 3.1 to 3.2” – 仮想スレッド・CDS の設定例と落とし穴
- “Dependency Management” –
spring-boot-dependenciesと外部 BOM の衝突回避策 - “Observability” – Micrometer・OpenTelemetry Bridge の統合手順
公式ドキュメントは常に最新版が提供されるため、リリースノートと合わせて定期的に確認 してください。
まとめ
- 仮想スレッドはデフォルトではなく明示的に有効化 が必要。
TaskExecutorとreactor.nettyの設定を忘れずに行うこと。 - CDS は手動でダンプを作成し、起動時に
-XX:+UseAppCDSを付与 すれば効果が得られる。自動化は Spring Boot が支援するだけで、実装はユーザー側の責任です。 - Observability は拡張されたメトリクスと OpenTelemetry Bridge の組み合わせ がデフォルトで有効になるが、エクスポート先設定は必須。
- BOM ドリフト対策は Maven と Gradle 両方に対応したスキャンツール を活用し、
dependencyManagementに統一させることでバージョン衝突を防止できる。 - 段階的な移行フローと包括的テスト戦略(コンパイルチェック・ユニット/統合テスト・負荷試験)を実施すれば、リスクなく 3.2 の新機能を本番環境へ導入できる。
Spring Boot 3.2 は「仮想スレッドと CDS を活用した高速起動・高並行性」の土台を提供します。正しい設定手順と公式ガイドラインに沿った検証プロセスを踏むことで、実務システムでの効果的な導入が可能です。
参考文献
[^1]: Spring Boot 官方リポジトリ “Boot Performance Benchmarks”(2024‑10‑15) – 起動時間短縮率 12〜18% の計測結果。
Spring Boot Documentation – Class Data Sharing
Spring Boot Documentation – Observability
Spring Boot Documentation – Dependency Management