Spring Boot のプロパティ設計
本記事では、Spring Bootにおける設定値（プロパティ）の管理方法と、
設定変更を反映する際の再ビルド・再起動の要否について整理する。
対象：:contentReference[oaicite:0]{index=0}
1. プロパティの読み込み優先順位
Spring Bootでは、同一の設定項目が複数箇所に定義されている場合、
以下の優先順位で設定値が決定される。
優先度（高 → 低）
- コマンドライン引数
- 環境変数
- 外部
application.properties/application.yml - jar内部の
application.properties - デフォルト設定
例
java -jar app.jar --server.port=8081
この場合、application.properties の設定より
コマンドライン引数が優先される。
2. 通常のJava修正
Javaコードを変更した場合は、以下の手順が必要となる。
Java修正
↓
再ビルド
↓
アプリ再起動
理由
Javaコードはコンパイルされて jarファイルに含まれるため、
修正を反映するには再ビルドが必要となる。
3. 再ビルド不要で設定変更を反映する方法
設定ファイルを jar外に配置することで、
再ビルドなしで設定変更を反映できる。
例
A/app.jar
A/config/application.properties
起動
java -jar app.jar --spring.config.location=./config/
この構成の場合
プロパティ変更
↓
アプリ再起動
のみで設定が反映される。
メリット
- 環境ごとの設定管理が容易
- DB接続先やAPIエンドポイントの変更に柔軟対応
- jarの再ビルド不要
4. 再起動不要で設定変更を反映する方法
設定ファイルを アプリ起動時ではなく処理時に読み込む設計にすることで、
再起動なしで設定変更を反映できる。
例
Properties props = PropertiesLoaderUtils.loadProperties(resource);
String value = props.getProperty("example.key");
処理フロー
処理実行
↓
設定ファイル読み込み
↓
設定値取得
この方式では
設定ファイル変更
↓
次回処理から反映
となり、再起動も不要となる。
5. 再起動不要方式の注意点
この方式にはいくつかのリスクがある。
IOコスト
処理のたびにファイル読み込みが発生するため、
アクセス頻度が高い場合はパフォーマンスに影響する。
更新途中の読み込み
設定ファイル更新中にアプリが読み込むと、
不完全な設定値を取得する可能性がある。
例
key1=value1
key2=
key3=value3
設定値の不整合
複数スレッドが同時に処理する場合
スレッドA → 旧設定
スレッドB → 新設定
のように動作が不安定になる可能性がある。
6. 実務での対策
実務では以下のような対策が行われる。
キャッシュ + 定期リロード
起動時
↓
設定ファイル読み込み
↓
メモリキャッシュ
↓
一定時間ごとに再ロード
アトミック更新
settings.tmp 作成
↓
書き込み完了
↓
rename
↓
アプリが読み込み
これにより 更新途中の読み込み問題を回避できる。
7. まとめ
Spring Bootにおける設定変更の反映方法は
以下の3パターンに整理できる。
方法 再ビルド 再起動
Javaコード修正 必要 必要
外部プロパティ変更 不要 必要
実行時読み込み 不要 不要
一般的なシステムでは
外部プロパティ + 再起動反映が最も多く採用される。