Spring和SpringMVC作為Bean管理容器和MVC層的預設框架，已被眾多WEB應用採用，而實際使用時，由於有了強大的註解功能，很多基於XML的配置方式已經被替代，但是在實際專案中，同時配置Spring和SpringMVC時會出現一些奇怪的異常，比如Bean被多次載入，多次例項化，或者依賴注入時，Bean不能被自動注入，但是明明你已經將該Bean註冊了的。找原因還是要看問題的根源，我們從容器說起。

在Spring整體框架的核心概念中，容器是核心思想，就是用來管理Bean的整個生命週期的，而在一個專案中，容器不一定只有一個，Spring中可以包括多個容器，而且容器有上下層關係，目前最常見的一種場景就是在一個專案中引入Spring和SpringMVC這兩個框架，其實就是2個容器，Spring是根容器，SpringMVC是其子容器，並且在Spring根容器中對於SpringMVC容器中的Bean是不可見的，而在SpringMVC容器中對於Spring根容器中的Bean是可見的，也就是子容器可以看見父容器中的註冊的Bean，反之就不行。理解這點很重要，因為這是一個規則，是Spring自己設定的，但是往下看，我們會發現有些地方它並不預設使用這個規則。

當我們使用註解時，對於Bean註冊這個功能的實現就不需要在給每個Bean配置XML了，只要使用統一的如下配置即可。

根據Spring提供的參考手冊，該配置的功能是掃描預設包下的所有的@Component註解，並且自動註冊到容器中，同時也掃描@Controller，@Service，@Respository這三個註解，他們是繼承自@Component。

除了以上我們使用的掃描配置，在專案中我們經常見到的就是<context:annotation-config/>這個配置，其實有了以上的配置，這個是可以省略掉的。

還有一個SpringMVC相關的是<mvc:annotation-driven />配置，經過驗證，這個是必須要配置的，因為它是和@RequestMapping結合使用的，這裡補充下SpringMVC框架相關的知識點。

HandlerMapping，是SpringMVC中用來處理Request請求URL到具體Controller的，其自身也分成很多種類；  HandlerAdapter，是SpringMVC中用來處理具體請求對映到具體方法的，其自身也分很多種類；

@RequestMapping這個註解的主要目的就是對具體的Controller和方法進行註冊，以方便HandlerMapping用來處理請求的對映。但是@RequestMapping需要結合<mvc:annotation-driven />使用才能生效。

好了，有了以上基礎知識的鋪墊，我們看下現在這樣的一個使用場景中，Spring與SpringMVC的容器衝突的原因在那裡！

Spring配置檔案applicationContext.xml，SpringMVC配置檔案applicationContext-MVC.xml，這樣專案中就有2個容器了，配置方式A，如下：

applicationContext.xml中配置了<context:component-scan base-package=“com.test" />，負責所有需要註冊的Bean的掃描工作，applicationContext-MVC.xml中配置<mvc:annotation-driven />，負責springMVC相關注解的使用，啟動專案發現，springMVC失效，無法進行跳轉，開啟log的DEBUG級別進行除錯，發現springMVC容器中的請求好像沒有對映到具體controller中；

配置方式B，如下：

為了快速驗證效果，將<context:component-scan base-package=“com.test" />掃描配置到applicationContext-MVC.xml中，重啟後，驗證成功，springMVC跳轉有效。

要想檢視具體原因，翻看原始碼，從springMVC的DispatcherServlet開始看，在一個請求進來之後，發生了什麼？漫長的檢視之後，找到原因，如下。

springMVC初始化時，會尋找所有當前容器中的所有@Controller註解的Bean，來確定其是否是一個handler，而當前容器springMVC中註冊的Bean中並沒有@Controller註解的，注意，上面提及的配置方式A，所有的@Controller配置的Bean都註冊在Spring這個父容器中了，看程式碼。

protected void initHandlerMethods() {
        if (logger.isDebugEnabled()) {
            logger.debug("Looking for request mappings in application context: " + getApplicationContext());
        }
        String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ?
                BeanFactoryUtils.beanNamesForTypeIncludingAncestors(getApplicationContext(), Object.class) :
                getApplicationContext().getBeanNamesForType(Object.class));
        for (String beanName : beanNames) {
            if (isHandler(getApplicationContext().getType(beanName))){
                detectHandlerMethods(beanName);
            }
        }
        handlerMethodsInitialized(getHandlerMethods());
    }

在方法isHandler中會判斷當前bean的註解是否是controller，程式碼如下：

protected boolean isHandler(Class<?> beanType) {
        return AnnotationUtils.findAnnotation(beanType, Controller.class) != null;
    }

在配置方式B中，springMVC容器中包括了所有的@Controller註解的Bean，所以自然就能找到了。

以上是原因，解決辦法是什麼？注意看initHandlerMethods()方法中，detectHandlerMethodsInAncestorContexts這個Switch，它主要控制從那裡獲取容器中的bean，是否包括父容器，預設是不包括的。所以解決辦法是有的，即在springMVC的配置檔案中配置HandlerMapping的detectHandlerMethodsInAncestorContexts屬性為true即可（這裡需要根據具體專案看使用的是哪種HandlerMapping），讓其檢測父容器的bean。如下：

<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
        <property name="detectHandlerMethodsInAncestorContexts">
            <value>true</value>
        </property>
    </bean>

以上已經有了2種解決方案了，但在實際工程中，會包括很多配置，根據不同的業務模組來劃分，所以我們一般思路是各負其責，明確邊界，Spring根容器負責所有其他非controller的Bean的註冊，而SpringMVC只負責controller相關的Bean的註冊。第三種方案如下：

Spring容器配置，排除所有@controller的Bean

SpringMVC容器配置，讓其只包括@controller的Bean

個人比較推薦第三種方案。引申一下，專案中使用事務的配置方案，也會在這種場景下失效，歸根結底也是由於2個容器的可見性問題導致，可以結合具體問題按照上面的思路進行查詢原因！

引用一下海濤的部落格中的一張圖。 原圖地址http://jinnianshilongnian.iteye.com/blog/1602617