九、設(shè)計(jì)模式

88. 說(shuō)一下你熟悉的設(shè)計(jì)模式？

參考：常用的設(shè)計(jì)模式匯總，超詳細(xì)！

89. 簡(jiǎn)單工廠和抽象工廠有什么區(qū)別？

簡(jiǎn)單工廠模式：

這個(gè)模式本身很簡(jiǎn)單而且使用在業(yè)務(wù)較簡(jiǎn)單的情況下。一般用于小項(xiàng)目或者具體產(chǎn)品很少擴(kuò)展的情況（這樣工廠類才不用經(jīng)常更改）。

它由三種角色組成：

工廠類角色：這是本模式的核心，含有一定的商業(yè)邏輯和判斷邏輯，根據(jù)邏輯不同，產(chǎn)生具體的工廠產(chǎn)品。如例子中的Driver類。

抽象產(chǎn)品角色：它一般是具體產(chǎn)品繼承的父類或者實(shí)現(xiàn)的接口。由接口或者抽象類來(lái)實(shí)現(xiàn)。如例中的Car接口。

具體產(chǎn)品角色：工廠類所創(chuàng)建的對(duì)象就是此角色的實(shí)例。在java中由一個(gè)具體類實(shí)現(xiàn)，如例子中的Benz、Bmw類。

來(lái)用類圖來(lái)清晰的表示下的它們之間的關(guān)系：

抽象工廠模式：

先來(lái)認(rèn)識(shí)下什么是產(chǎn)品族： 位于不同產(chǎn)品等級(jí)結(jié)構(gòu)中，功能相關(guān)聯(lián)的產(chǎn)品組成的家族。

圖中的BmwCar和BenzCar就是兩個(gè)產(chǎn)品樹（產(chǎn)品層次結(jié)構(gòu)）；而如圖所示的BenzSportsCar和BmwSportsCar就是一個(gè)產(chǎn)品族。他們都可以放到跑車家族中，因此功能有所關(guān)聯(lián)。同理BmwBussinessCar和BenzBusinessCar也是一個(gè)產(chǎn)品族。

可以這么說(shuō)，它和工廠方法模式的區(qū)別就在于需要?jiǎng)?chuàng)建對(duì)象的復(fù)雜程度上。而且抽象工廠模式是三個(gè)里面最為抽象、最具一般性的。抽象工廠模式的用意為：給客戶端提供一個(gè)接口，可以創(chuàng)建多個(gè)產(chǎn)品族中的產(chǎn)品對(duì)象。

而且使用抽象工廠模式還要滿足一下條件：

系統(tǒng)中有多個(gè)產(chǎn)品族，而系統(tǒng)一次只可能消費(fèi)其中一族產(chǎn)品

同屬于同一個(gè)產(chǎn)品族的產(chǎn)品以其使用。

來(lái)看看抽象工廠模式的各個(gè)角色（和工廠方法的如出一轍）：

抽象工廠角色： 這是工廠方法模式的核心，它與應(yīng)用程序無(wú)關(guān)。是具體工廠角色必須實(shí)現(xiàn)的接口或者必須繼承的父類。在java中它由抽象類或者接口來(lái)實(shí)現(xiàn)。

具體工廠角色：它含有和具體業(yè)務(wù)邏輯有關(guān)的代碼。由應(yīng)用程序調(diào)用以創(chuàng)建對(duì)應(yīng)的具體產(chǎn)品的對(duì)象。在java中它由具體的類來(lái)實(shí)現(xiàn)。

抽象產(chǎn)品角色：它是具體產(chǎn)品繼承的父類或者是實(shí)現(xiàn)的接口。在java中一般有抽象類或者接口來(lái)實(shí)現(xiàn)。

具體產(chǎn)品角色：具體工廠角色所創(chuàng)建的對(duì)象就是此角色的實(shí)例。在java中由具體的類來(lái)實(shí)現(xiàn)。

十、Spring / Spring MVC

90. 為什么要使用 spring？

1.簡(jiǎn)介

目的：解決企業(yè)應(yīng)用開發(fā)的復(fù)雜性

功能：使用基本的JavaBean代替EJB，并提供了更多的企業(yè)應(yīng)用功能

范圍：任何Java應(yīng)用

簡(jiǎn)單來(lái)說(shuō)，Spring是一個(gè)輕量級(jí)的控制反轉(zhuǎn)(IoC)和面向切面(AOP)的容器框架。

2.輕量

從大小與開銷兩方面而言Spring都是輕量的。完整的Spring框架可以在一個(gè)大小只有1MB多的JAR文件里發(fā)布。并且Spring所需的處理開銷也是微不足道的。此外，Spring是非侵入式的：典型地，Spring應(yīng)用中的對(duì)象不依賴于Spring的特定類。

3.控制反轉(zhuǎn)　　

Spring通過(guò)一種稱作控制反轉(zhuǎn)（IoC）的技術(shù)促進(jìn)了松耦合。當(dāng)應(yīng)用了IoC，一個(gè)對(duì)象依賴的其它對(duì)象會(huì)通過(guò)被動(dòng)的方式傳遞進(jìn)來(lái)，而不是這個(gè)對(duì)象自己創(chuàng)建或者查找依賴對(duì)象。你可以認(rèn)為IoC與JNDI相反——不是對(duì)象從容器中查找依賴，而是容器在對(duì)象初始化時(shí)不等對(duì)象請(qǐng)求就主動(dòng)將依賴傳遞給它。

4.面向切面

Spring提供了面向切面編程的豐富支持，允許通過(guò)分離應(yīng)用的業(yè)務(wù)邏輯與系統(tǒng)級(jí)服務(wù)（例如審計(jì)（auditing）和事務(wù)（transaction）管理）進(jìn)行內(nèi)聚性的開發(fā)。應(yīng)用對(duì)象只實(shí)現(xiàn)它們應(yīng)該做的——完成業(yè)務(wù)邏輯——僅此而已。它們并不負(fù)責(zé)（甚至是意識(shí)）其它的系統(tǒng)級(jí)關(guān)注點(diǎn)，例如日志或事務(wù)支持。

5.容器

Spring包含并管理應(yīng)用對(duì)象的配置和生命周期，在這個(gè)意義上它是一種容器，你可以配置你的每個(gè)bean如何被創(chuàng)建——基于一個(gè)可配置原型（prototype），你的bean可以創(chuàng)建一個(gè)單獨(dú)的實(shí)例或者每次需要時(shí)都生成一個(gè)新的實(shí)例——以及它們是如何相互關(guān)聯(lián)的。然而，Spring不應(yīng)該被混同于傳統(tǒng)的重量級(jí)的EJB容器，它們經(jīng)常是龐大與笨重的，難以使用。

6.框架

Spring可以將簡(jiǎn)單的組件配置、組合成為復(fù)雜的應(yīng)用。在Spring中，應(yīng)用對(duì)象被聲明式地組合，典型地是在一個(gè)XML文件里。Spring也提供了很多基礎(chǔ)功能（事務(wù)管理、持久化框架集成等等），將應(yīng)用邏輯的開發(fā)留給了你。

所有Spring的這些特征使你能夠編寫更干凈、更可管理、并且更易于測(cè)試的代碼。它們也為Spring中的各種模塊提供了基礎(chǔ)支持。

91. 解釋一下什么是 aop？

AOP（Aspect-Oriented Programming，面向方面編程），可以說(shuō)是OOP（Object-Oriented

Programing，面向?qū)ο缶幊蹋┑难a(bǔ)充和完善。OOP引入封裝、繼承和多態(tài)性等概念來(lái)建立一種對(duì)象層次結(jié)構(gòu)，用以模擬公共行為的一個(gè)集合。當(dāng)我們需要為分散的對(duì)象引入公共行為的時(shí)候，OOP則顯得無(wú)能為力。也就是說(shuō)，OOP允許你定義從上到下的關(guān)系，但并不適合定義從左到右的關(guān)系。例如日志功能。日志代碼往往水平地散布在所有對(duì)象層次中，而與它所散布到的對(duì)象的核心功能毫無(wú)關(guān)系。對(duì)于其他類型的代碼，如安全性、異常處理和透明的持續(xù)性也是如此。這種散布在各處的無(wú)關(guān)的代碼被稱為橫切（cross-cutting）代碼，在OOP設(shè)計(jì)中，它導(dǎo)致了大量代碼的重復(fù)，而不利于各個(gè)模塊的重用。

而AOP技術(shù)則恰恰相反，它利用一種稱為“橫切”的技術(shù)，剖解開封裝的對(duì)象內(nèi)部，并將那些影響了多個(gè)類的公共行為封裝到一個(gè)可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡(jiǎn)單地說(shuō)，就是將那些與業(yè)務(wù)無(wú)關(guān)，卻為業(yè)務(wù)模塊所共同調(diào)用的邏輯或責(zé)任封裝起來(lái)，便于減少系統(tǒng)的重復(fù)代碼，降低模塊間的耦合度，并有利于未來(lái)的可操作性和可維護(hù)性。AOP代表的是一個(gè)橫向的關(guān)系，如果說(shuō)“對(duì)象”是一個(gè)空心的圓柱體，其中封裝的是對(duì)象的屬性和行為；那么面向方面編程的方法，就仿佛一把利刃，將這些空心圓柱體剖開，以獲得其內(nèi)部的消息。而剖開的切面，也就是所謂的“方面”了。然后它又以巧奪天功的妙手將這些剖開的切面復(fù)原，不留痕跡。

使用“橫切”技術(shù)，AOP把軟件系統(tǒng)分為兩個(gè)部分：核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)。業(yè)務(wù)處理的主要流程是核心關(guān)注點(diǎn)，與之關(guān)系不大的部分是橫切關(guān)注點(diǎn)。橫切關(guān)注點(diǎn)的一個(gè)特點(diǎn)是，他們經(jīng)常發(fā)生在核心關(guān)注點(diǎn)的多處，而各處都基本相似。比如權(quán)限認(rèn)證、日志、事務(wù)處理。Aop的作用在于分離系統(tǒng)中的各種關(guān)注點(diǎn)，將核心關(guān)注點(diǎn)和橫切關(guān)注點(diǎn)分離開來(lái)。正如Avanade公司的高級(jí)方案構(gòu)架師Adam Magee所說(shuō)，AOP的核心思想就是“將應(yīng)用程序中的商業(yè)邏輯同對(duì)其提供支持的通用服務(wù)進(jìn)行分離?！?/p>

92. 解釋一下什么是 ioc？

IOC是Inversion of Control的縮寫，多數(shù)書籍翻譯成“控制反轉(zhuǎn)”。

1996年，Michael Mattson在一篇有關(guān)探討面向?qū)ο罂蚣艿奈恼轮?，首先提出了IOC 這個(gè)概念。對(duì)于面向?qū)ο笤O(shè)計(jì)及編程的基本思想，前面我們已經(jīng)講了很多了，不再贅述，簡(jiǎn)單來(lái)說(shuō)就是把復(fù)雜系統(tǒng)分解成相互合作的對(duì)象，這些對(duì)象類通過(guò)封裝以后，內(nèi)部實(shí)現(xiàn)對(duì)外部是透明的，從而降低了解決問(wèn)題的復(fù)雜度，而且可以靈活地被重用和擴(kuò)展。

IOC理論提出的觀點(diǎn)大體是這樣的：借助于“第三方”實(shí)現(xiàn)具有依賴關(guān)系的對(duì)象之間的解耦。如下圖：

大家看到了吧，由于引進(jìn)了中間位置的“第三方”，也就是IOC容器，使得A、B、C、D這4個(gè)對(duì)象沒(méi)有了耦合關(guān)系，齒輪之間的傳動(dòng)全部依靠“第三方”了，全部對(duì)象的控制權(quán)全部上繳給“第三方”IOC容器，所以，IOC容器成了整個(gè)系統(tǒng)的關(guān)鍵核心，它起到了一種類似“粘合劑”的作用，把系統(tǒng)中的所有對(duì)象粘合在一起發(fā)揮作用，如果沒(méi)有這個(gè)“粘合劑”，對(duì)象與對(duì)象之間會(huì)彼此失去聯(lián)系，這就是有人把IOC容器比喻成“粘合劑”的由來(lái)。

我們?cè)賮?lái)做個(gè)試驗(yàn)：把上圖中間的IOC容器拿掉，然后再來(lái)看看這套系統(tǒng)：

我們現(xiàn)在看到的畫面，就是我們要實(shí)現(xiàn)整個(gè)系統(tǒng)所需要完成的全部?jī)?nèi)容。這時(shí)候，A、B、C、D這4個(gè)對(duì)象之間已經(jīng)沒(méi)有了耦合關(guān)系，彼此毫無(wú)聯(lián)系，這樣的話，當(dāng)你在實(shí)現(xiàn)A的時(shí)候，根本無(wú)須再去考慮B、C和D了，對(duì)象之間的依賴關(guān)系已經(jīng)降低到了最低程度。所以，如果真能實(shí)現(xiàn)IOC容器，對(duì)于系統(tǒng)開發(fā)而言，這將是一件多么美好的事情，參與開發(fā)的每一成員只要實(shí)現(xiàn)自己的類就可以了，跟別人沒(méi)有任何關(guān)系！

我們?cè)賮?lái)看看，控制反轉(zhuǎn)(IOC)到底為什么要起這么個(gè)名字？我們來(lái)對(duì)比一下：

軟件系統(tǒng)在沒(méi)有引入IOC容器之前，如圖1所示，對(duì)象A依賴于對(duì)象B，那么對(duì)象A在初始化或者運(yùn)行到某一點(diǎn)的時(shí)候，自己必須主動(dòng)去創(chuàng)建對(duì)象B或者使用已經(jīng)創(chuàng)建的對(duì)象B。無(wú)論是創(chuàng)建還是使用對(duì)象B，控制權(quán)都在自己手上。

軟件系統(tǒng)在引入IOC容器之后，這種情形就完全改變了，如圖3所示，由于IOC容器的加入，對(duì)象A與對(duì)象B之間失去了直接聯(lián)系，所以，當(dāng)對(duì)象A運(yùn)行到需要對(duì)象B的時(shí)候，IOC容器會(huì)主動(dòng)創(chuàng)建一個(gè)對(duì)象B注入到對(duì)象A需要的地方。

通過(guò)前后的對(duì)比，我們不難看出來(lái)：對(duì)象A獲得依賴對(duì)象B的過(guò)程,由主動(dòng)行為變?yōu)榱吮粍?dòng)行為，控制權(quán)顛倒過(guò)來(lái)了，這就是“控制反轉(zhuǎn)”這個(gè)名稱的由來(lái)。

93. spring 有哪些主要模塊？

Spring框架至今已集成了20多個(gè)模塊。這些模塊主要被分如下圖所示的核心容器、數(shù)據(jù)訪問(wèn)/集成,、Web、AOP（面向切面編程）、工具、消息和測(cè)試模塊。

更多信息：howtodoinjava.com/java-spring-framework-tutorials/

94. spring 常用的注入方式有哪些？

Spring通過(guò)DI（依賴注入）實(shí)現(xiàn)IOC（控制反轉(zhuǎn)），常用的注入方式主要有三種：

構(gòu)造方法注入

setter注入

基于注解的注入

95. spring 中的 bean 是線程安全的嗎？

Spring容器中的Bean是否線程安全，容器本身并沒(méi)有提供Bean的線程安全策略，因此可以說(shuō)spring容器中的Bean本身不具備線程安全的特性，但是具體還是要結(jié)合具體scope的Bean去研究。

96. spring 支持幾種 bean 的作用域？

當(dāng)通過(guò)spring容器創(chuàng)建一個(gè)Bean實(shí)例時(shí)，不僅可以完成Bean實(shí)例的實(shí)例化，還可以為Bean指定特定的作用域。Spring支持如下5種作用域：

singleton：?jiǎn)卫Ｊ剑谡麄€(gè)Spring IoC容器中，使用singleton定義的Bean將只有一個(gè)實(shí)例

prototype：原型模式，每次通過(guò)容器的getBean方法獲取prototype定義的Bean時(shí)，都將產(chǎn)生一個(gè)新的Bean實(shí)例

request：對(duì)于每次HTTP請(qǐng)求，使用request定義的Bean都將產(chǎn)生一個(gè)新實(shí)例，即每次HTTP請(qǐng)求將會(huì)產(chǎn)生不同的Bean實(shí)例。只有在Web應(yīng)用中使用Spring時(shí)，該作用域才有效

session：對(duì)于每次HTTP Session，使用session定義的Bean豆?jié){產(chǎn)生一個(gè)新實(shí)例。同樣只有在Web應(yīng)用中使用Spring時(shí)，該作用域才有效

globalsession：每個(gè)全局的HTTP Session，使用session定義的Bean都將產(chǎn)生一個(gè)新實(shí)例。典型情況下，僅在使用portlet context的時(shí)候有效。同樣只有在Web應(yīng)用中使用Spring時(shí)，該作用域才有效

其中比較常用的是singleton和prototype兩種作用域。對(duì)于singleton作用域的Bean，每次請(qǐng)求該Bean都將獲得相同的實(shí)例。容器負(fù)責(zé)跟蹤Bean實(shí)例的狀態(tài)，負(fù)責(zé)維護(hù)Bean實(shí)例的生命周期行為；如果一個(gè)Bean被設(shè)置成prototype作用域，程序每次請(qǐng)求該id的Bean，Spring都會(huì)新建一個(gè)Bean實(shí)例，然后返回給程序。在這種情況下，Spring容器僅僅使用new

關(guān)鍵字創(chuàng)建Bean實(shí)例，一旦創(chuàng)建成功，容器不在跟蹤實(shí)例，也不會(huì)維護(hù)Bean實(shí)例的狀態(tài)。

如果不指定Bean的作用域，Spring默認(rèn)使用singleton作用域。Java在創(chuàng)建Java實(shí)例時(shí)，需要進(jìn)行內(nèi)存申請(qǐng)；銷毀實(shí)例時(shí)，需要完成垃圾回收，這些工作都會(huì)導(dǎo)致系統(tǒng)開銷的增加。因此，prototype作用域Bean的創(chuàng)建、銷毀代價(jià)比較大。而singleton作用域的Bean實(shí)例一旦創(chuàng)建成功，可以重復(fù)使用。因此，除非必要，否則盡量避免將Bean被設(shè)置成prototype作用域。

97. spring 自動(dòng)裝配 bean 有哪些方式？

Spring容器負(fù)責(zé)創(chuàng)建應(yīng)用程序中的bean同時(shí)通過(guò)ID來(lái)協(xié)調(diào)這些對(duì)象之間的關(guān)系。作為開發(fā)人員，我們需要告訴Spring要?jiǎng)?chuàng)建哪些bean并且如何將其裝配到一起。

spring中bean裝配有兩種方式：

隱式的bean發(fā)現(xiàn)機(jī)制和自動(dòng)裝配

在java代碼或者XML中進(jìn)行顯示配置

當(dāng)然這些方式也可以配合使用。

98. spring 事務(wù)實(shí)現(xiàn)方式有哪些？

編程式事務(wù)管理對(duì)基于 POJO 的應(yīng)用來(lái)說(shuō)是唯一選擇。我們需要在代碼中調(diào)用beginTransaction()、commit()、rollback()等事務(wù)管理相關(guān)的方法，這就是編程式事務(wù)管理。

基于 TransactionProxyFactoryBean 的聲明式事務(wù)管理

基于 @Transactional 的聲明式事務(wù)管理

基于 Aspectj AOP 配置事務(wù)

99. 說(shuō)一下 spring 的事務(wù)隔離？

事務(wù)隔離級(jí)別指的是一個(gè)事務(wù)對(duì)數(shù)據(jù)的修改與另一個(gè)并行的事務(wù)的隔離程度，當(dāng)多個(gè)事務(wù)同時(shí)訪問(wèn)相同數(shù)據(jù)時(shí)，如果沒(méi)有采取必要的隔離機(jī)制，就可能發(fā)生以下問(wèn)題：

臟讀：一個(gè)事務(wù)讀到另一個(gè)事務(wù)未提交的更新數(shù)據(jù)。

幻讀：例如第一個(gè)事務(wù)對(duì)一個(gè)表中的數(shù)據(jù)進(jìn)行了修改，比如這種修改涉及到表中的“全部數(shù)據(jù)行”。同時(shí)，第二個(gè)事務(wù)也修改這個(gè)表中的數(shù)據(jù)，這種修改是向表中插入“一行新數(shù)據(jù)”。那么，以后就會(huì)發(fā)生操作第一個(gè)事務(wù)的用戶發(fā)現(xiàn)表中還存在沒(méi)有修改的數(shù)據(jù)行，就好象發(fā)生了幻覺(jué)一樣。

不可重復(fù)讀：比方說(shuō)在同一個(gè)事務(wù)中先后執(zhí)行兩條一模一樣的select語(yǔ)句，期間在此次事務(wù)中沒(méi)有執(zhí)行過(guò)任何DDL語(yǔ)句，但先后得到的結(jié)果不一致，這就是不可重復(fù)讀。

100. 說(shuō)一下 spring mvc 運(yùn)行流程？

Spring MVC運(yùn)行流程圖：

Spring運(yùn)行流程描述：

1. 用戶向服務(wù)器發(fā)送請(qǐng)求，請(qǐng)求被Spring 前端控制Servelt DispatcherServlet捕獲；

2.?DispatcherServlet對(duì)請(qǐng)求URL進(jìn)行解析，得到請(qǐng)求資源標(biāo)識(shí)符（URI）。然后根據(jù)該URI，調(diào)用HandlerMapping獲得該Handler配置的所有相關(guān)的對(duì)象（包括Handler對(duì)象以及Handler對(duì)象對(duì)應(yīng)的攔截器），最后以HandlerExecutionChain對(duì)象的形式返回；

3.?DispatcherServlet 根據(jù)獲得的Handler，選擇一個(gè)合適的HandlerAdapter；（附注：如果成功獲得HandlerAdapter后，此時(shí)將開始執(zhí)行攔截器的preHandler(...)方法）

4. ?提取Request中的模型數(shù)據(jù)，填充Handler入?yún)?，開始執(zhí)行Handler（Controller)。 在填充Handler的入?yún)⑦^(guò)程中，根據(jù)你的配置，Spring將幫你做一些額外的工作：

HttpMessageConveter： 將請(qǐng)求消息（如Json、xml等數(shù)據(jù)）轉(zhuǎn)換成一個(gè)對(duì)象，將對(duì)象轉(zhuǎn)換為指定的響應(yīng)信息

數(shù)據(jù)轉(zhuǎn)換：對(duì)請(qǐng)求消息進(jìn)行數(shù)據(jù)轉(zhuǎn)換。如String轉(zhuǎn)換成Integer、Double等

數(shù)據(jù)根式化：對(duì)請(qǐng)求消息進(jìn)行數(shù)據(jù)格式化。 如將字符串轉(zhuǎn)換成格式化數(shù)字或格式化日期等

數(shù)據(jù)驗(yàn)證： 驗(yàn)證數(shù)據(jù)的有效性（長(zhǎng)度、格式等），驗(yàn)證結(jié)果存儲(chǔ)到BindingResult或Error中

5. ?Handler執(zhí)行完成后，向DispatcherServlet?返回一個(gè)ModelAndView對(duì)象；

6. ?根據(jù)返回的ModelAndView，選擇一個(gè)適合的ViewResolver（必須是已經(jīng)注冊(cè)到Spring容器中的ViewResolver)返回給DispatcherServlet?；

7.?ViewResolver 結(jié)合Model和View，來(lái)渲染視圖；

8. 將渲染結(jié)果返回給客戶端。

101. spring mvc 有哪些組件？

Spring MVC的核心組件：

DispatcherServlet：中央控制器，把請(qǐng)求給轉(zhuǎn)發(fā)到具體的控制類

Controller：具體處理請(qǐng)求的控制器

HandlerMapping：映射處理器，負(fù)責(zé)映射中央處理器轉(zhuǎn)發(fā)給controller時(shí)的映射策略

ModelAndView：服務(wù)層返回的數(shù)據(jù)和視圖層的封裝類

ViewResolver：視圖解析器，解析具體的視圖

Interceptors ：攔截器，負(fù)責(zé)攔截我們定義的請(qǐng)求然后做處理工作

102. @RequestMapping 的作用是什么？

RequestMapping是一個(gè)用來(lái)處理請(qǐng)求地址映射的注解，可用于類或方法上。用于類上，表示類中的所有響應(yīng)請(qǐng)求的方法都是以該地址作為父路徑。

RequestMapping注解有六個(gè)屬性，下面我們把她分成三類進(jìn)行說(shuō)明。

value， method：

value：指定請(qǐng)求的實(shí)際地址，指定的地址可以是URI Template 模式（后面將會(huì)說(shuō)明）；

method：指定請(qǐng)求的method類型， GET、POST、PUT、DELETE等；

consumes，produces

consumes：指定處理請(qǐng)求的提交內(nèi)容類型（Content-Type），例如application/json, text/html；

produces：指定返回的內(nèi)容類型，僅當(dāng)request請(qǐng)求頭中的(Accept)類型中包含該指定類型才返回；

params，headers

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

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

103. @Autowired 的作用是什么？

《@Autowired用法詳解》：blog.csdn.net/u013257679/article/details/52295106