A、春のIoCコンテナの概要
1.依存反転（DI）：得従属オブジェクトが反転されます。
管理の参照または依存パートナーが特定のオブジェクトによって行う場合には、高結合をもたらし、コードテスタビリティを低下させることができ、複雑なオブジェクト指向システムのために設計された非常に不利です。
春では、IoCコンテナ反転制御が対象において発生または直接オブジェクトの初期化に注入することができるパターンキャリア、に基づいて実施され、注射は、オブジェクトのデータ・フィールドを介して基準物体に注入することができますメソッドは、呼び出しを依存しています。この依存性は、オブジェクトが層ごとに注入され、再帰的です。
どのように反転制御に応じて、ビジネスの制御が通過特定のプラットフォームまたはフレームワークを見つけるオブジェクト、オブジェクト指向のシステム設計は、複雑さを低減し、オブジェクト指向システムのテスト容易性のために効果的なソリューションを増加させることです。これは、IoCのデザインパターンの開発は、コアの問題を解決するためのIoCコンテナで推進しています。
特定の依存性注入の主要な方法：インタフェース注射（タイプ1 IOC）、セッター注入（タイプ2 IOC）、コンストラクタインジェクション（タイプ3 IOC） 、春のIoC設計では、セッター注入とコンストラクタ噴射は、メイン噴射であります方法は、比較的に言えば、春のセッター注入の使用は、注射の一般的な方法であり、異常な注入を防止するために、スプリングIoCコンテナは、特定の依存関係のチェックを提供します。
第二に、IoCコンテナシリーズの設計と実装：たBeanFactoryとApplicationContextの
たBeanFactory単純なコンテナシリーズ：このシリーズのコンテナは、コンテナだけの最も基本的な機能を実現します。
ApplicationContextのコンテナハイシリーズ： ApplicationContextのアプリケーションコンテキスト、存在の同時期の先進的な形として。適応の多くをしながら、簡単なコンテナに基づいてアプリケーション・コンテキストは、フレームワーク指向のアプリケーション環境の機能の数を追加します。
IoCコンテナは、IoCコンテナのオブジェクト依存関係を管理するために使用され、BeanDefinitionオブジェクト依存反転モードは、データ抽象化の依存関係に管理されている、容器は、コア反転機能の実装に依存するデータ構造、依存反転機能であります行われ、このBeanDefinitionの取扱いを中心に展開。
図は、インターフェイスのデザインIoCコンテナで、我々はチャートから見ることができ、二つの主要な設計IoCコンテナのパスがあります。
インターフェイスからHierarchicalBeanFactory 1.たBeanFactoryは、その後ConfigurableBeanFactoryは、主要な設計たBeanFactory経路です。この設計では、インタフェースパスたBeanFactoryインタフェース定義基本仕様IoCコンテナ。インタフェース定義では、そのような基本的なIoCコンテナのgetBean（）メソッドを含む（豆容器から、この方法によって得ることができます）。
前記第2メインインターフェース設計は、コアとしてのApplicationContextコンテキストインタフェースアプリケーションインタフェース設計であり、メインインターフェース設計がここに関与している、たBeanFactoryからListableBeanFactory、その後のApplicationContextに、そして我々はWebApplicationContext又はConfigurableApplicationContextインタフェースを使用しました。たBeanFactory単純IoCコンテナに基づいて、ApplicationContextのインタフェース、継承MessageSource、ResourceLoader、ApplicationEventPublisherインタフェースを介して、のための容器の高度な特性のために多くの支持を追加します。
（A）、たBeanFactory
たBeanFactoryインタフェースは、IoCコンテナの最も基本的な形を定義し、我々は、底部と、基本的なプログラミング仕様、これらのインタフェース定義が続くするIoCコンテナを使用する理由であるIoCコンテナを同時に観察しなければならない基本的なサービス契約を提供しますIoCの基本的なアウトラインをチェック。
FactoryBeanのたBeanFactoryや使用頻度が高いが春に基づいています。彼らは、スペルに非常に似ています。ビーンであり、それは工場、すなわち、IoCコンテナまたはオブジェクトのファクトリです。春には、BeanがたBeanFactory（すなわちIoCコンテナ）で管理するすべてのです。しかし、FactoryBeanのが関係している、これは、単純なビーンビーンではなく、工場のモデルと変更モードの実装と設計モデルと同様に、Beanの工場の世代を生み出すか、オブジェクトを変更することができます。
たBeanFactory出典：
// // ソースコードはのIntelliJ IDEAでの.classファイルから再作成 // （Fernflower逆コンパイラによって供給） // パッケージorg.springframework.beans.factory。 輸入org.springframework.beans.BeansException。 輸入org.springframework.core.ResolvableType。 輸入org.springframework.lang.Nullable; パブリック インターフェイスたBeanFactory { 文字列FACTORY_BEAN_PREFIX = "＆" 。 getBean（文字列var1が）オブジェクトスローBeansException。 <T> T getBean（文字列VAR1、@Nullableクラス<T> VAR2）がスローBeansExceptionと、 オブジェクトgetBean（文字列VAR1、オブジェクト... VAR2）がスローBeansExceptionを。 <T> T getBean（クラス<T> VAR1）がスローBeansExceptionと、 <T> T getBean（クラス<T> VAR1、オブジェクト... VAR2）がスローBeansExceptionと、 ブールcontainsBean（文字列VAR1）。 ブール isSingleton（文字列VAR1）がスローNoSuchBeanDefinitionExceptionと、 ブール isPrototype（文字列VAR1）がスローNoSuchBeanDefinitionExceptionと、 ブール isTypeMatch（文字列VAR1、ResolvableType VAR2）がスローNoSuchBeanDefinitionExceptionと、 ブール isTypeMatch（文字列VAR1、@Nullableクラス<？> VAR2）がスローされますNoSuchBeanDefinitionException; @Nullable クラスは、 <？>のgetType（文字列VAR1）がスローNoSuchBeanDefinitionExceptionを。 文字列[] getAliases（ストリングVAR1）。 }
たBeanFactoryインタフェースを定義することによって、ユーザは、次の操作を実行できます。
1. getBean Beanのインターフェース方法を介して取得し、またBeanメソッドパラメータタイプによって確認することができます。
2.インターフェイスを介し方法containsBeanは、ユーザーがBeanの名前を含む容器を開発するかどうかを決定することを可能にします。
クエリインターフェイスメソッドに名前で指定されたかどうか3. isSingletonはシングルトンビーンの種類豆です。シングルトン属性の場合、ユーザーはBeanDefinitionを指定することができます。
指定された名前ビーンはプロトタイプで照会するインターフェイスメソッドを通じて4.んisPrototype。BeanDefinitionでユーザによって指定されてもよいシングルトンプロパティなど;
問い合わせへのインタフェースを介し方法isTypeMatchは、Beanクラスタイプの名前を指定します。5.は、特定のタイプのクラスです。タイプは、ユーザクラスによって指定されてもよいです。
豆のインターフェイスメソッドクラスタイプによって指定された名前を照会する6のgetType。
クエリ7. getAliasesは、インターフェースのメソッドを介してすべてのエイリアスビーンの名前を指定し、これらのエイリアスは、ユーザ定義BeanDefinitionです。
基本的な特性IoCコンテナの概要で定義されたこれらのインタフェースメソッド。
より明確たBeanFactoryがコンテナとして動作を理解するために、我々はBeanFanctory XmlBeanFactory実装クラスのソースコードを見て：
// // ソースコードはのIntelliJ IDEAでの.classファイルから再作成 // （Fernflower逆コンパイラによって供給） // パッケージorg.springframework.beans.factory.xml。 輸入org.springframework.beans.BeansException。 輸入org.springframework.beans.factory.BeanFactory。 輸入org.springframework.beans.factory.support.DefaultListableBeanFactory。 輸入org.springframework.core.io.Resource。 / ** @deprecated * / @Deprecated パブリック クラス XmlBeanFactoryは拡張DefaultListableBeanFactory { 民間 最終をXmlBeanDefinitionReaderリーダー。 公共 XmlBeanFactory（リソース資源）がスローBeansException { この（リソース（たBeanFactory）ヌル）。 } 公共 XmlBeanFactory（リソースリソースたBeanFactory parentBeanFactory）がスローBeansException { スーパー（parentBeanFactory）を、 この .readerは= 新しい XmlBeanDefinitionReaderを（この）; この.reader.loadBeanDefinitions（リソース）; } }
私達はちょうど基本的なまたはDefaultListableBeanFactoryの保有者により拡張へのアクセスにとして、そのようなApplicationContextの、その実現の基本的な原則とXmlBeanFactoryなどの他のIoCコンテナで、基底クラスDefaultListableBeanFactory、DefaultListableBeanFactoryのIoCを実現するために非常に重要であるとしてXmlBeanFactoryが使用されている参照します機能IoCコンテナ。
XmlBeanFactoryリファレンス実装では、我々はプログラム的DefaultListableBeanFactoryを使用します。私たちは、基本的なプロセスのいくつかのIoCコンテナを使用することがわかります。
パッケージcom.xyfer.controller。 輸入org.springframework.beans.factory.support.DefaultListableBeanFactory。 輸入org.springframework.beans.factory.xml.XmlBeanDefinitionReader。 輸入org.springframework.core.io.ClassPathResource。 パブリック クラスIoCDemo { 公共 静的 ボイドメイン（文字列[]引数）{ ClassPathResource RES = 新しい ClassPathResource（ "demo.xml" ）。 DefaultListableBeanFactory工場 = 新しいDefaultListableBeanFactory（）; XmlBeanDefinitionReaderリーダー = 新しいですXmlBeanDefinitionReader（工場）。 reader.loadBeanDefinitions（RES）。 } }
このように、我々は、ファクトリオブジェクトによって、このDefaultListableBeanFactory IoCコンテナを使用することができます。使用IoCコンテナでは、次の手順が必要です。
1.抽象リソースのIoCの設定ファイルを作成し、この抽象情報リソースはBeanDefinitionの定義が含まれています。
2. DefaultListableBeanFactoryここで使用したBeanFactoryを作成します。
3. BeanDefinitionの形態のXMLファイルをロードするためにここで使用されるXmlBeanDefinitionReaderロードさBeanDefinitionリーダーを、作成たBeanFactoryは、コールバックを通過するように構成されました。
位置定義されたリソース構成情報4.が読み出され、特定の構文解析プロセスはXmlBeanDefinitionReaderにより行います。Bean定義を全体の登録を完了し、ロードした後に必要なIoCコンテナを構築しました。今回は直接IoCコンテナを使用することができます。
（二）のApplicationContext
ApplicationContextのが意味IoCコンテナの高度な形態であるように、容器のApplicationContextたBeanFactoryを提供することに加えて、基本的な機能を提供するだけでなく、以下の追加のサービスをユーザに提供します。
ApplicationContextの継承から、我々は、異なるインタフェースを実装することで、追加異なる追加機能に基づいてのApplicationContextたBeanFactoryを見ることができます。
1.情報の異なるソースをサポートしています。ApplicationContextのはMessageSourceインタフェースがアプリケーションの多言語バージョンの開発のためのサービスを提供し、支持国際これらの情報源の機能を拡張して延びています。
2.访问资源。这一特性体现在对ResourceLoader和Resource的支持上，这样我们可以从不同的地方得到Bean定义资源。
3.支持应用事件。继承了接口ApplicationEventPublisher，从而在上下文中引入了事件机制。这些事件和Bean的生命周期的结合为Bean的管理提供了便利。
4.在ApplicationContext中提供的附加服务。这些服务使得基本IoC容器的功能更丰富。一般建议在开发应用时使用ApplicationContext作为IoC容器的基本形式。
三、IoC容器的初始化过程
简单来说，IoC容器的初始化是由refresh()方法启动的，这个方法标志IoC容器的正式启动。具体来说，这个启动包括BeanDefinition的Resource定位、载入和注册三个基本过程。
1.Resource定位过程。Resource定位指的是BeanDefinition的资源定位，它由ResourceLoader通过统一的Resource接口来完成，这个Resource对各种形式的BeanDefinition的使用都提供来统一的接口。在文件系统中的Bean定义信息可以使用FileSystemResource来进行抽象；在类路径中的Bean定义信息可以使用ClassPathResource来抽象。
2.BeanDefinition的载入。这个载入过程是把用户定义好的Bean表示成IoC容器内部的数据结构，而这个容器内部的数据结构就是BeanDefinition。具体来说，这个BeanDefinition实际上就是POJO对象在IoC容器中的抽象，通过这个BeanDefinition定义的数据结构，使IoC容器能够方便地对POJO对象也就是Bean进行管理。
3.向IoC容器注册这些BeanDefinition的过程。这个过程是通过调用BeanDefinitionRegistry接口的实现来完成的。这个注册过程把载入过程中解析得到的BeanDefinition向IoC容器进行注册。通过分析，我们可以看到，在IoC容器内部将BeanDefinition注入到一个HashMap中去，IoC容器就是通过这个HashMap来持用这些BeanDefinition数据的。
这里谈的是IoC容器初始化过程，这个过程一般不包含Bean依赖注入的实现。在Spring IoC的设计中，Bean定义的载入和依赖注入是两个独立的过程。依赖注入一般发生在应用第一次通过getBean向容器索取Bean的时候。但是又一个例外的配置，在使用IoC容器时有一个预实例化的配置，通过这个预实例化的配置（具体来说，可以通过为Bean定义信息中的lazyinit属性），可以对容器初始化过程做一个微小的控制，从而改变这个被设置了lazyinit属性的Bean的依赖注入过程。举例来说，如果我们对某个Bean设置了lazyinit属性，那么这个Bean的依赖注入在IoC容器初始化时就预先完成了，而不需要等到整个初始化完成以后，第一次使用getBean时才会触发。
四、IoC容器的依赖注入
IoC容器的初始化过程完成的主要工作在IoC容器中建立BeanDefinition数据映射。但是在此过程中IoC容器并没有对Bean的依赖关系进行注入。
当IoC容器已经载入了用户定义的Bean信息，容器中的BeanDefinition数据已经建立好的前提下，依赖注入的过程是在用户第一次向IoC容器索要Bean时触发的，也就是第一次调用getBean的时候触发，当然也有例外，就是当在BeanDefiniton中设置lazyinit属性来让容器完成对Bean的预实例化。这个预实例化实际上也是一个完成依赖注入的过程，但是这个依赖注入的过程是在初始化的过程中完成的。
getBean是依赖注入的起点，之后会调用createBean，Bean对象会依据BeanDefinition定义的要求生成。createBean不但生成了需要的Bean，还对Bean初始化进行了处理，比如实现了在BeanDefinition中的init-method属性定义，Bean后置处理器等。CGLIB是一个常用的字节码生成器的类库，它提供了一系列的API来提供生成和转换JAVA的字节码的功能。在Spring AOP中也使用CGLIB对JAVA的字节码进行增强。在IoC容器中，Spring通过默认类SimpleInstantiationStrategy类来生成Bean对象，它提供了两种实例化Java对象的方法，一种是通过BeanUtils，它使用了JVM的反射功能，一种是通过CGLIB来生成。
在实例化Bean对象生成的基础上，接下来就是各种依赖关系的处理。通过对BeanDefinition中的对象、value值、List、Map等进行解析，然后使用反射对属性进行注入。
在Bean的创建和对象依赖注入的过程中，使用递归在上下文体系中查找需要的Bean和创建Bean；在依赖注入时，通过递归调用容器的getBean方法，得到当前Bean的依赖Bean，同时也触发对依赖Bean的创建和注入。在对Bean的属性进行依赖注入时，解析的过程也是递归的过程。这样，根据依赖关系，一层一层地完成Bean的创建和注入，直到最后完成当前Bean的创建。有了这个顶层Bean的创建和对它的属性依赖注入的完成，意味着和当前Bean相关的整个依赖链的注入也完成了。
五、IoC容器的其他相关特性
1.ApplicationContext和Bean的初始化及销毁
Bean的生命周期
(1)Bean实例的创建
(2)为Bean实例设置属性
(3)调用Bean的初始化方法
(4)应用可以通过IoC容器使用Bean
(5)当容器关闭时，调用Bean的销毁方法
2.lazy-init属性和预实例化
3.FactoryBean的实现
4.BeanPostProcessor的实现
5.autowiring（自动依赖装配）的实现
配置autowiring属性，IoC容器会根据这个属性的配置，使用反射自动查找属性的类型或者名字，然后基于属性的类型或名字来自动匹配IoC容器中的Bean，从而自动地完成依赖注入。
6.Bean的依赖检查
Spring通过依赖检查特性，帮助应用检查是否所有的属性都已经被正确设置。在Bean定义时设置dependency-check属性来指定依赖检查模式即可。属性可以设置为none、simple、object、all四种模式，默认的模式是none。