ばね容器

DispatchServletで生成された大量のオブジェクトはどこで管理されますか?
DispatcherServiceletによって生成された多くのオブジェクトは、ApplicationContextによって管理されます.これはIoCです.
ApplicationContext
IoCは制御の逆転を意味する.開発者がnewで直接オブジェクトを作成する場合、そのオブジェクトを指す参照変数を管理するのは難しいです.したがって、スプリングはオブジェクトを直接管理します.この時、住所を知らなくてもいいです.必要なときはDIで良いので
DIを依存注入と呼ぶ.必要な場所でApplicationContextにアクセスして、必要なオブジェクトを取得できます.ApplicationContextはモノトーンなので、どこからアクセスしても同じオブジェクトであることが保証されます.
ApplicationContextには2種類あります(Root-APplicationContextとサーブレット-アプリケーションContext).
スプリングガイドの操作手順を見てみましょう

クライアントからの要求

猫が反応(スプリング起動には静的リソースがなくapacheを無視)
web.DispatchServiceletはxmlからスプリング内部

に入る.
DispatchServiceletは、この操作を実行する前にステップがあります.
要求に応じてサーブレットを作成すると、スレッドが作成されます.
スレッドの作成は負荷がかかりやすいと言えます.
したがって、各スレッドには共通のスレッドがあります.
これがDB接続です.
あるいは、すべてのスレッドで共通に使用できるのは
Context Loader Listerが発行します.(root ApplicationContextという名前のファイルを読みます.)
a.servlet-APplicationContext(Web関連情報のみを含む=>Web関連技術スキャン)
サーブレット-APplicationContextは、ViewResolver、Interceptor、およびMultipartResolverオブジェクトを生成し、Web関連のオペレーティングコントローラおよびRestControllerをスキャンします.
==============>>DispatcherServiceletがファイルを実行します.
b.root-applicationContext(db関連オブジェクトの作成をiocメモリにアップロード)
root-applicationContextは、その名称以外の名称サービス、Repositoryなどをスキャンし、DB関連オブジェクトを生成する.(スキャンはメモリにロードすることを意味します)
============>>ContextLoaderListenerがファイルを実行します.ContextLoaderListenerを実行する奴はWebxmlなのでroot-applicationContextはservlet-applicationContextの前にロードされます.
もちろん、サーブレット-APplicationContextはroot-applicationContextによってロードされたオブジェクトを参照できますが、逆にはできません.生成時間が違うからです.

ApplicationContextで必要なオブジェクトを登録する必要はありません
Bean Factory
必要なオブジェクトをbeanファクトリに登録することもできます.ここで登録すると、初期にメモリにロードするのではなく、必要に応じてgetBean()メソッドで呼び出してメモリにロードできます.これもIoCです.また、必要に応じてDIを使用することができます.ApplicationContextとは異なり、Bean Factoryにロードされたオブジェクトは、事前にロードされたものではなく、必要に応じてロードが呼び出されるため、ロードが遅延します.
@Configurationを示すクラスがあります
このクラスは@Configurationを表し、素子をスキャンするときにメモリに表示されます.
この中にオブジェクトを返す方法がある場合は、@Beanを使用してメモリに格納できます.

 @Configuration
 class a {
 	@Bean
 	객체 메소드(){
    	return 객체
    } 
 }

ソース:https://getinthere.tistory.com/11