請介紹一下Spring和AOP和IOC?

　　答:AOP面向方面編程基于IoC，是對OOP的補充。AOP利用一種稱為“橫切”的技術(shù)，剖解開封裝的對象內(nèi)部，并將那些影響了多個類的公共行為封裝到一個可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡單地說，就是將那些與業(yè)務(wù)無關(guān)，卻為業(yè)務(wù)模塊所共同調(diào)用的邏輯或責任封裝起來，比如日志記錄，便于減少系統(tǒng)的重復(fù)代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護性。

　　實現(xiàn)AOP的技術(shù)，主要分為兩大類：一是采用動態(tài)代理技術(shù)，利用截取消息的方式，對該消息進行裝飾，以取代原有對象行為的執(zhí)行；二是采用靜態(tài)織入的方式，引入特定的語法創(chuàng)建“方面”，從而使得編譯器可以在編譯期間織入有關(guān)“方面”的代碼。

　　Spring實現(xiàn)AOP：JDK動態(tài)代理和CGLIB代理JDK動態(tài)代理：其代理對象必須是某個接口的實現(xiàn)，它是通過在運行期間創(chuàng)建一個接口的實現(xiàn)類來完成對目標對象的代理；其核心的兩個類是InvocationHandler和Proxy。CGLIB代理：實現(xiàn)原理類似于JDK動態(tài)代理，只是它在運行期間生成的代理對象是針對目標類擴展的子類。CGLIB是高效的代碼生成包，底層是依靠ASM（開源的java字節(jié)碼編輯類庫）操作字節(jié)碼實現(xiàn)的，性能比JDK強；需要引入包asm.jar和cglib.jar。使用AspectJ注入式切面和@AspectJ注解驅(qū)動的切面實際上底層也是通過動態(tài)代理實現(xiàn)的。

　　IoC（InversionofControl）是指容器控制程序?qū)ο笾g的關(guān)系，而不是傳統(tǒng)實現(xiàn)中，由程序代碼直接操控。控制權(quán)由應(yīng)用代碼中轉(zhuǎn)到了外部容器，控制權(quán)的轉(zhuǎn)移是所謂反轉(zhuǎn)。對于Spring而言，就是由Spring來控制對象的生命周期和對象之間的關(guān)系；IoC還有另外一個名字——“依賴注入（DependencyInjection）”。

　　依賴注入的思想是通過反射機制實現(xiàn)的，在實例化一個類時，它通過反射調(diào)用類中set方法將事先保存在HashMap中的類屬性注入到類中。總而言之，在傳統(tǒng)的對象創(chuàng)建方式中，通常由調(diào)用者來創(chuàng)建被調(diào)用者的實例，而在Spring中創(chuàng)建被調(diào)用者的工作由Spring來完成，然后注入調(diào)用者，即所謂的依賴注入or控制反轉(zhuǎn)。

　　MyBatis中的#和$的區(qū)別

　　答:#將傳入的數(shù)據(jù)都當成一個字符串，會對自動傳入的數(shù)據(jù)加一個雙引號。$將傳入的數(shù)據(jù)直接顯示生成在sql中。#方式能夠很大程度防止sql注入。$方式無法防止Sql注入。$方式一般用于傳入數(shù)據(jù)庫對象，例如傳入表名。一般能用#的就別用$。

　　問:wait()notify()notifyAll()的區(qū)別

　　答:wait()方法將線程加入一個FIFO集合，notify()將等待中的線程隨機喚醒，notifyAll()將等待中的所有線程。

　　BIO和NIO的區(qū)別

　　答:JavaNIO和IO之間的第一個重要區(qū)別是IO是面向流的，其中NIO是面向緩沖區(qū)的。

　　面向流的JavaIO意味著您可以從流中一次讀取一個或多個字節(jié)。你對讀取的字節(jié)做什么取決于你。JavaNIO的面向緩沖區(qū)的方法略有不同。數(shù)據(jù)被讀入緩沖區(qū)，稍后處理該緩沖區(qū)。JavaIO的各種流都是blocking的。這意味著，當線程調(diào)用read（）或write（）時，該線程將被阻塞，直到有一些數(shù)據(jù)要讀取，或者數(shù)據(jù)被完全寫入，在此期間，該線程無法執(zhí)行任何其他操作。JavaNIO的非阻塞模式允許線程請求從通道讀取數(shù)據(jù)，并且只獲取當前可用的內(nèi)容，或者根本沒有數(shù)據(jù)，如果當前沒有數(shù)據(jù)可用。線程可以繼續(xù)使用其他內(nèi)容，而不是在數(shù)據(jù)可供讀取之前保持阻塞狀態(tài)。

　　樂觀鎖和悲觀鎖的區(qū)別

　　答:悲觀鎖(PessimisticLock),顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時候都認為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖，這樣別人想拿這個數(shù)據(jù)就會block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。

　　樂觀鎖(OptimisticLock),顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)，可以使用版本號等機制。樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量，像數(shù)據(jù)庫如果提供類似于write_condition機制的其實都是提供的樂觀鎖。

　　兩種鎖各有優(yōu)缺點，不可認為一種好于另一種，像樂觀鎖適用于寫比較少的情況下，即沖突真的很少發(fā)生的時候，這樣可以省去了鎖的開銷，加大了系統(tǒng)的整個吞吐量。但如果經(jīng)常產(chǎn)生沖突，上層應(yīng)用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。

　　MyISAM和Innodb的區(qū)別

　　答:MyISAM不支持外鍵，Innodb支持，MyISAM不支持事務(wù)。對數(shù)據(jù)信息的存儲處理方式不同，如果存儲引擎是MyISAM的，則創(chuàng)建一張表對應(yīng)三個文件，如果是Innodb則只有一個文件。對于MyISAM數(shù)據(jù)庫，需要定時清理，

　　SpringBoot有哪幾種讀取配置的方式？

　　答:SpringBoot可以通過@PropertySource,@Value,@Environment,@ConfigurationProperties來綁定變量。

　　TCP三次握手和四次揮手

　　答:第一次握手：Client將標志位SYN置為1，隨機產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進入SYN_SENT狀態(tài)，等待Server確認。

　　第二次握手：Server收到數(shù)據(jù)包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認連接請求，Server進入SYN_RCVD狀態(tài)。

　　第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。

　　第一次揮手：Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進入FIN_WAIT_1狀態(tài)。

　　第二次揮手：Server收到FIN后，發(fā)送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態(tài)。

　　第三次揮手：Server發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進入LAST_ACK狀態(tài)。

　　第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態(tài)，完成四次揮手。

　　JAVA的異常處理機制

　　答：JAVA的異常處理機制：如果某個方法不能按照正常的途徑完成任務(wù)，就可以通過另一種路徑退出方法。在這種情況下會拋出一個封裝了錯誤信息的對象。此時，這個方法會立刻退出同時不返回任何值。另外，調(diào)用這個方法的其他代碼也無法繼續(xù)執(zhí)行，異常處理機制會將代碼執(zhí)行交給異常處理器。

      以上就是動力節(jié)點Java培訓(xùn)機構(gòu)小編介紹的“常見Java中高級面試題大全整理”的內(nèi)容，希望對大家有幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務(wù)。