 |
|
|
| 1 2 3 次のページ
|
|
| はじめに
|
今回はDI処理についてお伝えする予定でしたが、その前に前回のフォローとしてinit処理とprototypeについて解説していきます。
|
| Seasar2でのinit処理
|
Seasar2にはinit処理というものがあります。init処理では設定ファイルから取得したコンポーネントを初期化して、singleton（注1）のコンポーネントを生成することができます。
※注1：
DIコンテナはいくつかのインスタンスモードを持ち、singletonはその1つです。singletonのコンポーネントは1度だけ生成され、コンテナから取得するたびに常に同じインスタンスが返されます。
init処理あり／なしのそれぞれでの処理をまとめると、表1、2のようになります。
| 処理 |
順番 |
Seasar2 |
| コンテナ生成時に行う処理 |
1 |
SAXパーサを使用してXMLを読み込む |
| 2 |
コンポーネントのリフレクション情報をキャッシュする |
| コンポーネント取得時に行う処理 |
1 |
コンテナ生成でリフレクション情報はキャッシュ済み |
| 2 |
コンポーネントを生成する |
| 3 |
生成したコンポーネントを返却する |
表1：Seasar2のinit処理を行わない場合（前回）
| 処理 |
順番 |
Seasar2 |
| コンテナ生成時に行う処理 |
1 |
SAXパーサを使用してXMLを読み込む |
| 2 |
コンポーネントのリフレクション情報をキャッシュする |
| 3 |
singletonのコンポーネントを生成する |
| コンポーネント取得時に行う処理 |
1 |
生成済みのコンポーネントを返却する |
表2：Seasar2のinit処理を行う場合
実は第1回で紹介した測定結果はinit処理を行っていません。しかし実際の案件では、アプリケーション初期化時にinit処理する方が効率的です。それはコンテナからのコンポーネント取得処理は、アプリケーションへ利用者がアクセスしたタイミングで行われるためです。
ではinit処理を加えるとSeasar2でのコンテナ生成・コンポーネント取得の速度はどれくらい変わるのでしょうか。表1、2を見ると処理がコンテナ生成時へ移っているので、コンテナ生成が遅くなりコンポーネント取得が速くなると予想できます。
なおSpringにおいてもコンテナにApplicationContextを使用すると、Seasar2のinit処理と同様にコンテナ生成時にsingletonコンポーネントを生成できますので、あわせて測定を行います。
|
| 測定プログラム
|
測定プログラムは第1回とほとんど同じで、Seasar2のコンテナ生成処理にinitを呼ぶ1行を追加します（前回コメントアウトした行は白で示した部分です）。
プログラム（Seasar2）
long start = System.currentTimeMillis();
S2Container container = S2ContainerFactory.create("(設定ファイルへのパス)");
container.init();
long end = System.currentTimeMillis();
// end - startを記録
プログラム（Spring）
long start = System.currentTimeMillis();
BeanFactory factory = new ClassPathXmlApplicationContext("(設定ファイルへのパス)");
long end = System.currentTimeMillis();
// end - startを記録
SpringもXmlBeanFactoryの代わりにApplicationContextのサブクラスであるClassPathXmlApplicationContextを使うように、1行変更しました。
|
1 2 3 次のページ
|
|
|
|
|
|
|
|
|
著者プロフィール
株式会社アークシステム 本間 宏崇
プログラマ。2004年より(株)アークシステムに所属。最近の興味はペアプログラミング・テスト駆動開発・プロジェクト自動化など。現在はWebアプリケーションフレームワーク「Teeda
（http://teeda.seasar.org/ja/）」の開発に携わっている。
|
|
|
|
|
著者プロフィール
日本ヒューレット・パッカード株式会社
今回、Seasar2とSpringのパフォーマンスの検証を行う際の環境を提供しています。
|
|
|
|
|
|
