春の循環依存問題を解決するには?

序文

昨日は、Spring の循環依存とその理由について話しましたが、今日は、Spring の循環依存の問題を解決する方法についてお話します。前回の記事で述べたように、セッター メソッドによる依存性注入によって生成された、シングルトン モードで生成された循環依存性の問題のみが解決されますか?

Springはシングルトンモードで循環依存をどのように解決しますか?

実際、重要なことは、作成中のシングルトン インスタンスを事前に公開することです。

シングルトン モードでの Setter 割り当ての循環依存

図に示す例では、A は B に依存し、B は C に依存し、C は B に依存します。
プロセスは次のとおりです。

1. A を作成し、コンストラクターを呼び出して構築を完了し、プロパティ割り当ての挿入を実行し、依存関係 B を見つけて、B をインスタンス化します。
2. B を作成し、コンストラクターを呼び出して構築を完了し、プロパティ割り当ての挿入を実行し、依存関係 C を見つけて、C をインスタンス化します。
3. C を作成し、コンストラクターを呼び出して構築を完了し、属性割り当て注入を実行して、A への依存関係を見つけます。

   これが循環依存を解決する鍵となります. A は構築メソッドによって構築されている. つまり Bean のメモリはヒープに割り当てられているので, A が属性値を補充しても変化しないからです.そのメモリ アドレス、したがって、この時点で、A の参照を事前に取り出して、C のインスタンス化を完了することができます。

したがって、このメソッドを使用すると、c の作成プロセスは次のようになります。 4. C を作成し、構築メソッドを呼び出し、構築を完了して属性割り当て注入を実行し、A への依存関係を見つけ、A も構築され、直接参照し、C を完了します。インスタンス化されます。5. C がインスタンス化を完了した後、B に注入し、B もインスタンス化を完了し、次に B が A に注入し、A もインスタンス化を完了します。
作成中のシングルトン Bean を取得するために、Spring は 3 レベルのキャッシュを提供して作成中の Bean を事前に公開し、シングルトン モードでの Setter 割り当ての循環依存問題を解決します。プロセスを図に示します。

Spring の 3 つの主要なキャッシュ:

Spring にはシングルトン Bean インスタンスを格納するために使用される 3 つのキャッシュがあります; これら 3 つのキャッシュは相互に排他的であり、同じ Bean インスタンスを同時に格納することはありません。

getBean を呼び出す場合、指定された Bean インスタンスを 3 つのキャッシュから順次取得する必要があります。読む順番は次のとおりです。

レベル 1 キャッシュ --> レベル 2 キャッシュ --> レベル 3 キャッシュ

• レベル 1 キャッシュ、singletonObjects シングルトン キャッシュ、インスタンス化されたシングルトン Bean (作成済み) を格納します。
• 2 番目のレベルのキャッシュはearlySingletonObjects 、事前に公開されたシングルトン キャッシュです。そこに格納されている Bean は構築されたばかりですが、後で属性を介して Bean が注入されます (Bean は事前に参照されますが、Bean はまだ作成中です)。
• レベル 3 キャッシュ、singletonFactories シングルトンを生成するためのファクトリ キャッシュ、およびストレージ ファクトリ (作成中)。

要約する

Spring の 3 つのキャッシュ メソッドは、シングルトン モードでの循環依存の問題を解決するために使用されますが、他のシナリオで発生する依存関係の問題は解決できず、エラーが報告されます。