Java面試題（史上最全）

時間 2021-04-03

標籤 html 前端 java git 程序員 github web 面試 ajax 正則表達式欄目 Java 简体版

原文原文鏈接

文章很長，建議收藏起來，慢慢讀! 瘋狂創客圈爲小夥伴奉上如下珍貴的學習資源：html

瘋狂創客圈經典圖書：《Netty Zookeeper Redis 高併發實戰》面試必備 + 大廠必備 + 漲薪必備
瘋狂創客圈經典圖書：《SpringCloud、Nginx高併發核心編程》面試必備 + 大廠必備 + 漲薪必備
資源寶庫： Java程序員必備網盤資源大集合價值>1000元 隨便取 GO->【博客園總入口 】
獨孤九劍：Netty靈魂實驗 ：本地 100W鏈接 高併發實驗，瞬間提高Java內力
技術、面試交流：和大廠小夥伴、技術高手、架構師進行純粹的的技術問題交流、探討求助、問題圍觀學習

推薦：瘋狂創客圈高質量博文

高併發必讀的精彩博文
nacos 實戰（史上最全）	sentinel （史上最全+入門教程）
Zookeeper 分佈式鎖（圖解+秒懂+史上最全）	Webflux（史上最全）
SpringCloud gateway （史上最全）	TCP/IP（圖解+秒懂+史上最全）
10分鐘看懂， Java NIO 底層原理	Feign原理（圖解）
更多精彩博文 .....	請參見【瘋狂創客圈高併發總目錄】

史上最全 Java 面試題 28 專題總目錄

精心梳理、吐血推薦、史上最強、建議收藏	阿里、京東、美團、頭條.... 隨意挑、橫着走！！！
1.Java算法面試題（史上最強、持續更新、吐血推薦）	2.Java基礎面試題（史上最全、持續更新、吐血推薦）
3.JVM面試題（史上最強、持續更新、吐血推薦）	四、架構設計面試題（史上最全、持續更新、吐血推薦）
五、Spring面試題專題	六、SpringMVC面試題專題
7.SpringBoot - 面試題（史上最強、持續更新）	八、Tomcat面試題專題部分
9.網絡協議面試題（史上最全、持續更新、吐血推薦）	十、TCP/IP協議（圖解+秒懂+史上最全）
11.JUC併發包與容器 - 面試題（史上最強、持續更新）	十二、設計模式面試題（史上最全、持續更新、吐血推薦）
13.死鎖面試題（史上最強、持續更新）	15.Zookeeper 分佈式鎖（圖解+秒懂+史上最全）
1四、Redis 面試題 - 收藏版（史上最強、持續更新）	1六、Zookeeper 面試題（史上最強、持續更新）
1七、分佈式事務面試題（史上最全、持續更新、吐血推薦）	1八、一致性協議（史上最全）
1九、Zab協議 (史上最全)	20、Paxos 圖解 (秒懂)
2一、raft 圖解 (秒懂)	2六、消息隊列、RabbitMQ、Kafka、RocketMQ面試題（史上最全、持續更新）
22.Linux面試題（史上最全、持續更新、吐血推薦）	2三、Mysql 面試題（史上最強、持續更新）
2四、SpringCloud 面試題 - 收藏版（史上最強、持續更新）	2五、Netty 面試題（史上最強、持續更新）
2七、內存泄漏內存溢出（史上最全）	2八、JVM 內存溢出實戰（史上最全）

Spring面試題專題部分

什麼是spring?

Spring是一個輕量級Java開發框架，最先有Rod Johnson建立，目的是爲了解決企業級應用開發的業務邏輯層和其餘各層的耦合問題。它是一個分層的JavaSE/JavaEE full-stack（一站式）輕量級開源框架，爲開發Java應用程序提供全面的基礎架構支持。Spring負責基礎架構，所以Java開發者能夠專一於應用程序的開發。前端

Spring最根本的使命是解決企業級應用開發的複雜性，即簡化Java開發。java

Spring能夠作不少事情，它爲企業級開發提供給了豐富的功能，可是這些功能的底層都依賴於它的兩個核心特性，也就是依賴注入（dependency injection，DI）和麪向切面編程（aspect-oriented programming，AOP）。git

爲了下降Java開發的複雜性，Spring採起了如下4種關鍵策略程序員

基於POJO的輕量級和最小侵入性編程；
經過依賴注入和麪向接口實現鬆耦合；
基於切面和慣例進行聲明式編程；
經過切面和模板減小樣板式代碼。

Spring框架的設計目標，設計理念，和核心是什麼

Spring設計目標：Spring爲開發者提供一個一站式輕量級應用開發平臺；github

Spring設計理念：在JavaEE開發中，支持POJO和JavaBean開發方式，使應用面向接口開發，充分支持OO（面向對象）設計方法；Spring經過IoC容器實現對象耦合關係的管理，並實現依賴反轉，將對象之間的依賴關係交給IoC容器，實現解耦；web

Spring框架的核心：IoC容器和AOP模塊。經過IoC容器管理POJO對象以及他們之間的耦合關係；經過AOP以動態非侵入的方式加強服務。面試

IoC讓相互協做的組件保持鬆散的耦合，而AOP編程容許你把遍及於應用各層的功能分離出來造成可重用的功能組件。ajax

Spring的優缺點是什麼？

優勢正則表達式

方便解耦，簡化開發

Spring就是一個大工廠，能夠將全部對象的建立和依賴關係的維護，交給Spring管理。
AOP編程的支持

Spring提供面向切面編程，能夠方便的實現對程序進行權限攔截、運行監控等功能。
聲明式事務的支持

只須要經過配置就能夠完成對事務的管理，而無需手動編程。
方便程序的測試

Spring對Junit4支持，能夠經過註解方便的測試Spring程序。
方便集成各類優秀框架

Spring不排斥各類優秀的開源框架，其內部提供了對各類優秀框架的直接支持（如：Struts、Hibernate、MyBatis等）。
下降JavaEE API的使用難度

Spring對JavaEE開發中很是難用的一些API（JDBC、JavaMail、遠程調用等），都提供了封裝，使這些API應用難度大大下降。

缺點

Spring明明一個很輕量級的框架，卻給人感受大而全
Spring依賴反射，反射影響性能
使用門檻升高，入門Spring須要較長時間

Spring有哪些應用場景

應用場景：JavaEE企業應用開發，包括SSH、SSM等

Spring價值：

Spring是非侵入式的框架，目標是使應用程序代碼對框架依賴最小化；
Spring提供一個一致的編程模型，使應用直接使用POJO開發，與運行環境隔離開來；
Spring推進應用設計風格向面向對象和麪向接口開發轉變，提升了代碼的重用性和可測試性；

Spring由哪些模塊組成？

Spring 總共大約有 20 個模塊，由 1300 多個不一樣的文件構成。而這些組件被分別整合在核心容器（Core Container） 、 AOP（Aspect Oriented Programming）和設備支持（Instrmentation） 、數據訪問與集成（Data Access/Integeration） 、 Web、 消息（Messaging） 、 Test等 6 個模塊中。如下是 Spring 5 的模塊結構圖：

spring core：提供了框架的基本組成部分，包括控制反轉（Inversion of Control，IOC）和依賴注入（Dependency Injection，DI）功能。
spring beans：提供了BeanFactory，是工廠模式的一個經典實現，Spring將管理對象稱爲Bean。
spring context：構建於 core 封裝包基礎上的 context 封裝包，提供了一種框架式的對象訪問方法。
spring jdbc：提供了一個JDBC的抽象層，消除了煩瑣的JDBC編碼和數據庫廠商特有的錯誤代碼解析，用於簡化JDBC。
spring aop：提供了面向切面的編程實現，讓你能夠自定義攔截器、切點等。
spring Web：提供了針對 Web 開發的集成特性，例如文件上傳，利用 servlet listeners 進行 ioc 容器初始化和針對 Web 的 ApplicationContext。
spring test：主要爲測試提供支持的，支持使用JUnit或TestNG對Spring組件進行單元測試和集成測試。

Spring 框架中都用到了哪些設計模式？

工廠模式：BeanFactory就是簡單工廠模式的體現，用來建立對象的實例；
單例模式：Bean默認爲單例模式。
代理模式：Spring的AOP功能用到了JDK的動態代理和CGLIB字節碼生成技術；
模板方法：用來解決代碼重複的問題。好比. RestTemplate, JmsTemplate, JpaTemplate。
觀察者模式：定義對象鍵一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都會獲得通知被制動更新，如Spring中listener的實現–ApplicationListener。

詳細講解一下核心容器（spring context應用上下文) 模塊

這是基本的Spring模塊，提供spring 框架的基礎功能，BeanFactory 是任何以spring爲基礎的應用的核心。Spring 框架創建在此模塊之上，它使Spring成爲一個容器。

Bean 工廠是工廠模式的一個實現，提供了控制反轉功能，用來把應用的配置和依賴從真正的應用代碼中分離。最經常使用的就是org.springframework.beans.factory.xml.XmlBeanFactory ，它根據XML文件中的定義加載beans。該容器從XML 文件讀取配置元數據並用它去建立一個徹底配置的系統或應用。

Spring框架中有哪些不一樣類型的事件

Spring 提供瞭如下5種標準的事件：

上下文更新事件（ContextRefreshedEvent）：在調用ConfigurableApplicationContext 接口中的refresh()方法時被觸發。
上下文開始事件（ContextStartedEvent）：當容器調用ConfigurableApplicationContext的Start()方法開始/從新開始容器時觸發該事件。
上下文中止事件（ContextStoppedEvent）：當容器調用ConfigurableApplicationContext的Stop()方法中止容器時觸發該事件。
上下文關閉事件（ContextClosedEvent）：當ApplicationContext被關閉時觸發該事件。容器被關閉時，其管理的全部單例Bean都被銷燬。
請求處理事件（RequestHandledEvent）：在Web應用中，當一個http請求（request）結束觸發該事件。若是一個bean實現了ApplicationListener接口，當一個ApplicationEvent 被髮布之後，bean會自動被通知。

Spring 應用程序有哪些不一樣組件？

Spring 應用通常有如下組件：

接口 - 定義功能。
Bean 類 - 它包含屬性，setter 和 getter 方法，函數等。
Bean 配置文件 - 包含類的信息以及如何配置它們。
Spring 面向切面編程（AOP） - 提供面向切面編程的功能。
用戶程序 - 它使用接口。

使用 Spring 有哪些方式？

使用 Spring 有如下方式：

做爲一個成熟的 Spring Web 應用程序。
做爲第三方 Web 框架，使用 Spring Frameworks 中間層。
做爲企業級 Java Bean，它能夠包裝現有的 POJO（Plain Old Java Objects）。
用於遠程使用。

Spring控制反轉(IOC)（13）

什麼是Spring IOC 容器？

控制反轉即IoC (Inversion of Control)，它把傳統上由程序代碼直接操控的對象的調用權交給容器，經過容器來實現對象組件的裝配和管理。所謂的「控制反轉」概念就是對組件對象控制權的轉移，從程序代碼自己轉移到了外部容器。

Spring IOC 負責建立對象，管理對象（經過依賴注入（DI），裝配對象，配置對象，而且管理這些對象的整個生命週期。

控制反轉(IoC)有什麼做用

管理對象的建立和依賴關係的維護。對象的建立並非一件簡單的事，在對象關係比較複雜時，若是依賴關係須要程序猿來維護的話，那是至關頭疼的
解耦，由容器去維護具體的對象
託管了類的產生過程，好比咱們須要在類的產生過程當中作一些處理，最直接的例子就是代理，若是有容器程序能夠把這部分處理交給容器，應用程序則無需去關心類是如何完成代理的

IOC的優勢是什麼？

IOC 或依賴注入把應用的代碼量降到最低。
它使應用容易測試，單元測試再也不須要單例和JNDI查找機制。
最小的代價和最小的侵入性使鬆散耦合得以實現。
IOC容器支持加載服務時的餓漢式初始化和懶加載。

Spring IoC 的實現機制

Spring 中的 IoC 的實現原理就是工廠模式加反射機制。

示例：

interface Fruit {
   public abstract void eat();
 }

class Apple implements Fruit {
    public void eat(){
        System.out.println("Apple");
    }
}

class Orange implements Fruit {
    public void eat(){
        System.out.println("Orange");
    }
}

class Factory {
    public static Fruit getInstance(String ClassName) {
        Fruit f=null;
        try {
            f=(Fruit)Class.forName(ClassName).newInstance();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return f;
    }
}

class Client {
    public static void main(String[] a) {
        Fruit f=Factory.getInstance("io.github.dunwu.spring.Apple");
        if(f!=null){
            f.eat();
        }
    }
}

Spring 的 IoC支持哪些功能

Spring 的 IoC 設計支持如下功能：

依賴注入
依賴檢查
自動裝配
支持集合
指定初始化方法和銷燬方法
支持回調某些方法（可是須要實現 Spring 接口，略有侵入）

其中，最重要的就是依賴注入，從 XML 的配置上說，即 ref 標籤。對應 Spring RuntimeBeanReference 對象。

對於 IoC 來講，最重要的就是容器。容器管理着 Bean 的生命週期，控制着 Bean 的依賴注入。

BeanFactory 和 ApplicationContext有什麼區別？

BeanFactory和ApplicationContext是Spring的兩大核心接口，均可以當作Spring的容器。其中ApplicationContext是BeanFactory的子接口。

依賴關係

BeanFactory：是Spring裏面最底層的接口，包含了各類Bean的定義，讀取bean配置文檔，管理bean的加載、實例化，控制bean的生命週期，維護bean之間的依賴關係。

ApplicationContext接口做爲BeanFactory的派生，除了提供BeanFactory所具備的功能外，還提供了更完整的框架功能：

繼承MessageSource，所以支持國際化。
統一的資源文件訪問方式。
提供在監聽器中註冊bean的事件。
同時加載多個配置文件。
載入多個（有繼承關係）上下文，使得每個上下文都專一於一個特定的層次，好比應用的web層。

加載方式

BeanFactroy採用的是延遲加載形式來注入Bean的，即只有在使用到某個Bean時(調用getBean())，纔對該Bean進行加載實例化。這樣，咱們就不能發現一些存在的Spring的配置問題。若是Bean的某一個屬性沒有注入，BeanFacotry加載後，直至第一次使用調用getBean方法纔會拋出異常。

ApplicationContext，它是在容器啓動時，一次性建立了全部的Bean。這樣，在容器啓動時，咱們就能夠發現Spring中存在的配置錯誤，這樣有利於檢查所依賴屬性是否注入。 ApplicationContext啓動後預載入全部的單實例Bean，經過預載入單實例bean ,確保當你須要的時候，你就不用等待，由於它們已經建立好了。

相對於基本的BeanFactory，ApplicationContext 惟一的不足是佔用內存空間。當應用程序配置Bean較多時，程序啓動較慢。

建立方式

BeanFactory一般以編程的方式被建立，ApplicationContext還能以聲明的方式建立，如使用ContextLoader。

註冊方式

BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但二者之間的區別是：BeanFactory須要手動註冊，而ApplicationContext則是自動註冊。

Spring 如何設計容器的，BeanFactory和ApplicationContext的關係詳解

Spring 做者 Rod Johnson 設計了兩個接口用以表示容器。

BeanFactory
ApplicationContext

BeanFactory 簡單粗暴，能夠理解爲就是個 HashMap，Key 是 BeanName，Value 是 Bean 實例。一般只提供註冊（put），獲取（get）這兩個功能。咱們能夠稱之爲 「低級容器」。

ApplicationContext 能夠稱之爲 「高級容器」。由於他比 BeanFactory 多了更多的功能。他繼承了多個接口。所以具有了更多的功能。例如資源的獲取，支持多種消息（例如 JSP tag 的支持），對 BeanFactory 多了工具級別的支持等待。因此你看他的名字，已經不是 BeanFactory 之類的工廠了，而是「應用上下文」，表明着整個大容器的全部功能。該接口定義了一個 refresh 方法，此方法是全部閱讀 Spring 源碼的人的最熟悉的方法，用於刷新整個容器，即從新加載/刷新全部的 bean。

固然，除了這兩個大接口，還有其餘的輔助接口，這裏就不介紹他們了。

BeanFactory和ApplicationContext的關係

爲了更直觀的展現「低級容器」和「高級容器」的關係，這裏經過經常使用的 ClassPathXmlApplicationContext 類來展現整個容器的層級 UML 關係。

有點複雜？先不要慌，我來解釋一下。

最上面的是 BeanFactory，下面的 3 個綠色的，都是功能擴展接口，這裏就不展開講。

看下面的隸屬 ApplicationContext 粉紅色的「高級容器」，依賴着「低級容器」，這裏說的是依賴，不是繼承哦。他依賴着「低級容器」的 getBean 功能。而高級容器有更多的功能：支持不一樣的信息源頭，能夠訪問文件資源，支持應用事件（Observer 模式）。

一般用戶看到的就是「高級容器」。但 BeanFactory 也很是夠用啦！

左邊灰色區域的是「低級容器」，只負載加載 Bean，獲取 Bean。容器其餘的高級功能是沒有的。例如上圖畫的 refresh 刷新 Bean 工廠全部配置，生命週期事件回調等。

小結

說了這麼多，不知道你有沒有理解Spring IoC？這裏小結一下：IoC 在 Spring 裏，只須要低級容器就能夠實現，2 個步驟：

加載配置文件，解析成 BeanDefinition 放在 Map 裏。
調用 getBean 的時候，從 BeanDefinition 所屬的 Map 裏，拿出 Class 對象進行實例化，同時，若是有依賴關係，將遞歸調用 getBean 方法 —— 完成依賴注入。

上面就是 Spring 低級容器（BeanFactory）的 IoC。

至於高級容器 ApplicationContext，他包含了低級容器的功能，當他執行 refresh 模板方法的時候，將刷新整個容器的 Bean。同時其做爲高級容器，包含了太多的功能。一句話，他不只僅是 IoC。他支持不一樣信息源頭，支持 BeanFactory 工具類，支持層級容器，支持訪問文件資源，支持事件發佈通知，支持接口回調等等。

ApplicationContext一般的實現是什麼？

FileSystemXmlApplicationContext ：此容器從一個XML文件中加載beans的定義，XML Bean 配置文件的全路徑名必須提供給它的構造函數。

ClassPathXmlApplicationContext：此容器也從一個XML文件中加載beans的定義，這裏，你須要正確設置classpath由於這個容器將在classpath裏找bean配置。

WebXmlApplicationContext：此容器加載一個XML文件，此文件定義了一個WEB應用的全部bean。

什麼是Spring的依賴注入？

控制反轉IoC是一個很大的概念，能夠用不一樣的方式來實現。其主要實現方式有兩種：依賴注入和依賴查找

依賴注入：相對於IoC而言，依賴注入(DI)更加準確地描述了IoC的設計理念。所謂依賴注入（Dependency Injection），即組件之間的依賴關係由容器在應用系統運行期來決定，也就是由容器動態地將某種依賴關係的目標對象實例注入到應用系統中的各個關聯的組件之中。組件不作定位查詢，只提供普通的Java方法讓容器去決定依賴關係。

依賴注入的基本原則

依賴注入的基本原則是：應用組件不該該負責查找資源或者其餘依賴的協做對象。配置對象的工做應該由IoC容器負責，「查找資源」的邏輯應該從應用組件的代碼中抽取出來，交給IoC容器負責。容器全權負責組件的裝配，它會把符合依賴關係的對象經過屬性（JavaBean中的setter）或者是構造器傳遞給須要的對象。

依賴注入有什麼優點

依賴注入之因此更流行是由於它是一種更可取的方式：讓容器全權負責依賴查詢，受管組件只須要暴露JavaBean的setter方法或者帶參數的構造器或者接口，使容器能夠在初始化時組裝對象的依賴關係。其與依賴查找方式相比，主要優點爲：

查找定位操做與應用代碼徹底無關。
不依賴於容器的API，能夠很容易地在任何容器之外使用應用對象。
不須要特殊的接口，絕大多數對象能夠作到徹底沒必要依賴容器。

有哪些不一樣類型的依賴注入實現方式？

依賴注入是時下最流行的IoC實現方式，依賴注入分爲接口注入（Interface Injection），Setter方法注入（Setter Injection）和構造器注入（Constructor Injection）三種方式。其中接口注入因爲在靈活性和易用性比較差，如今從Spring4開始已被廢棄。

構造器依賴注入：構造器依賴注入經過容器觸發一個類的構造器來實現的，該類有一系列參數，每一個參數表明一個對其餘類的依賴。

Setter方法注入：Setter方法注入是容器經過調用無參構造器或無參static工廠方法實例化bean以後，調用該bean的setter方法，即實現了基於setter的依賴注入。

構造器依賴注入和 Setter方法注入的區別

構造函數注入	setter 注入
沒有部分注入	有部分注入
不會覆蓋 setter 屬性	會覆蓋 setter 屬性
任意修改都會建立一個新實例	任意修改不會建立一個新實例
適用於設置不少屬性	適用於設置少許屬性

兩種依賴方式均可以使用，構造器注入和Setter方法注入。最好的解決方案是用構造器參數實現強制依賴，setter方法實現可選依賴。

Spring Beans（19）

什麼是Spring beans？

Spring beans 是那些造成Spring應用的主幹的java對象。它們被Spring IOC容器初始化，裝配，和管理。這些beans經過容器中配置的元數據建立。好比，以XML文件中的形式定義。

一個 Spring Bean 定義包含什麼？

一個Spring Bean 的定義包含容器必知的全部配置元數據，包括如何建立一個bean，它的生命週期詳情及它的依賴。

如何給Spring 容器提供配置元數據？Spring有幾種配置方式

這裏有三種重要的方法給Spring 容器提供配置元數據。

XML配置文件。
基於註解的配置。
基於java的配置。

Spring配置文件包含了哪些信息

Spring配置文件是個XML 文件，這個文件包含了類信息，描述瞭如何配置它們，以及如何相互調用。

Spring基於xml注入bean的幾種方式

Set方法注入；
構造器注入：①經過index設置參數的位置；②經過type設置參數類型；
靜態工廠注入；
實例工廠；

你怎樣定義類的做用域？

當定義一個在Spring裏，咱們還能給這個bean聲明一個做用域。它能夠經過bean 定義中的scope屬性來定義。如，當Spring要在須要的時候每次生產一個新的bean實例，bean的scope屬性被指定爲prototype。另外一方面，一個bean每次使用的時候必須返回同一個實例，這個bean的scope 屬性必須設爲 singleton。

解釋Spring支持的幾種bean的做用域

Spring框架支持如下五種bean的做用域：

singleton : bean在每一個Spring ioc 容器中只有一個實例。
prototype：一個bean的定義能夠有多個實例。
request：每次http請求都會建立一個bean，該做用域僅在基於web的Spring ApplicationContext情形下有效。
session：在一個HTTP Session中，一個bean定義對應一個實例。該做用域僅在基於web的Spring ApplicationContext情形下有效。
global-session：在一個全局的HTTP Session中，一個bean定義對應一個實例。該做用域僅在基於web的Spring ApplicationContext情形下有效。

注意： 缺省的Spring bean 的做用域是Singleton。使用 prototype 做用域須要慎重的思考，由於頻繁建立和銷燬 bean 會帶來很大的性能開銷。

Spring框架中的單例bean是線程安全的嗎？

不是，Spring框架中的單例bean不是線程安全的。

spring 中的 bean 默認是單例模式，spring 框架並無對單例 bean 進行多線程的封裝處理。

實際上大部分時候 spring bean 無狀態的（好比 dao 類），全部某種程度上來講 bean 也是安全的，但若是 bean 有狀態的話（好比 view model 對象），那就要開發者本身去保證線程安全了，最簡單的就是改變 bean 的做用域，把「singleton」變動爲「prototype」，這樣請求 bean 至關於 new Bean()了，因此就能夠保證線程安全了。

有狀態就是有數據存儲功能。
無狀態就是不會保存數據。

Spring如何處理線程併發問題？

在通常狀況下，只有無狀態的Bean才能夠在多線程環境下共享，在Spring中，絕大部分Bean均可以聲明爲singleton做用域，由於Spring對一些Bean中非線程安全狀態採用ThreadLocal進行處理，解決線程安全問題。

ThreadLocal和線程同步機制都是爲了解決多線程中相同變量的訪問衝突問題。同步機制採用了「時間換空間」的方式，僅提供一份變量，不一樣的線程在訪問前須要獲取鎖，沒得到鎖的線程則須要排隊。而ThreadLocal採用了「空間換時間」的方式。

ThreadLocal會爲每個線程提供一個獨立的變量副本，從而隔離了多個線程對數據的訪問衝突。由於每個線程都擁有本身的變量副本，從而也就沒有必要對該變量進行同步了。ThreadLocal提供了線程安全的共享對象，在編寫多線程代碼時，能夠把不安全的變量封裝進ThreadLocal。

解釋Spring框架中bean的生命週期

在傳統的Java應用中，bean的生命週期很簡單。使用Java關鍵字new進行bean實例化，而後該bean就可使用了。一旦該bean再也不被使用，則由Java自動進行垃圾回收。相比之下，Spring容器中的bean的生命週期就顯得相對複雜多了。正確理解Spring bean的生命週期很是重要，由於你或許要利用Spring提供的擴展點來自定義bean的建立過程。下圖展現了bean裝載到Spring應用上下文中的一個典型的生命週期過程。

bean在Spring容器中從建立到銷燬經歷了若干階段，每一階段均可以針對Spring如何管理bean進行個性化定製。

正如你所見，在bean準備就緒以前，bean工廠執行了若干啓動步驟。

咱們對上圖進行詳細描述：

Spring對bean進行實例化；

Spring將值和bean的引用注入到bean對應的屬性中；

若是bean實現了BeanNameAware接口，Spring將bean的ID傳遞給setBean-Name()方法；

若是bean實現了BeanFactoryAware接口，Spring將調用setBeanFactory()方法，將BeanFactory容器實例傳入；

若是bean實現了ApplicationContextAware接口，Spring將調用setApplicationContext()方法，將bean所在的應用上下文的引用傳入進來；

若是bean實現了BeanPostProcessor接口，Spring將調用它們的post-ProcessBeforeInitialization()方法；

若是bean實現了InitializingBean接口，Spring將調用它們的after-PropertiesSet()方法。相似地，若是bean使用initmethod聲明瞭初始化方法，該方法也會被調用；

若是bean實現了BeanPostProcessor接口，Spring將調用它們的post-ProcessAfterInitialization()方法；

此時，bean已經準備就緒，能夠被應用程序使用了，它們將一直駐留在應用上下文中，直到該應用上下文被銷燬；

若是bean實現了DisposableBean接口，Spring將調用它的destroy()接口方法。一樣，若是bean使用destroy-method聲明瞭銷燬方法，該方法也會被調用。

如今你已經瞭解瞭如何建立和加載一個Spring容器。可是一個空的容器並無太大的價值，在你把東西放進去以前，它裏面什麼都沒有。爲了從Spring的DI(依賴注入)中受益，咱們必須將應用對象裝配進Spring容器中。

哪些是重要的bean生命週期方法？你能重載它們嗎？

有兩個重要的bean 生命週期方法，第一個是setup ，它是在容器加載bean的時候被調用。第二個方法是 teardown 它是在容器卸載類的時候被調用。

bean 標籤有兩個重要的屬性（init-method和destroy-method）。用它們你能夠本身定製初始化和註銷方法。它們也有相應的註解（@PostConstruct和@PreDestroy）。

什麼是Spring的內部bean？什麼是Spring inner beans？

在Spring框架中，當一個bean僅被用做另外一個bean的屬性時，它能被聲明爲一個內部bean。內部bean能夠用setter注入「屬性」和構造方法注入「構造參數」的方式來實現，內部bean一般是匿名的，它們的Scope通常是prototype。

在 Spring中如何注入一個java集合？

Spring提供如下幾種集合的配置元素：

類型用於注入一列值，容許有相同的值。

類型用於注入一組值，不容許有相同的值。

類型用於注入一組鍵值對，鍵和值均可覺得任意類型。

類型用於注入一組鍵值對，鍵和值都只能爲String類型。

什麼是bean裝配？

裝配，或bean 裝配是指在Spring 容器中把bean組裝到一塊兒，前提是容器須要知道bean的依賴關係，如何經過依賴注入來把它們裝配到一塊兒。

什麼是bean的自動裝配？

在Spring框架中，在配置文件中設定bean的依賴關係是一個很好的機制，Spring 容器可以自動裝配相互合做的bean，這意味着容器不須要和配置，能經過Bean工廠自動處理bean之間的協做。這意味着 Spring能夠經過向Bean Factory中注入的方式自動搞定bean之間的依賴關係。自動裝配能夠設置在每一個bean上，也能夠設定在特定的bean上。

解釋不一樣方式的自動裝配，spring 自動裝配 bean 有哪些方式？

在spring中，對象無需本身查找或建立與其關聯的其餘對象，由容器負責把須要相互協做的對象引用賦予各個對象，使用autowire來配置自動裝載模式。

在Spring框架xml配置中共有5種自動裝配：

no：默認的方式是不進行自動裝配的，經過手工設置ref屬性來進行裝配bean。
byName：經過bean的名稱進行自動裝配，若是一個bean的 property 與另外一bean 的name 相同，就進行自動裝配。
byType：經過參數的數據類型進行自動裝配。
constructor：利用構造函數進行裝配，而且構造函數的參數經過byType進行裝配。
autodetect：自動探測，若是有構造方法，經過 construct的方式自動裝配，不然使用 byType的方式自動裝配。

使用@Autowired註解自動裝配的過程是怎樣的？

使用@Autowired註解來自動裝配指定的bean。在使用@Autowired註解以前須要在Spring配置文件進行配置，<context:annotation-config />。

在啓動spring IoC時，容器自動裝載了一個AutowiredAnnotationBeanPostProcessor後置處理器，當容器掃描到@Autowied、@Resource或@Inject時，就會在IoC容器自動查找須要的bean，並裝配給該對象的屬性。在使用@Autowired時，首先在容器中查詢對應類型的bean：

若是查詢結果恰好爲一個，就將該bean裝配給@Autowired指定的數據；
若是查詢的結果不止一個，那麼@Autowired會根據名稱來查找；
若是上述查找的結果爲空，那麼會拋出異常。解決方法時，使用required=false。

自動裝配有哪些侷限性？

自動裝配的侷限性是：

重寫：你仍需用和配置來定義依賴，意味着總要重寫自動裝配。

基本數據類型：你不能自動裝配簡單的屬性，如基本數據類型，String字符串，和類。

模糊特性：自動裝配不如顯式裝配精確，若是有可能，建議使用顯式裝配。

你能夠在Spring中注入一個null 和一個空字符串嗎？

能夠。

Spring註解（8）

什麼是基於Java的Spring註解配置? 給一些註解的例子

基於Java的配置，容許你在少許的Java註解的幫助下，進行你的大部分Spring配置而非經過XML文件。

以@Configuration 註解爲例，它用來標記類能夠當作一個bean的定義，被Spring IOC容器使用。

另外一個例子是@Bean註解，它表示此方法將要返回一個對象，做爲一個bean註冊進Spring應用上下文。

@Configuration
public class StudentConfig {
    @Bean
    public StudentBean myStudent() {
        return new StudentBean();
    }
}

怎樣開啓註解裝配？

註解裝配在默認狀況下是不開啓的，爲了使用註解裝配，咱們必須在Spring配置文件中配置 <context:annotation-config/>元素。

@Component, @Controller, @Repository, @Service 有何區別？

@Component：這將 java 類標記爲 bean。它是任何 Spring 管理組件的通用構造型。spring 的組件掃描機制如今能夠將其拾取並將其拉入應用程序環境中。

@Controller：這將一個類標記爲 Spring Web MVC 控制器。標有它的 Bean 會自動導入到 IoC 容器中。

@Service：此註解是組件註解的特化。它不會對 @Component 註解提供任何其餘行爲。您能夠在服務層類中使用 @Service 而不是 @Component，由於它以更好的方式指定了意圖。

@Repository：這個註解是具備相似用途和功能的 @Component 註解的特化。它爲 DAO 提供了額外的好處。它將 DAO 導入 IoC 容器，並使未經檢查的異常有資格轉換爲 Spring DataAccessException。

@Required 註解有什麼做用

這個註解代表bean的屬性必須在配置的時候設置，經過一個bean定義的顯式的屬性值或經過自動裝配，若@Required註解的bean屬性未被設置，容器將拋出BeanInitializationException。示例：

public class Employee {
    private String name;
    @Required
    public void setName(String name){
        this.name=name;
    }
    public string getName(){
        return name;
    }
}

@Autowired 註解有什麼做用

@Autowired默認是按照類型裝配注入的，默認狀況下它要求依賴對象必須存在（能夠設置它required屬性爲false）。@Autowired 註解提供了更細粒度的控制，包括在何處以及如何完成自動裝配。它的用法和@Required同樣，修飾setter方法、構造器、屬性或者具備任意名稱和/或多個參數的PN方法。

public class Employee {
    private String name;
    @Autowired
    public void setName(String name) {
        this.name=name;
    }
    public string getName(){
        return name;
    }
}

@Autowired和@Resource之間的區別

@Autowired可用於：構造函數、成員變量、Setter方法

@Autowired和@Resource之間的區別

@Autowired默認是按照類型裝配注入的，默認狀況下它要求依賴對象必須存在（能夠設置它required屬性爲false）。
@Resource默認是按照名稱來裝配注入的，只有當找不到與名稱匹配的bean纔會按照類型來裝配注入。

@Qualifier 註解有什麼做用

當您建立多個相同類型的 bean 並但願僅使用屬性裝配其中一個 bean 時，您可使用@Qualifier 註解和 @Autowired 經過指定應該裝配哪一個確切的 bean 來消除歧義。

@RequestMapping 註解有什麼用？

@RequestMapping 註解用於將特定 HTTP 請求方法映射到將處理相應請求的控制器中的特定類/方法。此註釋可應用於兩個級別：

類級別：映射請求的 URL
方法級別：映射 URL 以及 HTTP 請求方法

Spring數據訪問（14）

解釋對象/關係映射集成模塊

Spring 經過提供ORM模塊，支持咱們在直接JDBC之上使用一個對象/關係映射映射(ORM)工具，Spring 支持集成主流的ORM框架，如Hiberate，JDO和 iBATIS，JPA，TopLink，JDO，OJB 。Spring的事務管理一樣支持以上全部ORM框架及JDBC。

在Spring框架中如何更有效地使用JDBC？

使用Spring JDBC 框架，資源管理和錯誤處理的代價都會被減輕。因此開發者只需寫statements 和 queries從數據存取數據，JDBC也能夠在Spring框架提供的模板類的幫助下更有效地被使用，這個模板叫JdbcTemplate

解釋JDBC抽象和DAO模塊

經過使用JDBC抽象和DAO模塊，保證數據庫代碼的簡潔，並能避免數據庫資源錯誤關閉致使的問題，它在各類不一樣的數據庫的錯誤信息之上，提供了一個統一的異常訪問層。它還利用Spring的AOP 模塊給Spring應用中的對象提供事務管理服務。

spring DAO 有什麼用？

Spring DAO（數據訪問對象）使得 JDBC，Hibernate 或 JDO 這樣的數據訪問技術更容易以一種統一的方式工做。這使得用戶容易在持久性技術之間切換。它還容許您在編寫代碼時，無需考慮捕獲每種技術不一樣的異常。

spring JDBC API 中存在哪些類？

JdbcTemplate

SimpleJdbcTemplate

NamedParameterJdbcTemplate

SimpleJdbcInsert

SimpleJdbcCall

JdbcTemplate是什麼

JdbcTemplate 類提供了不少便利的方法解決諸如把數據庫數據轉變成基本數據類型或對象，執行寫好的或可調用的數據庫操做語句，提供自定義的數據錯誤處理。

使用Spring經過什麼方式訪問Hibernate？使用 Spring 訪問 Hibernate 的方法有哪些？

在Spring中有兩種方式訪問Hibernate：

使用 Hibernate 模板和回調進行控制反轉
擴展 HibernateDAOSupport 並應用 AOP 攔截器節點

如何經過HibernateDaoSupport將Spring和Hibernate結合起來？

用Spring的 SessionFactory 調用 LocalSessionFactory。集成過程分三步：

配置the Hibernate SessionFactory
繼承HibernateDaoSupport實現一個DAO
在AOP支持的事務中裝配

Spring支持的事務管理類型， spring 事務實現方式有哪些？

Spring支持兩種類型的事務管理：

編程式事務管理：這意味你經過編程的方式管理事務，給你帶來極大的靈活性，可是難維護。

聲明式事務管理：這意味着你能夠將業務代碼和事務管理分離，你只需用註解和XML配置來管理事務。

Spring事務的實現方式和實現原理

Spring事務的本質其實就是數據庫對事務的支持，沒有數據庫的事務支持，spring是沒法提供事務功能的。真正的數據庫層的事務提交和回滾是經過binlog或者redo log實現的。

說一下Spring的事務傳播行爲

spring事務的傳播行爲說的是，當多個事務同時存在的時候，spring如何處理這些事務的行爲。

① PROPAGATION_REQUIRED：若是當前沒有事務，就建立一個新事務，若是當前存在事務，就加入該事務，該設置是最經常使用的設置。

② PROPAGATION_SUPPORTS：支持當前事務，若是當前存在事務，就加入該事務，若是當前不存在事務，就以非事務執行。

③ PROPAGATION_MANDATORY：支持當前事務，若是當前存在事務，就加入該事務，若是當前不存在事務，就拋出異常。

④ PROPAGATION_REQUIRES_NEW：建立新事務，不管當前存不存在事務，都建立新事務。

⑤ PROPAGATION_NOT_SUPPORTED：以非事務方式執行操做，若是當前存在事務，就把當前事務掛起。

⑥ PROPAGATION_NEVER：以非事務方式執行，若是當前存在事務，則拋出異常。

⑦ PROPAGATION_NESTED：若是當前存在事務，則在嵌套事務內執行。若是當前沒有事務，則按REQUIRED屬性執行。

說一下 spring 的事務隔離？

spring 有五大隔離級別，默認值爲 ISOLATION_DEFAULT（使用數據庫的設置），其餘四個隔離級別和數據庫的隔離級別一致：

ISOLATION_DEFAULT：用底層數據庫的設置隔離級別，數據庫設置的是什麼我就用什麼；
ISOLATION_READ_UNCOMMITTED：未提交讀，最低隔離級別、事務未提交前，就可被其餘事務讀取（會出現幻讀、髒讀、不可重複讀）；
ISOLATION_READ_COMMITTED：提交讀，一個事務提交後才能被其餘事務讀取到（會形成幻讀、不可重複讀），SQL server 的默認級別；
ISOLATION_REPEATABLE_READ：可重複讀，保證屢次讀取同一個數據時，其值都和事務開始時候的內容是一致，禁止讀取到別的事務未提交的數據（會形成幻讀），MySQL 的默認級別；
ISOLATION_SERIALIZABLE：序列化，代價最高最可靠的隔離級別，該隔離級別能防止髒讀、不可重複讀、幻讀。

髒讀：表示一個事務可以讀取另外一個事務中還未提交的數據。好比，某個事務嘗試插入記錄 A，此時該事務還未提交，而後另外一個事務嘗試讀取到了記錄 A。

不可重複讀 ：是指在一個事務內，屢次讀同一數據。

幻讀：指同一個事務內屢次查詢返回的結果集不同。好比同一個事務 A 第一次查詢時候有 n 條記錄，可是第二次同等條件下查詢卻有 n+1 條記錄，這就好像產生了幻覺。發生幻讀的緣由也是另一個事務新增或者刪除或者修改了第一個事務結果集裏面的數據，同一個記錄的數據內容被修改了，全部數據行的記錄就變多或者變少了。

Spring框架的事務管理有哪些優勢？

爲不一樣的事務API 如 JTA，JDBC，Hibernate，JPA 和JDO，提供一個不變的編程模式。
爲編程式事務管理提供了一套簡單的API而不是一些複雜的事務API
支持聲明式事務管理。
和Spring各類數據訪問抽象層很好得集成。

你更傾向用那種事務管理類型？

大多數Spring框架的用戶選擇聲明式事務管理，由於它對應用代碼的影響最小，所以更符合一個無侵入的輕量級容器的思想。聲明式事務管理要優於編程式事務管理，雖然比編程式事務管理（這種方式容許你經過代碼控制事務）少了一點靈活性。惟一不足地方是，最細粒度只能做用到方法級別，沒法作到像編程式事務那樣能夠做用到代碼塊級別。

Spring面向切面編程(AOP)（13）

什麼是AOP

OOP(Object-Oriented Programming)面向對象編程，容許開發者定義縱向的關係，但並適用於定義橫向的關係，致使了大量代碼的重複，而不利於各個模塊的重用。

AOP(Aspect-Oriented Programming)，通常稱爲面向切面編程，做爲面向對象的一種補充，用於將那些與業務無關，但卻對多個對象產生影響的公共行爲和邏輯，抽取並封裝爲一個可重用的模塊，這個模塊被命名爲「切面」（Aspect），減小系統中的重複代碼，下降了模塊間的耦合度，同時提升了系統的可維護性。可用於權限認證、日誌、事務處理等。

Spring AOP and AspectJ AOP 有什麼區別？AOP 有哪些實現方式？

AOP實現的關鍵在於代理模式，AOP代理主要分爲靜態代理和動態代理。靜態代理的表明爲AspectJ；動態代理則以Spring AOP爲表明。

（1）AspectJ是靜態代理的加強，所謂靜態代理，就是AOP框架會在編譯階段生成AOP代理類，所以也稱爲編譯時加強，他會在編譯階段將AspectJ(切面)織入到Java字節碼中，運行的時候就是加強以後的AOP對象。

（2）Spring AOP使用的動態代理，所謂的動態代理就是說AOP框架不會去修改字節碼，而是每次運行時在內存中臨時爲方法生成一個AOP對象，這個AOP對象包含了目標對象的所有方法，而且在特定的切點作了加強處理，並回調原對象的方法。

JDK動態代理和CGLIB動態代理的區別

Spring AOP中的動態代理主要有兩種方式，JDK動態代理和CGLIB動態代理：

JDK動態代理只提供接口的代理，不支持類的代理。核心InvocationHandler接口和Proxy類，InvocationHandler 經過invoke()方法反射來調用目標類中的代碼，動態地將橫切邏輯和業務編織在一塊兒；接着，Proxy利用 InvocationHandler動態建立一個符合某一接口的的實例, 生成目標類的代理對象。
若是代理類沒有實現 InvocationHandler 接口，那麼Spring AOP會選擇使用CGLIB來動態代理目標類。CGLIB（Code Generation Library），是一個代碼生成的類庫，能夠在運行時動態的生成指定類的一個子類對象，並覆蓋其中特定方法並添加加強代碼，從而實現AOP。CGLIB是經過繼承的方式作的動態代理，所以若是某個類被標記爲final，那麼它是沒法使用CGLIB作動態代理的。

靜態代理與動態代理區別在於生成AOP代理對象的時機不一樣，相對來講AspectJ的靜態代理方式具備更好的性能，可是AspectJ須要特定的編譯器進行處理，而Spring AOP則無需特定的編譯器處理。

InvocationHandler 的 invoke(Object proxy,Method method,Object[] args)：proxy是最終生成的代理實例; method 是被代理目標實例的某個具體方法; args 是被代理目標實例某個方法的具體入參, 在方法反射調用時使用。

如何理解 Spring 中的代理？

將 Advice 應用於目標對象後建立的對象稱爲代理。在客戶端對象的狀況下，目標對象和代理對象是相同的。

Advice + Target Object = Proxy

解釋一下Spring AOP裏面的幾個名詞

（1）切面（Aspect）：切面是通知和切點的結合。通知和切點共同定義了切面的所有內容。在Spring AOP中，切面可使用通用類（基於模式的風格）或者在普通類中以 @AspectJ 註解來實現。

（2）鏈接點（Join point）：指方法，在Spring AOP中，一個鏈接點老是表明一個方法的執行。應用可能有數以千計的時機應用通知。這些時機被稱爲鏈接點。鏈接點是在應用執行過程當中可以插入切面的一個點。這個點能夠是調用方法時、拋出異常時、甚至修改一個字段時。切面代碼能夠利用這些點插入到應用的正常流程之中，並添加新的行爲。

（3）通知（Advice）：在AOP術語中，切面的工做被稱爲通知。

（4）切入點（Pointcut）：切點的定義會匹配通知所要織入的一個或多個鏈接點。咱們一般使用明確的類和方法名稱，或是利用正則表達式定義所匹配的類和方法名稱來指定這些切點。

（5）引入（Introduction）：引入容許咱們向現有類添加新方法或屬性。

（6）目標對象（Target Object）：被一個或者多個切面（aspect）所通知（advise）的對象。它一般是一個代理對象。也有人把它叫作被通知（adviced）對象。既然Spring AOP是經過運行時代理實現的，這個對象永遠是一個被代理（proxied）對象。

（7）織入（Weaving）：織入是把切面應用到目標對象並建立新的代理對象的過程。在目標對象的生命週期裏有多少個點能夠進行織入：

編譯期：切面在目標類編譯時被織入。AspectJ的織入編譯器是以這種方式織入切面的。
類加載期：切面在目標類加載到JVM時被織入。須要特殊的類加載器，它能夠在目標類被引入應用以前加強該目標類的字節碼。AspectJ5的加載時織入就支持以這種方式織入切面。
運行期：切面在應用運行的某個時刻被織入。通常狀況下，在織入切面時，AOP容器會爲目標對象動態地建立一個代理對象。SpringAOP就是以這種方式織入切面。

Spring在運行時通知對象

經過在代理類中包裹切面，Spring在運行期把切面織入到Spring管理的bean中。代理封裝了目標類，並攔截被通知方法的調用，再把調用轉發給真正的目標bean。當代理攔截到方法調用時，在調用目標bean方法以前，會執行切面邏輯。

直到應用須要被代理的bean時，Spring才建立代理對象。若是使用的是ApplicationContext的話，在ApplicationContext從BeanFactory中加載全部bean的時候，Spring纔會建立被代理的對象。由於Spring運行時才建立代理對象，因此咱們不須要特殊的編譯器來織入SpringAOP的切面。

Spring只支持方法級別的鏈接點

由於Spring基於動態代理，因此Spring只支持方法鏈接點。Spring缺乏對字段鏈接點的支持，並且它不支持構造器鏈接點。方法以外的鏈接點攔截功能，咱們能夠利用Aspect來補充。

在Spring AOP 中，關注點和橫切關注的區別是什麼？在 spring aop 中 concern 和 cross-cutting concern 的不一樣之處

關注點（concern）是應用中一個模塊的行爲，一個關注點可能會被定義成一個咱們想實現的一個功能。

橫切關注點（cross-cutting concern）是一個關注點，此關注點是整個應用都會使用的功能，並影響整個應用，好比日誌，安全和數據傳輸，幾乎應用的每一個模塊都須要的功能。所以這些都屬於橫切關注點。

Spring通知有哪些類型？

在AOP術語中，切面的工做被稱爲通知，其實是程序執行時要經過SpringAOP框架觸發的代碼段。

Spring切面能夠應用5種類型的通知：

前置通知（Before）：在目標方法被調用以前調用通知功能；
後置通知（After）：在目標方法完成以後調用通知，此時不會關心方法的輸出是什麼；
返回通知（After-returning ）：在目標方法成功執行以後調用通知；
異常通知（After-throwing）：在目標方法拋出異常後調用通知；
環繞通知（Around）：通知包裹了被通知的方法，在被通知的方法調用以前和調用以後執行自定義的行爲。

同一個aspect，不一樣advice的執行順序：

①沒有異常狀況下的執行順序：

around before advice
before advice
target method 執行
around after advice
after advice
afterReturning

②有異常狀況下的執行順序：

around before advice
before advice
target method 執行
around after advice
after advice
afterThrowing:異常發生
java.lang.RuntimeException: 異常發生

什麼是切面 Aspect？

aspect 由 pointcount 和 advice 組成，切面是通知和切點的結合。它既包含了橫切邏輯的定義, 也包括了鏈接點的定義. Spring AOP 就是負責實施切面的框架, 它將切面所定義的橫切邏輯編織到切面所指定的鏈接點中.
AOP 的工做重心在於如何將加強編織目標對象的鏈接點上, 這裏包含兩個工做:

如何經過 pointcut 和 advice 定位到特定的 joinpoint 上
如何在 advice 中編寫切面代碼.

能夠簡單地認爲, 使用 @Aspect 註解的類就是切面.

解釋基於XML Schema方式的切面實現

在這種狀況下，切面由常規類以及基於XML的配置實現。

解釋基於註解的切面實現

在這種狀況下(基於@AspectJ的實現)，涉及到的切面聲明的風格與帶有java5標註的普通java類一致。

有幾種不一樣類型的自動代理？

BeanNameAutoProxyCreator

DefaultAdvisorAutoProxyCreator

Metadata autoproxying

Spring MVC面試題專題部分

什麼是Spring MVC？簡單介紹下你對Spring MVC的理解？

Spring MVC是一個基於Java的實現了MVC設計模式的請求驅動類型的輕量級Web框架，經過把模型-視圖-控制器分離，將web層進行職責解耦，把複雜的web應用分紅邏輯清晰的幾部分，簡化開發，減小出錯，方便組內開發人員之間的配合。

Spring MVC的優勢

（1）能夠支持各類視圖技術,而不只僅侷限於JSP；

（2）與Spring框架集成（如IoC容器、AOP等）；

（3）清晰的角色分配：前端控制器(dispatcherServlet) , 請求處處理器映射（handlerMapping), 處理器適配器（HandlerAdapter), 視圖解析器（ViewResolver）。

（4）支持各類請求資源的映射策略。

核心組件

Spring MVC的主要組件？

（1）前端控制器 DispatcherServlet（不須要程序員開發）

做用：接收請求、響應結果，至關於轉發器，有了DispatcherServlet 就減小了其它組件之間的耦合度。

（2）處理器映射器HandlerMapping（不須要程序員開發）

做用：根據請求的URL來查找Handler

（3）處理器適配器HandlerAdapter

注意：在編寫Handler的時候要按照HandlerAdapter要求的規則去編寫，這樣適配器HandlerAdapter才能夠正確的去執行Handler。

（4）處理器Handler（須要程序員開發）

（5）視圖解析器 ViewResolver（不須要程序員開發）

做用：進行視圖的解析，根據視圖邏輯名解析成真正的視圖（view）

（6）視圖View（須要程序員開發jsp）

View是一個接口，它的實現類支持不一樣的視圖類型（jsp，freemarker，pdf等等）

什麼是DispatcherServlet

Spring的MVC框架是圍繞DispatcherServlet來設計的，它用來處理全部的HTTP請求和響應。

什麼是Spring MVC框架的控制器？

控制器提供一個訪問應用程序的行爲，此行爲一般經過服務接口實現。控制器解析用戶輸入並將其轉換爲一個由視圖呈現給用戶的模型。Spring用一個很是抽象的方式實現了一個控制層，容許用戶建立多種用途的控制器。

Spring MVC的控制器是否是單例模式,若是是,有什麼問題,怎麼解決？

答：是單例模式,因此在多線程訪問的時候有線程安全問題,不要用同步,會影響性能的,解決方案是在控制器裏面不能寫字段。

工做原理

請描述Spring MVC的工做流程？描述一下 DispatcherServlet 的工做流程？

（1）用戶發送請求至前端控制器DispatcherServlet；
（2） DispatcherServlet收到請求後，調用HandlerMapping處理器映射器，請求獲取Handle；
（3）處理器映射器根據請求url找到具體的處理器，生成處理器對象及處理器攔截器(若是有則生成)一併返回給DispatcherServlet；
（4）DispatcherServlet 調用 HandlerAdapter處理器適配器；
（5）HandlerAdapter 通過適配調用具體處理器(Handler，也叫後端控制器)；
（6）Handler執行完成返回ModelAndView；
（7）HandlerAdapter將Handler執行結果ModelAndView返回給DispatcherServlet；
（8）DispatcherServlet將ModelAndView傳給ViewResolver視圖解析器進行解析；
（9）ViewResolver解析後返回具體View；
（10）DispatcherServlet對View進行渲染視圖（即將模型數據填充至視圖中）
（11）DispatcherServlet響應用戶。

MVC框架

MVC是什麼？MVC設計模式的好處有哪些

mvc是一種設計模式（設計模式就是平常開發中編寫代碼的一種好的方法和經驗的總結）。模型（model）-視圖（view）-控制器（controller），三層架構的設計模式。用於實現前端頁面的展示與後端業務數據處理的分離。

mvc設計模式的好處

1.分層設計，實現了業務系統各個組件之間的解耦，有利於業務系統的可擴展性，可維護性。

2.有利於系統的並行開發，提高開發效率。

經常使用註解

註解原理是什麼

註解本質是一個繼承了Annotation的特殊接口，其具體實現類是Java運行時生成的動態代理類。咱們經過反射獲取註解時，返回的是Java運行時生成的動態代理對象。經過代理對象調用自定義註解的方法，會最終調用AnnotationInvocationHandler的invoke方法。該方法會從memberValues這個Map中索引出對應的值。而memberValues的來源是Java常量池。

Spring MVC經常使用的註解有哪些？

@RequestMapping：用於處理請求 url 映射的註解，可用於類或方法上。用於類上，則表示類中的全部響應請求的方法都是以該地址做爲父路徑。

@RequestBody：註解實現接收http請求的json數據，將json轉換爲java對象。

@ResponseBody：註解實現將conreoller方法返回對象轉化爲json對象響應給客戶。

SpingMvc中的控制器的註解通常用哪一個,有沒有別的註解能夠替代？

答：通常用@Controller註解,也可使用@RestController,@RestController註解至關於@ResponseBody ＋ @Controller,表示是表現層,除此以外，通常不用別的註解代替。

@Controller註解的做用

在Spring MVC 中，控制器Controller 負責處理由DispatcherServlet 分發的請求，它把用戶請求的數據通過業務處理層處理以後封裝成一個Model ，而後再把該Model 返回給對應的View 進行展現。在Spring MVC 中提供了一個很是簡便的定義Controller 的方法，你無需繼承特定的類或實現特定的接口，只需使用@Controller 標記一個類是Controller ，而後使用@RequestMapping 和@RequestParam 等一些註解用以定義URL 請求和Controller 方法之間的映射，這樣的Controller 就能被外界訪問到。此外Controller 不會直接依賴於HttpServletRequest 和HttpServletResponse 等HttpServlet 對象，它們能夠經過Controller 的方法參數靈活的獲取到。

@Controller 用於標記在一個類上，使用它標記的類就是一個Spring MVC Controller 對象。分發處理器將會掃描使用了該註解的類的方法，並檢測該方法是否使用了@RequestMapping 註解。@Controller 只是定義了一個控制器類，而使用@RequestMapping 註解的方法纔是真正處理請求的處理器。單單使用@Controller 標記在一個類上還不能真正意義上的說它就是Spring MVC 的一個控制器類，由於這個時候Spring 還不認識它。那麼要如何作Spring 才能認識它呢？這個時候就須要咱們把這個控制器類交給Spring 來管理。有兩種方式：

在Spring MVC 的配置文件中定義MyController 的bean 對象。
在Spring MVC 的配置文件中告訴Spring 該到哪裏去找標記爲@Controller 的Controller 控制器。

@RequestMapping註解的做用

RequestMapping是一個用來處理請求地址映射的註解，可用於類或方法上。用於類上，表示類中的全部響應請求的方法都是以該地址做爲父路徑。

RequestMapping註解有六個屬性，下面咱們把她分紅三類進行說明（下面有相應示例）。

value， method

value：指定請求的實際地址，指定的地址能夠是URI Template 模式（後面將會說明）；

method：指定請求的method類型， GET、POST、PUT、DELETE等；

consumes，produces

consumes：指定處理請求的提交內容類型（Content-Type），例如application/json, text/html;

produces: 指定返回的內容類型，僅當request請求頭中的(Accept)類型中包含該指定類型才返回；

params，headers

params：指定request中必須包含某些參數值是，才讓該方法處理。

headers：指定request中必須包含某些指定的header值，才能讓該方法處理請求。

@ResponseBody註解的做用

做用：該註解用於將Controller的方法返回的對象，經過適當的HttpMessageConverter轉換爲指定格式後，寫入到Response對象的body數據區。

使用時機：返回的數據不是html標籤的頁面，而是其餘某種格式的數據時（如json、xml等）使用；

@PathVariable和@RequestParam的區別

請求路徑上有個id的變量值，能夠經過@PathVariable來獲取 @RequestMapping(value = 「/page/{id}」, method = RequestMethod.GET)

@RequestParam用來得到靜態的URL請求入參 spring註解時action裏用到。

其餘

Spring MVC與Struts2區別

相同點

都是基於mvc的表現層框架，都用於web項目的開發。

不一樣點

1.前端控制器不同。Spring MVC的前端控制器是servlet：DispatcherServlet。struts2的前端控制器是filter：StrutsPreparedAndExcutorFilter。

2.請求參數的接收方式不同。Spring MVC是使用方法的形參接收請求的參數，基於方法的開發，線程安全，能夠設計爲單例或者多例的開發，推薦使用單例模式的開發（執行效率更高），默認就是單例開發模式。struts2是經過類的成員變量接收請求的參數，是基於類的開發，線程不安全，只能設計爲多例的開發。

3.Struts採用值棧存儲請求和響應的數據，經過OGNL存取數據，Spring MVC經過參數解析器是將request請求內容解析，並給方法形參賦值，將數據和視圖封裝成ModelAndView對象，最後又將ModelAndView中的模型數據經過reques域傳輸到頁面。Jsp視圖解析器默認使用jstl。

4.與spring整合不同。Spring MVC是spring框架的一部分，不須要整合。在企業項目中，Spring MVC使用更多一些。

Spring MVC怎麼樣設定重定向和轉發的？

（1）轉發：在返回值前面加"forward:"，譬如"forward:user.do?name=method4"

（2）重定向：在返回值前面加"redirect:"，譬如"redirect:http://www.baidu.com"

Spring MVC怎麼和AJAX相互調用的？

經過Jackson框架就能夠把Java裏面的對象直接轉化成Js能夠識別的Json對象。具體步驟以下：

（1）加入Jackson.jar

（2）在配置文件中配置json的映射

（3）在接受Ajax方法裏面能夠直接返回Object,List等,但方法前面要加上@ResponseBody註解。

如何解決POST請求中文亂碼問題，GET的又如何處理呢？

（1）解決post請求亂碼問題：

在web.xml中配置一個CharacterEncodingFilter過濾器，設置成utf-8；

<filter>
    <filter-name>CharacterEncodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>

    <init-param>
        <param-name>encoding</param-name>
        <param-value>utf-8</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>CharacterEncodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

（2）get請求中文參數出現亂碼解決方法有兩個：

①修改tomcat配置文件添加編碼與工程編碼一致，以下：

<ConnectorURIEncoding="utf-8" connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

②另一種方法對參數進行從新編碼：

String userName = new String(request.getParamter(「userName」).getBytes(「ISO8859-1」),「utf-8」)

ISO8859-1是tomcat默認編碼，須要將tomcat編碼後的內容按utf-8編碼。

Spring MVC的異常處理？

答：能夠將異常拋給Spring框架，由Spring框架來處理；咱們只須要配置簡單的異常處理器，在異常處理器中添視圖頁面便可。

若是在攔截請求中，我想攔截get方式提交的方法,怎麼配置

答：能夠在@RequestMapping註解裏面加上method=RequestMethod.GET。

怎樣在方法裏面獲得Request,或者Session？

答：直接在方法的形參中聲明request,Spring MVC就自動把request對象傳入。

若是想在攔截的方法裏面獲得從前臺傳入的參數,怎麼獲得？

答：直接在形參裏面聲明這個參數就能夠,但必須名字和傳過來的參數同樣。

若是前臺有不少個參數傳入,而且這些參數都是一個對象的,那麼怎麼樣快速獲得這個對象？

答：直接在方法中聲明這個對象,Spring MVC就自動會把屬性賦值到這個對象裏面。

Spring MVC中函數的返回值是什麼？

答：返回值能夠有不少類型,有String, ModelAndView。ModelAndView類把視圖和數據都合併的一塊兒的，但通常用String比較好。

Spring MVC用什麼對象從後臺向前臺傳遞數據的？

答：經過ModelMap對象,能夠在這個對象裏面調用put方法,把對象加到裏面,前臺就能夠經過el表達式拿到。

怎麼樣把ModelMap裏面的數據放入Session裏面？

答：能夠在類上面加上@SessionAttributes註解,裏面包含的字符串就是要放入session裏面的key。

Spring MVC裏面攔截器是怎麼寫的

有兩種寫法,一種是實現HandlerInterceptor接口，另一種是繼承適配器類，接着在接口方法當中，實現處理邏輯；而後在Spring MVC的配置文件中配置攔截器便可：

<!-- 配置Spring MVC的攔截器 -->
<mvc:interceptors>
    <!-- 配置一個攔截器的Bean就能夠了 默認是對全部請求都攔截 -->
    <bean id="myInterceptor" class="com.zwp.action.MyHandlerInterceptor"></bean>
    <!-- 只針對部分請求攔截 -->
    <mvc:interceptor>
       <mvc:mapping path="/modelMap.do" />
       <bean class="com.zwp.action.MyHandlerInterceptorAdapter" />
    </mvc:interceptor>
</mvc:interceptors>

介紹一下 WebApplicationContext

WebApplicationContext 繼承了ApplicationContext 並增長了一些WEB應用必備的特有功能，它不一樣於通常的ApplicationContext ，由於它能處理主題，並找到被關聯的servlet。

Tomcat 專題部分

Tomcat是什麼？

Tomcat 服務器Apache軟件基金會項目中的一個核心項目，是一個免費的開放源代碼的Web 應用服務器，屬於輕量級應用服務器，在中小型系統和併發訪問用戶不是不少的場合下被廣泛使用，是開發和調試JSP 程序的首選。

Tomcat的缺省端口是多少，怎麼修改

找到Tomcat目錄下的conf文件夾
進入conf文件夾裏面找到server.xml文件
打開server.xml文件
在server.xml文件裏面找到下列信息
把Connector標籤的8080端口改爲你想要的端口

<Service name="Catalina">
<Connector port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" />

tomcat 有哪幾種Connector 運行模式(優化)？

下面，咱們先大體瞭解Tomcat Connector的三種運行模式。

BIO：同步並阻塞 一個線程處理一個請求。缺點：併發量高時，線程數較多，浪費資源。Tomcat7或如下，在Linux系統中默認使用這種方式。

配製項：protocol=」HTTP/1.1」

NIO：同步非阻塞IO

利用Java的異步IO處理，能夠經過少許的線程處理大量的請求，能夠複用同一個線程處理多個connection(多路複用)。

Tomcat8在Linux系統中默認使用這種方式。

Tomcat7必須修改Connector配置來啓動。

配製項：protocol=」org.apache.coyote.http11.Http11NioProtocol」

備註：咱們經常使用的Jetty，Mina，ZooKeeper等都是基於java nio實現.
APR：即Apache Portable Runtime，從操做系統層面解決io阻塞問題。AIO方式，****異步非阻塞IO(Java NIO2又叫AIO) 主要與NIO的區別主要是操做系統的底層區別.能夠作個比喻:比做快遞，NIO就是網購後要本身到官網查下快遞是否已經到了(多是屢次)，而後本身去取快遞；AIO就是快遞員送貨上門了(不用關注快遞進度)。

配製項：protocol=」org.apache.coyote.http11.Http11AprProtocol」

備註：需在本地服務器安裝APR庫。Tomcat7或Tomcat8在Win7或以上的系統中啓動默認使用這種方式。Linux若是安裝了apr和native，Tomcat直接啓動就支持apr。

Tomcat有幾種部署方式？

在Tomcat中部署Web應用的方式主要有以下幾種：

利用Tomcat的自動部署。

把web應用拷貝到webapps目錄。Tomcat在啓動時會加載目錄下的應用，並將編譯後的結果放入work目錄下。
使用Manager App控制檯部署。

在tomcat主頁點擊「Manager App」進入應用管理控制檯，能夠指定一個web應用的路徑或war文件。
修改conf/server.xml文件部署。

修改conf/server.xml文件，增長Context節點能夠部署應用。
增長自定義的Web部署文件。

在conf/Catalina/localhost/ 路徑下增長 xyz.xml文件，內容是Context節點，能夠部署應用。

tomcat容器是如何建立servlet類實例？用到了什麼原理？

當容器啓動時，會讀取在webapps目錄下全部的web應用中的web.xml文件，而後對 xml文件進行解析，並讀取servlet註冊信息。而後，將每一個應用中註冊的servlet類都進行加載，並經過 反射的方式實例化。（有時候也是在第一次請求時實例化）
在servlet註冊時加上1若是爲正數，則在一開始就實例化，若是不寫或爲負數，則第一次請求實例化。

Tomcat工做模式

Tomcat做爲servlet容器，有三種工做模式：

一、獨立的servlet容器，servlet容器是web服務器的一部分；
二、進程內的servlet容器，servlet容器是做爲web服務器的插件和java容器的實現，web服務器插件在內部地址空間打開一個jvm使得java容器在內部得以運行。反應速度快但伸縮性不足；
三、進程外的servlet容器，servlet容器運行於web服務器以外的地址空間，並做爲web服務器的插件和java容器實現的結合。反應時間不如進程內但伸縮性和穩定性比進程內優；

進入Tomcat的請求能夠根據Tomcat的工做模式分爲以下兩類：

Tomcat做爲應用程序服務器：請求來自於前端的web服務器，這多是Apache, IIS, Nginx等；
Tomcat做爲獨立服務器：請求來自於web瀏覽器；

面試時問到Tomcat相關問題的概率並不高，正式由於如此，不少人忽略了對Tomcat相關技能的掌握，下面這一篇文章整理了Tomcat相關的系統架構，介紹了Server、Service、Connector、Container之間的關係，各個模塊的功能，能夠說把這幾個掌握住了，Tomcat相關的面試題你就不會有任何問題了！另外，在面試的時候你還要有意識無心識的往Tomcat這個地方引，就好比說常見的Spring MVC的執行流程，一個URL的完整調用鏈路，這些相關的題目你是能夠往Tomcat處理請求的這個過程去說的！掌握了Tomcat這些技能，面試官必定會佩服你的！

學了本章以後你應該明白的是：

Server、Service、Connector、Container四大組件之間的關係和聯繫，以及他們的主要功能點；
Tomcat執行的總體架構，請求是如何被一步步處理的；
Engine、Host、Context、Wrapper相關的概念關係；
Container是如何處理請求的；
Tomcat用到的相關設計模式；

Tomcat頂層架構

俗話說，站在巨人的肩膀上看世界，通常學習的時候也是先總覽一下總體，而後逐個部分個個擊破，最後造成思路，瞭解具體細節，Tomcat的結構很複雜，可是 Tomcat 很是的模塊化，找到了 Tomcat 最核心的模塊，問題才能夠遊刃而解，瞭解了 Tomcat 的總體架構對之後深刻了解 Tomcat 來講相當重要！

先上一張Tomcat的頂層結構圖（圖A），以下：

Tomcat中最頂層的容器是Server，表明着整個服務器，從上圖中能夠看出，一個Server能夠包含至少一個Service，便可以包含多個Service，用於具體提供服務。

Service主要包含兩個部分：Connector和Container。從上圖中能夠看出 Tomcat 的心臟就是這兩個組件，他們的做用以下：

Connector用於處理鏈接相關的事情，並提供Socket與Request請求和Response響應相關的轉化;
Container用於封裝和管理Servlet，以及具體處理Request請求；

一個Tomcat中只有一個Server，一個Server能夠包含多個Service，一個Service只有一個Container，可是能夠有多個Connectors，這是由於一個服務能夠有多個鏈接，如同時提供Http和Https連接，也能夠提供向相同協議不一樣端口的鏈接，示意圖以下（Engine、Host、Context下面會說到）：

多個 Connector 和一個 Container 就造成了一個 Service，有了 Service 就能夠對外提供服務了，可是 Service 還要一個生存的環境，必需要有人可以給她生命、掌握其生死大權，那就非 Server 莫屬了！因此整個 Tomcat 的生命週期由 Server 控制。

另外，上述的包含關係或者說是父子關係，均可以在tomcat的conf目錄下的server.xml配置文件中看出，下圖是刪除了註釋內容以後的一個完整的server.xml配置文件（Tomcat版本爲8.0）

詳細的配置文件內容能夠到Tomcat官網查看：Tomcat配置文件

上邊的配置文件，還能夠經過下邊的一張結構圖更清楚的理解：

Server標籤設置的端口號爲8005，shutdown=」SHUTDOWN」，表示在8005端口監聽「SHUTDOWN」命令，若是接收到了就會關閉Tomcat。一個Server有一個Service，固然還能夠進行配置，一個Service有多個Connector，Service左邊的內容都屬於Container的，Service下邊是Connector。

Tomcat頂層架構小結

Tomcat中只有一個Server，一個Server能夠有多個Service，一個Service能夠有多個Connector和一個Container；
Server掌管着整個Tomcat的生死大權；
Service 是對外提供服務的；
Connector用於接受請求並將請求封裝成Request和Response來具體處理；
Container用於封裝和管理Servlet，以及具體處理request請求；

知道了整個Tomcat頂層的分層架構和各個組件之間的關係以及做用，對於絕大多數的開發人員來講Server和Service對咱們來講確實很遠，而咱們開發中絕大部分進行配置的內容是屬於Connector和Container的，因此接下來介紹一下Connector和Container。

Connector和Container的微妙關係

由上述內容咱們大體能夠知道一個請求發送到Tomcat以後，首先通過Service而後會交給咱們的Connector，Connector用於接收請求並將接收的請求封裝爲Request和Response來具體處理，Request和Response封裝完以後再交由Container進行處理，Container處理完請求以後再返回給Connector，最後在由Connector經過Socket將處理的結果返回給客戶端，這樣整個請求的就處理完了！

Connector最底層使用的是Socket來進行鏈接的，Request和Response是按照HTTP協議來封裝的，因此Connector同時須要實現TCP/IP協議和HTTP協議！

Tomcat既然須要處理請求，那麼確定須要先接收到這個請求，接收請求這個東西咱們首先就須要看一下Connector！

Connector架構分析

Connector用於接受請求並將請求封裝成Request和Response，而後交給Container進行處理，Container處理完以後在交給Connector返回給客戶端。

所以，咱們能夠把Connector分爲四個方面進行理解：

Connector如何接受請求的？
如何將請求封裝成Request和Response的？
封裝完以後的Request和Response如何交給Container進行處理的？
Container處理完以後如何交給Connector並返回給客戶端的？

首先看一下Connector的結構圖（圖B），以下所示：

Connector就是使用ProtocolHandler來處理請求的，不一樣的ProtocolHandler表明不一樣的鏈接類型，好比：Http11Protocol使用的是普通Socket來鏈接的，Http11NioProtocol使用的是NioSocket來鏈接的。

其中ProtocolHandler由包含了三個部件：Endpoint、Processor、Adapter。

Endpoint用來處理底層Socket的網絡鏈接，Processor用於將Endpoint接收到的Socket封裝成Request，Adapter用於將Request交給Container進行具體的處理。
Endpoint因爲是處理底層的Socket網絡鏈接，所以Endpoint是用來實現TCP/IP協議的，而Processor用來實現HTTP協議的，Adapter將請求適配到Servlet容器進行具體的處理。
Endpoint的抽象實現AbstractEndpoint裏面定義的Acceptor和AsyncTimeout兩個內部類和一個Handler接口。Acceptor用於監聽請求，AsyncTimeout用於檢查異步Request的超時，Handler用於處理接收到的Socket，在內部調用Processor進行處理。

至此，咱們應該很輕鬆的回答1，2，3的問題了，可是4仍是不知道，那麼咱們就來看一下Container是如何進行處理的以及處理完以後是如何將處理完的結果返回給Connector的？

Container架構分析

Container用於封裝和管理Servlet，以及具體處理Request請求，在Container內部包含了4個子容器，結構圖以下（圖C）：

4個子容器的做用分別是：

Engine：引擎，用來管理多個站點，一個Service最多隻能有一個Engine；
Host：表明一個站點，也能夠叫虛擬主機，經過配置Host就能夠添加站點；
Context：表明一個應用程序，對應着平時開發的一套程序，或者一個WEB-INF目錄以及下面的web.xml文件；
Wrapper：每一Wrapper封裝着一個Servlet；

下面找一個Tomcat的文件目錄對照一下，以下圖所示：

Context和Host的區別是Context表示一個應用，咱們的Tomcat中默認的配置下webapps下的每個文件夾目錄都是一個Context，其中ROOT目錄中存放着主應用，其餘目錄存放着子應用，而整個webapps就是一個Host站點。

咱們訪問應用Context的時候，若是是ROOT下的則直接使用域名就能夠訪問，例如：www.baidu.com，若是是Host（webapps）下的其餘應用，則可使用www.baidu.com/docs進行訪問，固然默認指定的根應用（ROOT）是能夠進行設定的，只不過Host站點下默認的主應用是ROOT目錄下的。

看到這裏咱們知道Container是什麼，可是仍是不知道Container是如何進行請求處理的以及處理完以後是如何將處理完的結果返回給Connector的？別急！下邊就開始探討一下Container是如何進行處理的！

Container如何處理請求的

Container處理請求是使用Pipeline-Valve管道來處理的！（Valve是閥門之意）

Pipeline-Valve是責任鏈模式，責任鏈模式是指在一個請求處理的過程當中有不少處理者依次對請求進行處理，每一個處理者負責作本身相應的處理，處理完以後將處理後的結果返回，再讓下一個處理者繼續處理。

可是！Pipeline-Valve使用的責任鏈模式和普通的責任鏈模式有些不一樣！區別主要有如下兩點：

每一個Pipeline都有特定的Valve，並且是在管道的最後一個執行，這個Valve叫作BaseValve，BaseValve是不可刪除的；
在上層容器的管道的BaseValve中會調用下層容器的管道。

咱們知道Container包含四個子容器，而這四個子容器對應的BaseValve分別在：StandardEngineValve、StandardHostValve、StandardContextValve、StandardWrapperValve。

Pipeline的處理流程圖以下（圖D）：

Connector在接收到請求後會首先調用最頂層容器的Pipeline來處理，這裏的最頂層容器的Pipeline就是EnginePipeline（Engine的管道）；
在Engine的管道中依次會執行EngineValve一、EngineValve2等等，最後會執行StandardEngineValve，在StandardEngineValve中會調用Host管道，而後再依次執行Host的HostValve一、HostValve2等，最後在執行StandardHostValve，而後再依次調用Context的管道和Wrapper的管道，最後執行到StandardWrapperValve。
當執行到StandardWrapperValve的時候，會在StandardWrapperValve中建立FilterChain，並調用其doFilter方法來處理請求，這個FilterChain包含着咱們配置的與請求相匹配的Filter和Servlet，其doFilter方法會依次調用全部的Filter的doFilter方法和Servlet的service方法，這樣請求就獲得了處理！
當全部的Pipeline-Valve都執行完以後，而且處理完了具體的請求，這個時候就能夠將返回的結果交給Connector了，Connector在經過Socket的方式將結果返回給客戶端。