私が初めて Spring を使い始めたとき、最も興味をそそられた概念の 1 つは Bean スコープの概念でした。 Spring は、Spring コンテナ内で作成される Bean のライフサイクルを決定するさまざまな Bean スコープを提供します。最も一般的に使用される 2 つのスコープは、Singleton と Prototype です。これらのスコープを理解することは、効率的かつ効果的な Spring アプリケーションを設計するために重要です。そのため、それらについて私が学んだことを順に説明していきます。

Spring Bean のスコープを理解する

Spring では、Bean は Spring IoC (制御の反転) コンテナーによってインスタンス化、アセンブル、および管理されるオブジェクトです。 Bean スコープは、Bean のライフサイクル、つまり Bean インスタンスがいつ、どのように作成され、どれくらいの期間存続するかを指します。

Spring はいくつかの Bean スコープを提供しますが、ここでは次の 2 つに焦点を当てます。

• シングルトン スコープ
• プロトタイプのスコープ

各スコープには固有の使用例があり、適切な使用例を選択すると、アプリケーションの動作とパフォーマンスに大きな影響を与える可能性があります。

シングルトンスコープ

Singleton スコープは Spring のデフォルトのスコープであり、私が最も頻繁に使用するスコープです。 Bean が Singleton スコープで定義されている場合、Spring コンテナはその Bean のインスタンスを 1 つだけ作成し、この単一のインスタンスがアプリケーション コンテキスト全体で共有されることを意味します。

仕組み

Bean をシングルトンとして宣言すると、Spring はアプリケーション コンテキストの起動中または最初の参照時に、Bean インスタンスが最初に要求されたときに Bean インスタンスを作成します。その後、この Bean に対する後続のリクエストはすべて同じインスタンスを返します。

これが簡単な例です:

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

この例では、myService() はシングルトン Bean です。 Spring コンテキストから MyService Bean をリクエストするたびに、同じインスタンスを取得します。

シングルトン Bean の使用例

シングルトン スコープはステートレス Bean、つまりクライアント固有の情報を保持しない Bean に最適であることがわかりました。例:

• サービス クラス: 通常、これらのクラスには、個別のインスタンスを必要とせずにアプリケーション全体で共有できるビジネス ロジックが含まれています。
• DAO クラス: 通常、これらはデータベースと対話し、クライアント固有の状態を維持しないため、単一のインスタンスで十分です。

利点と考慮事項

シングルトン Bean の主な利点はメモリ効率です。単一のインスタンスを再利用することで、アプリケーションが消費するメモリが減り、オブジェクトの作成と破棄のオーバーヘッドが最小限に抑えられます。ただし、状態を維持するシングルトン Bean には注意することが重要です。シングルトン Bean が誤って状態 (インスタンス変数など) を保持すると、この状態が複数のクライアント間で共有される可能性があり、データの不整合が生じる可能性があります。

プロトタイプの範囲

Singleton とは対照的に、Prototype スコープは、Spring コンテナから Bean がリクエストされるたびに新しい Bean インスタンスを作成します。これについて学んだとき、プロトタイプ Bean が、使用するたびに新しいインスタンスが必要なシナリオに役立つことは明らかでした。

仕組み

Bean が Prototype スコープで定義されている場合、Spring は Bean がリクエストされるたびに新しいインスタンスを返します。プロトタイプ Bean を定義する方法は次のとおりです:

@Configuration
public class AppConfig {
    @Bean
    @Scope("prototype")
    public MyService myService() {
        return new MyService();
    }
}

この例では、Spring コンテキストから MyService Bean をリクエストするたびに、Spring は MyService の新しいインスタンスを作成します。

プロトタイプ Bean の使用例

プロトタイプ Bean は、ステートフル Bean を扱う場合に特に役立ちます。ステートフル Bean は、ある種のクライアント固有の状態を維持したり、使用ごとに固有の構成を必要としたりします。典型的な使用例には次のようなものがあります:

• コマンド オブジェクト: 各コマンドが個別に実行され、独自の状態を維持するコマンドのようなパターンを実装している場合は、プロトタイプ Bean が正しい選択です。
• セッションまたはリクエストのスコープ Bean: Web アプリケーションでは、ユーザー セッションまたはリクエストに固有の Bean をプロトタイプとして定義して、ユーザーまたはリクエストごとに新しいインスタンスが作成されるようにすることができます。

利点と考慮事項

プロトタイプ Bean を使用する主な利点は、新しいインスタンスを作成する際の柔軟性です。これは、ステートフル オブジェクトを扱う場合に特に便利です。ただし、パフォーマンスとリソース使用量に関してはトレードオフがあります。毎回新しいインスタンスが作成されるため、メモリ消費量が増加し、ガベージ コレクションがより頻繁に発生する可能性があります。さらに、シングルトン Bean とは異なり、Spring は作成後のプロトタイプ Bean のライフサイクルを管理しないため、これらの Bean の破棄とクリーンアップを手動で処理する必要があります。

シングルトンとプロトタイプ: 適切なスコープの選択

Spring アプリケーションを設計するときに直面する重要な決定の 1 つは、シングルトン スコープとプロトタイプ スコープのどちらを選択するかです。私が考慮する要素の要約は次のとおりです:

• ステートフルネス: Bean がステートレスである場合、通常はシングルトンが最良の選択です。ステートフル Bean の場合は、プロトタイプの方が適切です。
• リソース管理: シングルトン Bean は、インスタンスが 1 つだけ維持されるため、メモリ効率が高くなります。プロトタイプ Bean は柔軟性が高くなりますが、より多くのリソースを消費します。
• ライフサイクル管理: シングルトン Bean は、ライフサイクル全体にわたって Spring コンテナによって管理されます。対照的に、プロトタイプ Bean のライフサイクル全体を管理する必要があります。

実践例

各スコープをいつ使用するかを明確にするのに役立つ実用的なシナリオを紹介します。オンライン ショッピング アプリケーションを構築しているとします。

• ショッピング カート サービス: このサービスは通常ステートレスであり、シングルトン Bean の適切な候補となります。毎回新しいインスタンスを作成する必要はなく、同じサービスで複数のリクエストを処理できます。
• 注文処理: 一方、顧客の注文を表す Order オブジェクトはステートフルであり、その注文に固有の詳細を保持します。したがって、各注文が Order クラスの個別のインスタンスによって処理されるように、これはプロトタイプ Bean である必要があります。

スコープの混合: 注意事項

私が苦労して学んだことの 1 つは、シングルトン Bean とプロトタイプ Bean を混在させると予期せぬ問題が発生する可能性があるということです。たとえば、プロトタイプ スコープの Bean をシングルトン Bean に注入すると、シングルトン Bean は常にプロトタイプ Bean の同じインスタンスを使用することになります。これを避けるために、私は通常、プロバイダーを注入するか、@Lookup アノテーションを使用して、プロトタイプ Bean の新しいインスタンスが必要になるたびに確実に作成されるようにします。

@Service
public class SingletonService {

    @Autowired
    private Provider myPrototypeServiceProvider;

    public void usePrototypeService() {
        MyPrototypeService prototypeService = myPrototypeServiceProvider.get();
        prototypeService.execute();
    }
}

この例では、myPrototypeServiceProvider.get() により、Singleton Bean 内で呼び出されるたびに MyPrototypeService の新しいインスタンスが作成されることが保証されます。

さようなら ！

Spring のシングルトン Bean スコープとプロトタイプ Bean スコープの微妙な違いを理解することは、開発者としての私の歩みにおいて非常に重要でした。どちらのスコープにも、ユースケースに応じて明確な利点があり、適切なスコープを選択すると、アプリケーションのパフォーマンスと設計に大きな影響を与える可能性があります。

私の経験では、シングルトンはその効率性とシンプルさのため、ほとんどの Bean にとって頼りになるスコープですが、プロトタイプは毎回新しいインスタンスが必要になる特殊なケースのために予約されています。 Bean のステートフル性とアプリケーション内での Bean の使用方法を慎重に検討することで、情報に基づいた意思決定を行うことができ、より優れた、より保守しやすい Spring アプリケーションを実現することができます。