縱觀java的開源框架，strtus,spring或者是springmvc等，他們的啓動都有個共同的特點就是在服務器啓動的時候預先加載進來相應的信息，初始化相關的類，他們或者用Servlet實現如sturts1和springmvc，或者用監聽器和過濾器，總之一切的準備工作都是對容器裏所有的類進行加載和調用的管理以及更好的解耦合。下面主要討論spring啓動的三種常見方式。
spring啓動可以選中監聽器也可以選擇過濾器一下要介紹的三種方式是：IntrospectorCleanupListener初始化spring容器，ContextLoadListener啓動spring及ContextLoaderServlet
IntrospectorCleanupListener簡介
spring中的提供了一個名爲org.springframework.web.util.IntrospectorCleanupListener的監聽器。它主要負責處理由 JavaBeans Introspector的使用而引起的緩衝泄露。spring中對它的描述如下：
它是一個在web應用關閉的時候,清除JavaBeans Introspector的監聽器.在web.xml中註冊這個listener.可以保證在web 應用關閉的時候釋放與掉這個web 應用相關的class loader 和由它管理的類
如果你使用了JavaBeans Introspector來分析應用中的類,Introspector 緩衝中會保留這些類的引用.結果在你的應用關閉的時候,這些類以及web 應用相關的class loader沒有被垃圾回收.
不幸的是,清除Introspector的唯一方式是刷新整個緩衝.這是因爲我們沒法判斷哪些是屬於你的應用的引用.所以刪除被緩衝的introspection會導致把這臺電腦上的所有應用的introspection都刪掉.
需要注意的是,spring 託管的bean不需要使用這個監聽器.因爲spring它自己的introspection所使用的緩衝在分析完一個類之後會被馬上從javaBeans Introspector緩衝中清除掉.
應用程序中的類從來不直接使用JavaBeans Introspector.所以他們一般不會導致內部查看資源泄露.但是一些類庫和框架往往會產生這個問題.例如:Struts 和Quartz.
單個的內部查看泄漏會導致整個的web應用的類加載器不能進行垃圾回收.在web應用關閉之後,你會看到此應用的所有靜態類資源(例如單例).這個錯誤當然不是由這個類自身引起的.
ContextLoaderListener簡介
與BeanFactory通常以編程的方式被創建不同的是，ApplicationContext能以聲明的方式創建，如使用ContextLoader。當然你也可以使用ApplicationContext的實現之一來以編程的方式創建ApplicationContext實例。首先，讓我們先分析ContextLoader接口及其實現。
ContextLoader接口有兩個實現：ContextLoaderListener和ContextLoaderServlet。兩者都實現同樣的功能，但不同的是，ContextLoaderListener不能在與Servlet 2.2兼容的web容器中使用。根據Servlet 2.4規範, servlet context listener要在web應用程序的servlet context建立後立即執行，並要能夠響應第一個請求(在servlet context要關閉時也一樣)：這樣一個servlet context listener是初始化Spring ApplicationContext的理想場所。雖然使用哪個完全取決於你，但是在同等條件下應該首選ContextLoaderListener；對於更多兼容性的信息，請查看ContextLoaderServlet的JavaDoc。
你可以象下面那樣使用ContextLoaderListener來註冊一個ApplicationContext：
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- or use the ContextLoaderServlet instead of the above listener
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
-->
監聽器首先檢查contextConfigLocation參數，如果它不存在，它將使用/WEB-INF/applicationContext.xml作爲默認值。如果已存在，它將使用分隔符（逗號、冒號或空格）將字符串分解成應用上下文將位置路徑。ContextLoaderServlet同ContextLoaderListener一樣使用'contextConfigLocation'參數。
ContextLoaderServlet簡介
先看看spring官方網上的信息：
Bootstrap servlet to start up Spring's root WebApplicationContext. Simply delegates to ContextLoader.
This servlet should have a lower load-on-startup value in web.xml than any servlets that access the root web application context.
Note that this class has been deprecated for containers implementing Servlet API 2.4 or higher, in favor of ContextLoaderListener.
According to Servlet 2.4, listeners must be initialized before load-on-startup servlets. Many Servlet 2.3 containers already enforce this behavior. If you use such a container, this servlet can be replaced with ContextLoaderListener. Else or if working with a Servlet 2.2 container, stick with this servlet.
（大意是說，這個servlet是啓動spring容器的一個servlet，必須把啓動優先級調到0，就是比所有的servlet都先啓動，ContextServlet最好用在servlet2.4或以上雖然2.3有支持）