lagou-java習(xí)題庫

序言:

文章內(nèi)容輸出來源：拉勾教育Java高薪訓(xùn)練營呢撞。
本篇文章是學(xué)習(xí)課程中的一部分面試題集錦(持續(xù)更新中......)

一视译、請說說MyBatis的工作原理辟躏？

1）讀取 MyBatis 配置文件：

mybatis-config.xml 為 MyBatis 的全局配置文件，配置了 MyBatis 的運行環(huán)境等信息涤躲，例如數(shù)據(jù)庫連接信息报嵌。

2）加載映射文件:

映射文件即 SQL 映射文件虱咧，該文件中配置了操作數(shù)據(jù)庫的 SQL 語句，需要在 MyBatis 配置文件 mybatis-config.xml 中加載锚国。
mybatis-config.xml 文件可以加載多個映射文件腕巡，每個文件對應(yīng)數(shù)據(jù)庫中的一張表。

3）構(gòu)造會話工廠：

通過 MyBatis 的環(huán)境等配置信息構(gòu)建會話工廠 SqlSessionFactory跷叉。

4）創(chuàng)建會話對象：

由會話工廠創(chuàng)建 SqlSession 對象逸雹，該對象中包含了執(zhí)行 SQL 語句的所有方法营搅。

5）Executor 執(zhí)行器：

MyBatis 底層定義了一個 Executor 接口來操作數(shù)據(jù)庫云挟，它將根據(jù) SqlSession 傳遞的參數(shù)動態(tài)地生成需要執(zhí)行的 SQL 語句梆砸，同時負(fù)責(zé)查詢緩存的維護(hù)。

6）MappedStatement 對象：

在 Executor 接口的執(zhí)行方法中有一個 MappedStatement 類型的參數(shù)园欣，該參數(shù)是對映射信息的封裝帖世，用于存儲要映射的 SQL 語句的 id、參數(shù)等信息沸枯。

7）輸入?yún)?shù)映射：

輸入?yún)?shù)類型可以是 Map日矫、List 等集合類型，也可以是基本數(shù)據(jù)類型和 POJO 類型绑榴。
輸入?yún)?shù)映射過程類似于 JDBC 對 preparedStatement 對象設(shè)置參數(shù)的過程哪轿。

8）輸出結(jié)果映射：

輸出結(jié)果類型可以是 Map、 List 等集合類型翔怎，也可以是基本數(shù)據(jù)類型和 POJO 類型窃诉。
輸出結(jié)果映射過程類似于 JDBC 對結(jié)果集的解析過程。

二赤套、HashMap存儲原理飘痛，有啥問題，如何避免容握？

一宣脉、存儲原理：

1、HashMap是一個鍵值對的集合剔氏，是非synchronized的塑猖，源碼中每個節(jié)點用Node<K,V>表示。
Node是一個內(nèi)部類谈跛，這里的key為鍵羊苟，value為值，next指向下一個元素币旧，可以看出HashMap中的元素不是一個單純的鍵值對践险，還包含下一個元素的引用。
2吹菱、HashMap的數(shù)據(jù)結(jié)構(gòu)：數(shù)組+(鏈表或紅黑樹)巍虫，數(shù)組是HashMap的主體，鏈表則是主要為了解決哈希沖突而存在的鳍刷。
在HashMap底層使用數(shù)組加（鏈表或紅黑樹）的結(jié)構(gòu)完美的解決了數(shù)組和鏈表的問題占遥，使得查詢和插入，刪除的效率都很高输瓜。
因為鏈表中元素太多的時候會影響查找效率瓦胎，所以當(dāng) 鏈表的元素個數(shù)達(dá)到8 的時候使用鏈表存儲就轉(zhuǎn)變成了使用紅黑樹存儲芬萍，原因就是紅黑樹是平衡二叉樹，在查找性能方面比鏈表要高搔啊。
3柬祠、HashMap中有兩個重要的參數(shù)：初始容量大小和加載因子，初始容量大小是創(chuàng)建時給數(shù)組分配的容量大小负芋，默認(rèn)值為16漫蛔，用數(shù)組容量大小乘以加載因子得到一個值。
一旦數(shù)組中存儲的元素個數(shù)超過該值就會調(diào)用rehash方法將數(shù)組容量增加到原來的兩倍旧蛾，專業(yè)術(shù)語叫做擴(kuò)容莽龟。
在做擴(kuò)容的時候會生成一個新的數(shù)組，原來的所有數(shù)據(jù)需要重新計算哈希碼值重新分配到新的數(shù)組锨天，所以擴(kuò)容的操作非常消耗性能毯盈。

二、問題：

當(dāng)重新調(diào)整HashMap大小的時候病袄，存在條件競爭搂赋，如果兩個線程都發(fā)現(xiàn)HashMap需要重新調(diào)整大小了，它們會同時試著調(diào)整大小陪拘。
在調(diào)整大小的過程中厂镇，存儲在LinkedList中的元素的次序會反過來，因為移動到新的bucket位置的時候左刽，HashMap并不會將元素放在LinkedList的尾部捺信，而是放在頭部，這是為了避免尾部遍歷(tail traversing)欠痴。
如果條件競爭發(fā)生了迄靠，那么就死循環(huán)了。

三喇辽、避免：

1.java8的改進(jìn)
添加了紅黑樹掌挚，當(dāng)鏈表長度大于8時，還需要判斷當(dāng)前數(shù)組的長度,如果數(shù)組長度 < 64 時菩咨，此時并不會轉(zhuǎn)換為紅黑樹吠式，而是擴(kuò)容, 只有當(dāng)鏈表中的元素個數(shù) > 8，并且數(shù)組的長度 >= 64 時才會將鏈表轉(zhuǎn)為紅黑樹抽米。
擴(kuò)容后特占，新數(shù)組中的鏈表順序依然與舊數(shù)組中的鏈表順序保持一致。
具體JDK8是用 head 和 tail 來保證鏈表的順序和之前一樣云茸，這樣就不會產(chǎn)生循環(huán)引用是目，也就沒有死循環(huán)了。
雖然修復(fù)了死循環(huán)的BUG标捺，但是HashMap 還是非線程安全類懊纳，仍然會產(chǎn)生數(shù)據(jù)丟失等問題揉抵。
2.可以使用HashTable和調(diào)用Collections工具類的synchronizedMap()方法達(dá)到線程安全的目的。
但由于synchronized是串行執(zhí)行嗤疯，在訪問量很大的情況下效率很低冤今，不推薦使用。

三身弊、通常一個Xml映射文件辟汰，都會寫一個Dao接口與之對應(yīng)列敲，請問阱佛，這個Dao接口的工作原理是什么？Dao接口里的方法戴而，參數(shù)不同時凑术，方法能重載嗎？

1.簡述：

Dao接口所意，就是人們常說的Mapper接口;
接口的全限名淮逊，就是映射文件中的namespace的值;
接口的方法名，就是映射文件中MappedStatement的id值;
接口方法內(nèi)的參數(shù)扶踊，就是傳遞給sql的參數(shù)泄鹏；
Mapper接口是沒有實現(xiàn)類的，當(dāng)調(diào)用接口方法時秧耗，接口全限名+方法名拼接字符串作為key值备籽，可唯一定位一個MappedStatement。

2.舉例：

com.mybatis3.mappers.StudentDao.findStudentById分井，可以唯一找到namespace為com.mybatis3.mappers.StudentDao下面id = findStudentById的MappedStatement车猬。

3.工作原理：

在Mybatis中，每一個<select>尺锚、<insert>珠闰、<update>、<delete>標(biāo)簽瘫辩，都會被解析為一個MappedStatement對象伏嗜。
Dao接口里的方法，是不能重載的伐厌，因為是全限名+方法名的保存和尋找策略承绸。
Dao接口的工作原理是JDK動態(tài)代理，Mybatis運行時會使用JDK動態(tài)代理為Dao接口生成代理proxy對象（如使用spring會注入到容器中）弧械，代理對象proxy會攔截接口方法八酒，轉(zhuǎn)而執(zhí)行MappedStatement所代表的sql，然后將sql執(zhí)行結(jié)果返回刃唐。

四羞迷、JVM中類加載的過程? 什么是雙親委派界轩？類加載器有哪些?

1.在加載階段，虛擬機(jī)需要完成以下三件事情：

1.通過一個類的全限定名來獲取定義此類的二進(jìn)制字節(jié)流(并沒有指明要從一個Class文件中獲取衔瓮，可以從其他渠道浊猾，如：網(wǎng)絡(luò)、動態(tài)生成热鞍、數(shù)據(jù)庫等)葫慎；
2.將這個字節(jié)流所代表的的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運行時數(shù)據(jù)結(jié)構(gòu)；
3.在內(nèi)存中(對于HotSpot虛擬機(jī)而言就是方法區(qū))生成一個代表這個類的java.lang.Class對象薇宠，作為方法區(qū)這個類的各種數(shù)據(jù)訪問入口偷办；

2.雙親委派:

類加載器收到類加載請求，自己不加載澄港，向上委托給父類加載椒涯，父類加載不了，再自己加載, 就是避免Java核心API篡改回梧。

3.類加載器有哪些:

1.Bootstrap ClassLoader(啟動類 | 根加載器):它用來加載 Java 的核心類废岂，是用原生代碼來實現(xiàn)的，并不繼承自 java.lang.ClassLoader（負(fù)責(zé)加載$JAVA_HOME中jre/lib/rt.jar里所有的class狱意，由C++實現(xiàn)湖苞，不是ClassLoader子類）。
由于引導(dǎo)類加載器涉及到虛擬機(jī)本地實現(xiàn)細(xì)節(jié)详囤，開發(fā)者無法直接獲取到啟動類加載器的引用财骨，所以不允許直接通過引用進(jìn)行操作。
2.ExtClassLoader(擴(kuò)展類加載器)：它負(fù)責(zé)加載JRE的擴(kuò)展目錄纬纪，lib/ext或者由java.ext.dirs系統(tǒng)屬性指定的目錄中的JAR包的類蚓再。由Java語言實現(xiàn)，開發(fā)者可以直接使用擴(kuò)展類加載器包各。
3.AppClassLoader:被稱為系統(tǒng)(應(yīng)用)類加載器:它負(fù)責(zé)在JVM啟動時加載來自Java命令的-classpath選項摘仅、java.class.path系統(tǒng)屬性，或者CLASSPATH換將變量所指定的JAR包和類路徑问畅。
程序可以通過ClassLoader的靜態(tài)方法getSystemClassLoader()來獲取系統(tǒng)類加載器娃属。如果沒有特別指定，則用戶自定義的類加載器都以此類加載器作為父加載器护姆。由Java語言實現(xiàn)矾端，父類加載器為ExtClassLoader。

類加載器結(jié)構(gòu).jpg

五卵皂、從以下幾個方面談?wù)剬ybatis的一級緩存

1. mybaits中如何維護(hù)一級緩存

BaseExecutor成員變量之一的PerpetualCache秩铆，是對Cache接口最基本的實現(xiàn)，其實現(xiàn)非常簡單，內(nèi)部持有HashMap殴玛，對一級緩存的操作實則是對HashMap的操作捅膘。

2. 一級緩存的生命周期

MyBatis一級緩存的生命周期和SqlSession一致；
MyBatis的一級緩存最大范圍是SqlSession內(nèi)部滚粟，有多個SqlSession或者分布式的環(huán)境下寻仗，數(shù)據(jù)庫寫操作會引起臟數(shù)據(jù); MyBatis一級緩存內(nèi)部設(shè)計簡單，只是一個沒有容量限定的HashMap凡壤，在緩存的功能性上有所欠缺署尤。

3. mybatis 一級緩存何時失效

a. MyBatis在開啟一個數(shù)據(jù)庫會話時，會創(chuàng)建一個新的SqlSession對象亚侠，SqlSession對象中會有一個新的Executor對象曹体，Executor對象中持有一個新的PerpetualCache對象；當(dāng)會話結(jié)束時盖奈，SqlSession對象及其內(nèi)部的Executor對象還有PerpetualCache對象也一并釋放掉混坞。
b. 如果SqlSession調(diào)用了close()方法，會釋放掉一級緩存PerpetualCache對象钢坦，一級緩存將不可用；
c. 如果SqlSession調(diào)用了clearCache()啥酱，會清空PerpetualCache對象中的數(shù)據(jù)爹凹，但是該對象仍可使用；
d. SqlSession中執(zhí)行了任何一個update操作update()镶殷、delete()禾酱、insert() ，都會清空PerpetualCache對象的數(shù)據(jù)

4 一級緩存的工作流程绘趋？

a. 對于某個查詢颤陶，根據(jù)statementId,params,rowBounds來構(gòu)建一個key值，根據(jù)這個key值去緩存Cache中取出對應(yīng)的key值存儲的緩存結(jié)果陷遮；
b. 判斷從Cache中根據(jù)特定的key值取的數(shù)據(jù)數(shù)據(jù)是否為空滓走，即是否命中；
c. 如果命中帽馋，則直接將緩存結(jié)果返回搅方；
d. 如果沒命中：去數(shù)據(jù)庫中查詢數(shù)據(jù)，得到查詢結(jié)果绽族；將key和查詢到的結(jié)果分別作為key,value對存儲到Cache中姨涡；將查詢結(jié)果返回.

六、Jvm中對象分配的規(guī)則

1.對象優(yōu)先分配在Eden區(qū)吧慢，如果Eden區(qū)沒有足夠的空間時涛漂，虛擬機(jī)執(zhí)行一次Minor GC。
2.大對象直接進(jìn)入老年代（大對象是指需要大量連續(xù)內(nèi)存空間的對象）检诗。這樣做的目的是避免在Eden區(qū)和兩個Survivor區(qū)之間發(fā)生大量的內(nèi)存拷貝（新生代采用復(fù)制算法收集內(nèi)存）匈仗。
3.長期存活的對象進(jìn)入老年代底哗。虛擬機(jī)為每個對象定義了一個年齡計數(shù)器，如果對象經(jīng)過了1次Minor GC那么對象會進(jìn)入Survivor區(qū)锚沸，之后每經(jīng)過一次Minor GC那么對象的年齡加1跋选，知道達(dá)到閥值對象進(jìn)入老年區(qū)。
4.動態(tài)判斷對象的年齡哗蜈。如果Survivor區(qū)中相同年齡的所有對象大小的總和大于Survivor空間的一半前标，年齡大于或等于該年齡的對象可以直接進(jìn)入老年代。
5.空間分配擔(dān)保距潘。每次進(jìn)行Minor GC時炼列，JVM會計算Survivor區(qū)移至老年區(qū)的對象的平均大小，如果這個值大于老年區(qū)的剩余值大小則進(jìn)行一次Full GC音比，如果小于檢查HandlePromotionFailure設(shè)置俭尖，如果true則只進(jìn)行Monitor GC,如果false則進(jìn)行Full GC。

七洞翩、 @Component和@Bean的區(qū)別是什么

1. @Component注解作用于類稽犁，而@Bean注解作用于方法。
1. @Component注解通常是通過類路徑掃描來自動偵測以及自動裝配到Spring容器中（我們可以使用@ComponentScan注解定義要掃描的路徑）骚亿。
  @Bean注解通常是在標(biāo)有該注解的方法中定義產(chǎn)生這個bean已亥，告訴Spring這是某個類的實例，當(dāng)我需要用它的時候還給我来屠。
1. @Bean注解比@Component注解的自定義性更強(qiáng)虑椎，而且很多地方只能通過@Bean注解來注冊bean。
  比如當(dāng)引用第三方庫的類需要裝配到Spring容器的時候俱笛，就只能通過@Bean注解來實現(xiàn)捆姜。

八、FileSystemResource和ClassPathResource之間的區(qū)別是什么迎膜？

在FileSystemResource中你需要給出spring-config.xml(Spring配置)文件相對于您的項目的相對路徑或文件的絕對位置泥技。
在ClassPathResource中Sping查找文件使用ClassPath，因此spring-config.xml應(yīng)該包含在類路徑下星虹。
一句話,ClassPathResource在類路徑下搜索和FileSystemResource在文件系統(tǒng)下搜索零抬。

九、構(gòu)造方法注入和setter注入之間的區(qū)別

1宽涌、在Setter注入,可以將依賴項部分注入,構(gòu)造方法注入不能部分注入平夜，因為調(diào)用構(gòu)造方法如果傳入所有的參數(shù)就會報錯。
2卸亮、如果我們?yōu)橥粚傩蕴峁㏒etter和構(gòu)造方法注入忽妒，Setter注入將覆蓋構(gòu)造方法注入。
但是構(gòu)造方法注入不能覆蓋setter注入值。顯然段直，構(gòu)造方法注入被稱為創(chuàng)建實例的第一選項吃溅。
3、使用setter注入你不能保證所有的依賴都被注入,這意味著你可以有一個對象依賴沒有被注入鸯檬。
在另一方面構(gòu)造方法注入直到你所有的依賴都注入后才開始創(chuàng)建實例决侈。
4、在構(gòu)造函數(shù)注入,如果A和B對象相互依賴：A依賴于B,B也依賴于A,此時在創(chuàng)建對象的A或者B時喧务，Spring拋出ObjectCurrentlyInCreationException赖歌。
所以Spring可以通過setter注入,從而解決循環(huán)依賴的問題。

十功茴、ApplicationContext通常的實現(xiàn)是什么

1庐冯、 FileSystemXmlApplicationContext ：此容器從一個XML文件中加載beans的定義，XML Bean 配置文件的全路徑名必須提供給它的構(gòu)造函數(shù)坎穿。
2展父、 ClassPathXmlApplicationContext：此容器也從一個XML文件中加載beans的定義，這里玲昧，你需要正確設(shè)置classpath因為這個容器將在classpath里找bean配置栖茉。
3、WebXmlApplicationContext：此容器加載一個XML文件酌呆，此文件定義了一個WEB應(yīng)用的所有bean衡载。

十一、描述Spring和SpringMVC父子容器關(guān)系, 父子容器重復(fù)掃描會出現(xiàn)什么樣的問題, 子容器是否可以使用父容器中的bean, 如果可以如何配置?

1隙袁、父子容器關(guān)系

Spring是父容器，SpringMVC是其子容器弃榨，
并且在Spring父容器中注冊的Bean對于SpringMVC容器中是可見的菩收，
而在SpringMVC容器中注冊的Bean對于Spring父容器中是不可見的，也就是子容器可以看見父容器中的注冊的Bean鲸睛，反之就不行娜饵。

父容器是使用了ContextLoaderListener加載并實例化的ioc容器為父容器。
子容器是使用了DispatcherServerlet加載并實例化的ioc容器為子容器官辈。
父容器不能調(diào)用子容器中任何的組件,子容器可以調(diào)用除了controller以外的組件箱舞。

2、問題

事務(wù)失效

3拳亿、子容器可以使用父容器的bean(默認(rèn)不能使用)

需要配置:

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

十二晴股、簡述什么是死鎖, 活鎖, 饑餓以及產(chǎn)生的原因？

1肺魁、死鎖:

指兩個或兩個以上的進(jìn)程(或線程)在執(zhí)行過程中, 因爭奪資源造成的一種相互等待的現(xiàn)象, 若無外力作用, 他們將無法推進(jìn)下去
產(chǎn)生死鎖的原因?

1.互斥條件: 所謂互斥就是進(jìn)程在某一時間內(nèi)獨占資源.
2.請求與保持條件: 一個進(jìn)程因請求資源而阻塞時, 對已獲得的資源保持不放
3.不剝奪條件: 進(jìn)程已獲得資源, 在未使用前, 不能強(qiáng)行剝奪.
4.循環(huán)等待條件: 若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系.

2电湘、活鎖:

任務(wù)或者執(zhí)行者沒有被阻塞, 由于某些條件沒有滿足, 導(dǎo)致一直重復(fù)嘗試, 失敗, 嘗試, 失敗，
活鎖和思索的區(qū)別在于, 處于活鎖的實體是在不斷的改變狀態(tài), 所謂的"活", 而處于死鎖的實體表現(xiàn)為等待, 活鎖有可能自行解開, 死鎖則不能。

3寂呛、饑餓:

一個或多個線程因為種種原因無法獲得所需要的資源, 導(dǎo)致一直無法執(zhí)行的狀態(tài)怎诫。
java中導(dǎo)致饑餓的原因?

1.高優(yōu)先級線程吞噬所有的低優(yōu)先級線程cpu時間。
2.線程被永久堵塞在一個等待進(jìn)入同步塊的狀態(tài), 因為其他線程總是能在它之前持續(xù)的對該同步塊進(jìn)行訪問贷痪。
3.線程在等待一個本身也處于永久等待完成的對象(比如調(diào)用這個對象的wait方法), 因為其他線程總是被持續(xù)的獲得喚醒幻妓。

十三、SpringMVC中的攔截器和Servlet中的filter有什么區(qū)別?

首先最核心的一點他們的攔截側(cè)重點是不同的：

1劫拢、SpringMVC中的攔截器是依賴JDK的反射實現(xiàn)的：

SpringMVC的攔截器主要是進(jìn)行攔截請求肉津，通過對Handler進(jìn)行處理的時候進(jìn)行攔截，先聲明的攔截器中的preHandle方法會先執(zhí)行尚镰，然而它的postHandle方法（他是介于處理完業(yè)務(wù)之后和返回結(jié)果之前）和afterCompletion方法卻會后執(zhí)行阀圾。
并且Spring的攔截器是按照配置的先后順序進(jìn)行攔截的。

2 狗唉、 Servlet的filter是基于函數(shù)回調(diào)實現(xiàn)的過濾器：

Filter主要是針對URL地址做一個編碼的事情初烘、而過濾掉沒用的參數(shù)、安全校驗（比較泛的分俯，比如登錄不登錄之類）肾筐。

十四、講一下 oom 以及遇到這種情況怎么處理的缸剪，是否使用過日志分析工具 ?

1吗铐、OOM，全稱“OutOfMemory”杏节，翻譯成中文就是“內(nèi)存用完了”

當(dāng) JVM 因為沒有足夠的內(nèi)存來為對象分配空間并且垃圾回收器也已經(jīng)沒有空間可回收時唬渗，就會拋出這個 error。

2奋渔、處理過程：

首先通過內(nèi)存映射分析工具如：

EclipseMemoryAnalyzer堆dump出的異常堆轉(zhuǎn)儲進(jìn)行快照解析確認(rèn)內(nèi)存中的對象是否是必要的镊逝，也就是先分清楚是內(nèi)存泄漏 MemoryLeak 還是 MemoryOverflow 。
如果是內(nèi)存泄漏可通過工具進(jìn)一步查看泄露的對象到 GCRoots 的引用鏈嫉鲸，就能找到泄露對象是怎么通過路徑與 GCRoots 相關(guān)聯(lián)導(dǎo)致垃圾收集器無法回收撑蒜。
他們?nèi)绻淮嬖谛孤毒蜋z查堆參數(shù) -Xmx 與 -Xms與機(jī)器物理內(nèi)存對比是否還可以調(diào)大；
從代碼上檢測是否是某些對象的生命周期過長持有狀態(tài)時間過長嘗試減少代碼運行期間的內(nèi)存消耗玄渗。

十五座菠、Spring Boot 中 “約定優(yōu)于配置“的具體產(chǎn)品體現(xiàn)在哪里 ?

Spring Boot Starter、Spring Boot Jpa 都是“約定優(yōu)于配置“的一種體現(xiàn)藤树。都是通過“約定優(yōu)于配置“的設(shè)計思路來設(shè)計的浴滴；
Spring Boot Starter 在啟動的過程中會根據(jù)約定的信息對資源進(jìn)行初始化；
Spring Boot Jpa 通過約定的方式來自動生成 Sql 也榄，避免大量無效代碼編寫巡莹。

十六司志、Spring Boot 中如何實現(xiàn)定時任務(wù) ?

定時任務(wù)也是一個常見的需求，Spring Boot 中對于定時任務(wù)的支持主要還是來自 Spring 框架降宅。
在 Spring Boot 中使用定時任務(wù)主要有兩種不同的方式骂远，一個就是使用 Spring 中的 @Scheduled 注解，另一個則是使用第三方框架 Quartz腰根。
使用 Spring 中的 @Scheduled 的方式主要通過 @Scheduled 注解來實現(xiàn)激才。
使用 Quartz ，則按照 Quartz 的方式额嘿，定義 Job 和 Trigger 即可瘸恼。

十七、wait 和 sleep 的區(qū)別

1册养、sleep 來自 Thread 類东帅，和 wait 來自 Object 類。
2球拦、主要是sleep方法沒有釋放鎖靠闭，而wait方法釋放了鎖，使得其他線程可以使用同步控制塊或者方法坎炼。
3愧膀、wait，notify和 notifyAll 只能在同步控制方法或者同步控制塊里面使用谣光，而 sleep 可以在任何地方使用(使用范圍)檩淋。
4、sleep 必須捕獲異常萄金，而 wait 蟀悦，notify 和 notifyAll 不需要捕獲異常。

(1) sleep 方法屬于 Thread 類中方法氧敢，表示讓一個線程進(jìn)入睡眠狀態(tài)熬芜，等待一定的時間之后，自動醒來進(jìn)入到可運行狀態(tài)福稳，不會馬上進(jìn)入運行狀態(tài)，因為線程調(diào)度機(jī)制恢復(fù)線程的運行也需要時間瑞侮，一個線程對象調(diào)用了 sleep 方法之后的圆，并不會釋放他所持有的所有對象鎖，所以也就不會影響其他進(jìn)程對象的運行半火。
但在 sleep 的過程中過程中有可能被其他對象調(diào)用它的 interrupt() ,產(chǎn)生 InterruptedException 異常越妈，如果你的程序不捕獲這個異常，線程就會異常終止钮糖，進(jìn)入 TERMINATED 狀態(tài)梅掠，如果你的程序捕獲了這個異常酌住，那么程序就會繼續(xù)執(zhí)行catch語句塊(可能還有 finally 語句塊)以及以后的代碼。
注意 sleep() 方法是一個靜態(tài)方法阎抒，也就是說他只對當(dāng)前對象有效酪我，通過 t.sleep() 讓t對象進(jìn)入 sleep ，這樣的做法是錯誤的且叁，它只會是使當(dāng)前線程被 sleep 而不是 t 線程都哭。

(2) wait 屬于 Object 的成員方法，一旦一個對象調(diào)用了wait方法逞带，必須要采用 notify() 和 notifyAll() 方法喚醒該進(jìn)程;如果線程擁有某個或某些對象的同步鎖欺矫，那么在調(diào)用了 wait() 后，這個線程就會釋放它持有的所有同步資源展氓，而不限于這個被調(diào)用了 wait() 方法的對象穆趴。 wait() 方法也同樣會在 wait 的過程中有可能被其他對象調(diào)用 interrupt() 方法而產(chǎn)生。

十八遇汞、spring-boot-starter-parent 有什么用 ?

1未妹、定義了 Java 編譯版本。
2勺疼、使用 UTF-8 格式編碼教寂。
3、繼承自 spring-boot-dependencies执庐，這個里邊定義了依賴的版本酪耕，也正是因為繼承了這個依賴，所以我們在寫依賴時才不需要寫版本號轨淌。
4迂烁、執(zhí)行打包操作的配置。
5递鹉、自動化的資源過濾盟步。
6、自動化的插件配置躏结。
7却盘、針對 application.properties 和 application.yml 的資源過濾，包括通過 profile 定義的不同環(huán)境的配置文件媳拴，例如 application-dev.properties 和 application-dev.yml黄橘。

十九、Spring Boot 是否可以使用 XML 配置 ?

Spring Boot 推薦使用 Java 配置而非 XML 配置屈溉，但是 Spring Boot 中也可以使用 XML 配置塞关，通過 @ImportResource 注解可以引入一個 XML 配置。

二十子巾、Spring Boot 打成的 jar 和普通的 jar 有什么區(qū)別 ?

Spring Boot 項目最終打包成的 jar 是可執(zhí)行 jar 帆赢，這種 jar 可以直接通過java -jar xxx.jar命令來運行小压，這種 jar不可以作為普通的 jar 被其他項目依賴，即使依賴了也無法使用其中的類椰于。
Spring Boot 的 jar 無法被其他項目依賴怠益，主要還是他和普通 jar 的結(jié)構(gòu)不同。
普通的 jar 包廉羔，解壓后直接就是包名溉痢，包里就是我們的代碼，而 Spring Boot 打包成的可執(zhí)行 jar 解壓后，在 \BOOT-INF\classes 目錄下才是我們的代碼，因此無法被直接引用萝衩。
如果非要引用，可以在 pom.xml 文件中增加配置镀娶，將 Spring Boot 項目打包成兩個 jar ，一個可執(zhí)行揪罕，一個可引用梯码。

二十一、nginx是如何實現(xiàn)高并發(fā)的好啰？

一個主進(jìn)程轩娶，多個工作進(jìn)程，每個工作進(jìn)程可以處理多個請求框往，每進(jìn)來一個request鳄抒，會有一個worker進(jìn)程去處理。
但不是全程的處理椰弊，處理到可能發(fā)生阻塞的地方许溅，比如向上游（后端）服務(wù)器轉(zhuǎn)發(fā)request，并等待請求返回秉版。
那么贤重，這個處理的worker繼續(xù)處理其他請求，而一旦上游服務(wù)器返回了清焕，就會觸發(fā)這個事件并蝗，worker才會來接手，這個request才會接著往下走秸妥。
由于web server的工作性質(zhì)決定了每個request的大部份生命都是在網(wǎng)絡(luò)傳輸中借卧，實際上花費在server機(jī)器上的時間片不多。
這是幾個進(jìn)程就解決高并發(fā)的秘密所在筛峭。
即webserver剛好屬于網(wǎng)絡(luò)io密集型應(yīng)用，不算是計算密集型陪每。

二十二影晓、Tomcat Servlet容器處理流程：

當(dāng)?戶請求某個URL資源時

1）HTTP服務(wù)器會把請求信息使?ServletRequest對象封裝起來
2）進(jìn)?步去調(diào)?Servlet容器中某個具體的Servlet
3）在 2）中镰吵，Servlet容器拿到請求后，根據(jù)URL和Servlet的映射關(guān)系挂签，找到相應(yīng)的Servlet
4）如果Servlet還沒有被加載疤祭，就?反射機(jī)制創(chuàng)建這個Servlet，并調(diào)?Servlet的init?法來完成初始化
5）接著調(diào)?這個具體Servlet的service?法來處理請求饵婆，請求處理結(jié)果使?ServletResponse對象封裝
6）把ServletResponse對象返回給HTTP服務(wù)器勺馆，HTTP服務(wù)器會把響應(yīng)發(fā)送給客戶端