使用するアプリケーションは、クラスパス上のファイルが変更されるたびに自動的に再起動します。これは、コードの変更に対して非常に高速なフィードバックループを提供するため、IDEで作業する場合に便利な機能です。デフォルトでは、フォルダーを指すクラスパス上のエントリは、変更が監視されます。静的アセットやビューテンプレートなどの特定のリソースでは、アプリケーションを再起動する必要がないことに注意してください。再起動のトリガーDevToolsはクラスパスリソースを監視するため、再起動をトリガーする唯一の方法はクラスパスを更新することです。クラスパスを更新する方法は、使用しているIDEによって異なります。Eclipseでは、変更されたファイルを保存すると、クラスパスが更新され、再起動がトリガーされます。Project)をビルドすると同じ効果があります。フォークが有効になっている限り、サポートされているビルドプラグイン(MavenおよびGradle)を使用してアプリケーションを起動することもできます。これは、DevToolsが適切に動作するために独立したアプリケーションクラスローダーを必要とするためです。デフォルトでは、GradleおよびMavenプラグインはアプリケーションプロセスをフォークします。自動再起動は、LiveReloadと併用すると非常にうまく機能します。詳細については、LiveReloadセクションを参照してください。JRebelを使用する場合、動的なクラスの再読み込みを優先して自動再起動が無効になります。その他のdevtools機能(LiveReloadやプロパティのオーバーライドなど)は引き続き使用できます。DevToolsは、アプリケーションコンテキストのシャットダウンフックに依存して、再起動中に閉じます。シャットダウンフック(SpringApplication.setRegisterShutdownHook(false))を無効にした場合、正しく機能しません。spring-boot-starterという名前のプロジェクトを自動的に無視します。カスタマイズする必要があります。アプリケーションがすでに提供している場合、ラップされます。メソッドの直接オーバーライドはサポートされていません。Bootが提供する再起動テクノロジは、2つのクラスローダーを使用して機能します。変更されないクラス(たとえば、サードパーティのjarからのクラス)は、基本クラスローダーにロードされます。積極的に開発しているクラスは、再起動クラスローダーにロードされます。アプリケーションを再起動すると、再起動クラスローダーが破棄され、新しいクラスローダーが作成されます。このアプローチは、基本クラスローダーがすでに利用可能であり、データが設定されているため、通常、アプリケーションの再起動は「コールドスタート」よりもはるかに高速であることを意味します。テクノロジーをZeroTurnaroundからリロードすることを検討できます。これらは、ロードされたクラスを書き換えて、リロードを受け入れやすくすることで機能します。状態評価の変更の記録デフォルトでは、アプリケーションを再起動するたびに、状態評価デルタを示すレポートが記録されます。このレポートには、Beanの追加や削除、構成プロパティの設定などの変更を行うと、アプリケーションの自動構成に対する変更が表示されます。レポートのログを無効にするには、次のプロパティを設定します。リソースを除外する特定のリソースは、変更されたときに必ずしも再起動をトリガーする必要はありません。例:Thymeleafテンプレートはその場で編集できます。リソースを変更しても再起動はトリガーされませんが、ライブリロードはトリガーされます。プロパティを使用できます。除外するには、次のプロパティを設定します。プロパティを使用します。追加のパスを見るクラスパスにないファイルに変更を加えた場合、アプリケーションを再起動または再ロードすることができます。プロパティを使用して、変更を監視する追加のパスを構成します。プロパティを使用して、追加のパスにある変更が完全な再起動またはライブリロードをトリガーするかどうかを制御できます。プロパティを使用して無効にすることができます。このプロパティを設定できます(そうすると、再起動クラスローダーが初期化されますが、ファイルの変更は監視されません)。設定する必要があります。変更されたファイルを継続的にコンパイルするIDEを使用している場合、特定の時間にのみ再起動をトリガーすることをお勧めします。そのためには、「トリガーファイル」を使用できます。これは、実際に再起動チェックをトリガーするときに変更する必要がある特別なファイルです。ファイルを更新すると、チェックがトリガーされますが、再起動は、Devtoolsが何らかの処理を行うことを検出した場合にのみ実際に発生します。プロパティをトリガーファイルの名前(パスを除く)に設定します。トリガーファイルは、クラスパスのどこかに表示する必要があります。プロパティは次のようになります。更新されたときにのみ発生します。グローバル設定として設定できます。一部のIDEには、トリガーファイルの手動更新を不要にする機能があります。両方ともそのようなサポートを持っています。.reloadtriggerである限り)。IntelliJについては、このドキュメントの指示に従ってください。再起動クラスローダーのカスタマイズ再起動とリロードセクションで前述したように、再起動機能は2つのクラスローダーを使用して実装されます。ほとんどのアプリケーションでは、このアプローチはうまく機能します。クラスロードの課題が発生する場合があります。ファイルは「ベース」クラスローダーでロードされます。すべてのモジュールがIDEにインポートされるわけではなく、マルチモジュールプロジェクトで作業している場合は、カスタマイズが必要になる場合があります。ファイルを作成できます。restart.includeというプレフィックスが付いたプロパティを含めることができます。要素は「ベース」クラスローダーにプッシュダウンする必要があるアイテムです。次の例に示すように、プロパティの値はクラスパスに適用される正規表現パターンです。restart.exclude.companycommonlibs=/mycorp-common-[\\w\\d-\.]+\.jarrestart.include.projectcommon=/mycorp-myproj-[\\w\\d-\.]+\.jarすべてのプロパティキーは一意である必要があります。始まる限り、考慮されます。プロジェクト内、またはプロジェクトが使用するライブラリ内にファイルをパッケージ化できます。ObjectInputStreamを使用してデシリアライズされたオブジェクトではうまく機能しません。Thread.currentThread().getContextClassLoader()と組み合わせて使用する必要がある場合があります。残念ながら、いくつかのサードパーティライブラリは、コンテキストクラスローダーを考慮せずにデシリアライズします。このような問題を見つけた場合は、元の作者に修正を依頼する必要があります。モジュールには、リソースが変更されたときにブラウザーのリフレッシュをトリガーするために使用できるLiveReloadサーバーが組み込まれています。Chrome、Firefox、およびSafariで自由に使用できます。falseに設定できます。一度に実行できるLiveReloadサーバーは1つだけです。アプリケーションを開始する前に、他のLiveReloadサーバーが実行されていないことを確認してください。IDEから複数のアプリケーションを起動する場合、最初のアプリケーションのみがLiveReloadをサポートしています。フォルダーに追加することにより、グローバルdevtools設定を構成できます。Bootアプリケーションに適用されます。例:常にトリガーファイルを使用するように再起動を構成するには、次のプロパティを追加します。ファイルの存在が検索されます。Bootの古いバージョン上にあるアプリケーションとdevtoolsグローバル構成を共有できます。上記のファイルでアクティブ化されたプロファイルは、プロファイル固有の構成ファイルのロードには影響しません。Boot開発者ツールは、ローカル開発に限定されません。アプリケーションをリモートで実行するときに、いくつかの機能を使用することもできます。リモートサポートはオプトインです。これを有効にするとセキュリティ上のリスクになる可能性があります。信頼できるネットワークで実行している場合、またはSSLで保護されている場合にのみ有効にしてください。'リモートサポートを使用しないでください。本番デプロイでサポートを有効にしないでください。再パッケージ化されたアーカイブに含まれていることを確認する必要があります。プロパティを設定する必要があります。重要なパスワードやシークレットと同様に、値は一意で強力で、推測や総当たり攻撃ができないようにする必要があります。devtoolsサポートは2つの部分で提供されます。接続を受け入れるサーバー側エンドポイントと、IDEで実行するクライアントアプリケーションです。プロパティが設定されると、サーバーコンポーネントは自動的に有効になります。クライアントコンポーネントは手動で起動する必要があります。リモートクライアントアプリケーションの実行リモートクライアントアプリケーションは、IDE内から実行されるように設計されています。実行する必要があります。いう名前のプロジェクトがある場合、次のようにします。「起動構成」を作成します。プロジェクトを参照します。メインクラスとして使用します。(またはリモートのURL)に追加します。実行中のリモートクライアントは、次のリストのようになります。1.105)リモートクライアントは実際のアプリケーションと同じクラスパスを使用しているため、アプリケーションプロパティを直接読み取ることができます。プロパティが読み取られ、認証のためにサーバーに渡されます。使用することを常にお勧めします。これにより、トラフィックが暗号化され、パスワードを傍受できなくなります。プロパティを構成します。リモートアップデートリモートクライアントは、ローカル再起動と同じ方法でアプリケーションクラスパスの変更を監視します。)再起動をトリガーします。これは、ローカルにないクラウドサービスを使用する機能を反復する場合に役立ちます。一般的に、リモートの更新と再起動は、完全な再構築とデプロイのサイクルよりもはるかに高速です。ファイルは、リモートクライアントが実行されている場合にのみ監視されます。リモートクライアントを開始する前にファイルを変更した場合、そのファイルはリモートサーバーにプッシュされません。特定の時間間隔でクラスの変更をポーリングし、事前定義された待機期間を待って、変更がないことを確認します。次に、変更がリモートアプリケーションにアップロードされます。遅い開発環境では、クワイエット期間が十分ではなく、クラスの変更がバッチに分割される場合があります。クラス変更の最初のバッチがアップロードされた後、サーバーが再起動されます。サーバーが再起動しているため、次のバッチをアプリケーションに送信できません。ログに、一部のクラスのアップロードの失敗に関する警告と、それに続く再試行によって明示されます。変更の最初のバッチがアップロードされた後、アプリケーションコードの不整合や再起動の失敗につながる可能性もあります。パラメーターを開発環境に合った値に増やしてみてください。spring.devtools.restart.poll-interval=2sspring.devtools.restart.quiet-period=1s監視対象のクラスパスフォルダーは2秒ごとにポーリングされて変更され、追加のクラス変更がないことを確認するために1秒の待機期間が維持されます。本番用にアプリケーションをパッケージ化する実行可能jarは、実動デプロイに使用できます。自己完結型であるため、クラウドベースのデプロイにも最適です。ヘルス、監査、メトリックRESTまたはJMXエンドポイントなどの追加の「本番対応」機能については、spring-boot-actuatorの追加を検討してください。詳細については、production-ready-features.htmlを参照してください。Bootの使用方法と、従うべきいくつかのベストプラクティスを理解する必要があります。Bootの機能の詳細を学ぶことができます。」の特徴について読むこともできます。