序文
この記事では、主に春のルックアップ（メソッドインジェクション）に関する関連するコンテンツを紹介します。参照と学習のために共有されます。以下ではあまり言いません。詳細な紹介を一緒に見てみましょう。
これは、Springを使用するときに発生する可能性があります。1つのシングルトンビーンは、別の非シングルトンビーンに依存します。自動アセンブリを使用して依存関係を注入するだけの場合、以下に示すように、いくつかの問題が発生する場合があります。
シングルトンのクラスA
@componentpublic class classa {@autowired private classb classb; public void printclass（）{system.out.println（ "これはクラスA：" + this）; classb.printclass（）; }}非シングルのクラスB
@component@scope（value = scope_prototype）public classb {public void printclass（）{system.out.println（ "これはクラスB：" + this）; }}ここでは、クラスAはデフォルトのシングルトンの範囲を採用し、クラスBに依存しています。クラスBの範囲はプロトタイプであるため、シングルトンではありません。現時点では、テストを実行した後、このような書く問題を確認できます。
@runwith（springrunner.class）@contextconfiguration（classs = {classa.class、classb.class}）public class mytest {@autowired private classa classa; @test public void simpletest（）{for（int i = 0; i <3; i ++）{classa.printclass（）; }}}出力の結果は次のとおりです。
これはクラスA：classa@282003e1です
これはクラスB：classB@7fad8c79です
これはクラスA：classa@282003e1です
これはクラスB：classB@7fad8c79です
これはクラスA：classa@282003e1です
これはクラスB：classB@7fad8c79です
ご覧のとおり、両方のクラスのハッシュコードは3つの出力で同じです。シングルトンであるため、クラスAの価値は変わらないことは理解できますが、クラスBの範囲はプロトタイプですが、シングルトンになったように見えるハッシュコードも変わらないようにしますか？
この状況の理由は、クラスAのスコープがデフォルトのシングルトンであるため、コンテキストはクラスAの豆のみを1回しか作成しないため、依存関係を注入する可能性は1つだけで、コンテナはクラスAに毎回新しいクラスBを提供できません。
それほど良くない解決策
上記の問題を解決するために、アプリケーションContextAwareを実装するためにクラスAにいくつかの変更を加えることができます。
@componentPublic classa ClassaはApplicationContextAware {private applicationContext ApplicationContext; public void printclass（）{system.out.println（ "これはクラスA：" + this）; getClassB（）。printClass（）; } public classb getClassB（）{return applicationContext.getBean（classb.class）; } public void setApplicationContext（applicationContext ApplicationContext）throws beansexception {this.applicationContext = applicationContext; }}このようにして、クラスBに行く必要があるたびに、コンテキストで新しい豆を手動で見つけることができます。別のテストを実行した後、次の出力を取得しました。
これはクラスA：com.devhao.classa@4df828d7です
これはクラスB：com.devhao.classb@31206bebです
これはクラスA：com.devhao.classa@4df828d7です
これはクラスB：com.devhao.classb@3e77a1edです
これはクラスA：com.devhao.classa@4df828d7です
これはクラスB：com.devhao.classb@3ffcd140です
クラスAのハッシュコードは3つの出力では変更されていませんが、クラスBは毎回異なることがわかります。これは、問題が解決され、新しいインスタンスが呼び出されるたびに使用されることを示しています。
ただし、この執筆方法はスプリングと強く結合されており、春は侵襲性を低下させる別の方法を提供します。
@見上げる
Springは、 @Lookupと呼ばれる注釈を提供します。これは、メソッドで機能する注釈です。それによってマークされた方法はオーバーライドされます。次に、リターン値のタイプに従って、コンテナはBeanFactoryのGetBean（）メソッドを呼び出してBeanを返します。
@componentPublic classa {public void printclass（）{system.out.println（ "これはクラスA：" + this）; getClassB（）。printClass（）; } @lookup public classb getClassB（）{return null; }}それははるかにシンプルで、春と強く結合しなくなったことがわかります。テストを再度実行すると、正しい出力を取得できます。
コンテナがサブクラスを動的に生成し、注釈付きメソッドを書き換え/実装するため、注釈付きメソッドの返品値はもはや重要ではありません。
使用される@lookupメソッドは、次の署名に準拠する必要があります。
<public | Protected> [要約] <Return-Type> themethodname（argumentsなし）;
要約します
上記は、この記事のコンテンツ全体です。この記事の内容には、すべての人の研究や仕事に特定の参照値があることを願っています。ご質問がある場合は、メッセージを残してコミュニケーションをとることができます。 wulin.comへのご支援ありがとうございます。