私のプロジェクトでは、
Foo foo = (Foo) beanFactory.getBean("name");
の中へ
Foo foo = beanFactory.getBean(Foo.class);
利点は明らかです。型の安全性、コードの複雑さの軽減、無駄な定数の削減などです。通常、このような行は、このような配線が唯一のオプションである静的なレガシー コンテキストに配置されます。
ある日、ユーザーから遅いと苦情が寄せられ、それがSpringの内部から来ていることが判明するまで、すべて順調でした。そこで、プロファイラーを起動して、
org.springframework.beans.factory.support.AbstractBeanFactory::doGetBean(String, Class<T>, Object[], boolean)
高価な呼び出しがある
Class.isAssignableFrom(anotherClass)
。
文字列名と型の検索の速度の違いが驚くほど大きいことを確認するために、小さなパフォーマンステストをすばやく作成しました。350回(私はStaticApplicationContext
このテストに使用していますFAIW)!
これを調べているうちに、SPR-6870投票数が多いのに、なぜか取り上げられていない。これが私をこの問題を解決するための試み状況は大幅に改善されましたが、まだ遅いです〜25文字列による検索よりも 100 倍も時間がかかります。この試みでは、問題の半分しか解決されないことがわかりました。Bean の名前をキャッシュして O(n) の反復を節約しますが、それでもisAssignableFrom
型を検証するための呼び出しを行う必要があります。
説明した問題は、私のシナリオに関連するだけでなく、使用する Bean にも関連しており@Autowired
、ループ内で Bean が作成される場合に困難に感じられる可能性があります。
解決策の 1 つは、Bean ファクトリ メソッドの 1 つをオーバーライドし、is-this-bean-of-the-same-type チェックの結果をキャッシュすることですが、明らかにこれは Spring で実行すべきであり、自分のコードでは実行すべきではありません。
他にも同様の問題に悩まされ、解決策を見つけた人はいますか?
ベストアンサー1
この問題はSpringで解決され、SPR-6870詳細については、解決策のコメントを参照してください。修正はバージョン 3.2.0.RELEASE および 3.1.2 以降で利用可能です。