春の配線は、私のプロジェクトで名前

Question

により、配線よりも大きさによっても遅いですが、私は

Foo foo = beanFactory.getBean(Foo.class); 

に

Foo foo = (Foo) beanFactory.getBean("name"); 

のすべての使用を移行しようとしている利点は明白です：型の安全性、あまり複雑でないコード、より少ない無駄な定数などを含む。典型的には、そのような線は、そのような配線が唯一の選択肢である静的な従来の状況に位置する。

これは、ある日、ユーザーがSpring内部から来たことが判明した遅さについて文句を言うまでは問題ありませんでした。だから私は

Class.isAssignableFrom(anotherClass)に高価な呼び出しがあり

org.springframework.beans.factory.support.AbstractBeanFactory::doGetBean(String, Class<T>, Object[], boolean)

にホットスポットを見つけるために、プロファイラを解雇しました。

は、私はすぐに（私はこのテストFAIWためStaticApplicationContext使用しています）回百日咳される文字列の名前と型の検索の速度差を調べるために、小さなパフォーマンステストを作成しました！

これを調べているうちに、投票数の多いSPR-6870が見つかりましたが、何らかの理由で対処されていません。これで私はan attempt to solve this problemになりましたが、これは状況を大幅に改善しますが、まだ遅いです〜25回の文字列による検索より！ O（n）反復で保存するためにBeanの名前をキャッシュしますが、依然としてisAssignableFromを呼び出して型を検証する必要があります。

説明した問題は私のシナリオに関連するだけでなく、@Autowiredを使用する豆のためでもあり、ループ内に豆が作成されている場合には苦に感じることがあります。

解決策の1つは、Beanファクトリメソッドの1つをオーバーライドして同じタイプのチェック結果をキャッシュすることですが、これはSpringで行い、自分のコードで行うべきではありません。

似たような問題に悩んでいる人は誰ですか？その解決策が見つかりましたか？

Answer 1

ほとんどのSpringアプリケーションは、実行時にコンテキストからBeanを取得するのではなく、起動時に物事をまとめます。アプリケーションの通常の実行中にアプリケーションコンテキストを頻繁に変更しない限り、Beanを複数回フェッチしてはいけません。

ユーザーが遅を訴えている場合、あなたの本当の問題は、あまりにも多くの豆のルックアップであるようだ、ということを考えると、より遅い手段を使用することで、実際の問題が浮上したばかりです。私は（Javaであなたの依存関係を設定し、春3.0でサポートされている、私は信じている）は、Javaコンフィグに移動すると、起動時にすべてのBeanを配線するにアプリを設定しようとするだろう

。これはまた、依存関係が満たされない場合、あなたのアプリが起動しないという利点もあります。

Answer 2

この問題は、今SPR-6870の分解能で春に解決されます。詳細については、そこの解決コメントを参照してください。この修正は、バージョン3.2.0.RELEASEおよび3.1.2以降で使用できます。