在積極備戰大廠的同時,我們也要關注大廠的一些實際面試情況和難易程度,感受一下大廠的氛圍,系列文章持續更新,有好的面試題的伙伴們也可以私信博主,我們共同努力!當然了,文章中有什么不合適的地方也請大家指正!

目錄
BeanFactory 和 ApplicationContext 有什么區別
Spring Bean 的生命周期
Spring IOC 如何實作
說說 Spring AOP
Spring AOP 實作原理
動態代理( cglib 與 JDK)
Spring 事務實作方式
Spring 事務底層原理
如何自定義注解實作功能
Spring MVC 運行流程和啟動流程
Spring 的單例實作原理
Spring 框架中用到了哪些設計模式
為什么選擇 Netty
說說業務中, Netty 的使用場景
原生的 NIO 在 JDK 1.7 版本存在 epoll bug
TCP 粘包/拆包的解決辦法
Netty 執行緒模型
說說 Netty 的零拷貝
Netty 內部執行流程
【系列文章】

BeanFactory 和 ApplicationContext 有什么區別
-
BeanFactory 可以理解為含有 bean 集合的工廠類, BeanFactory 包含了種 bean 的定義,以便在接收到客戶端請求時將對應的 bean 實體化,
-
BeanFactory 還能在實體化物件的時生成協作類之間的關系,此舉將 bean 自身與 bean 客戶端的配置中解放出來, BeanFactory 還包含了 bean 生命周期的控制,呼叫客戶端的初始化方法( initialization methods)和銷毀方法( destruction methods),
-
從表面上看, application context 如同 bean factory 一樣具有 bean 定義、 bean 關聯關系的設定,根據請求分發 bean 的功能,但 application context 在此基礎上還提供了其他的功能,
-
提供了支持國際化的文本訊息
-
統一的資源檔案讀取方式
-
已在監聽器中注冊的 bean 的事件
Spring Bean 的生命周期
-
Spring Bean 的生命周期簡單易懂,在一個 bean 實體被初始化時,需要執行一系列的初始化操作以達到可用的狀態,同樣的,當一個 bean 不在被呼叫時需要進行相關的析構操作,并從 bean 容器中移除,
-
Spring bean factory 負責管理在 spring 容器中被創建的 bean 的生命周期, Bean 的生命周期由兩組回呼( call back)方法組成,
-
初始化之后呼叫的回呼方法,
-
銷毀之前呼叫的回呼方法,
-
-
Spring 框架提供了以下四種方式來管理 bean 的生命周期事件:
-
InitializingBean 和 DisposableBean 回呼介面
-
針對特殊行為的其他 Aware 介面
-
Bean 組態檔中的 Custom init()方法和 destroy()方法
-
@PostConstruct 和@PreDestroy 注解方式
Spring IOC 如何實作
-
Spring 中的 org.springframework.beans 包和 org.springframework.context 包構成了Spring 框架 IoC 容器的基礎,
-
BeanFactory 介面提供了一個先進的配置機制,使得任何型別的物件的配置成為可能,ApplicationContex 介面對 BeanFactory(是一個子介面)進行了擴展,在 BeanFactory 的基礎上添加了其他功能,比如與 Spring 的 AOP 更容易集成,也提供了處理 messageresource 的機制(用于國際化)、事件傳播以及應用層的特別配置,比如針對 Web 應用的WebApplicationContext,
-
org.springframework.beans.factory.BeanFactory 是 Spring IoC 容器的具體實作,用來包裝和管理前面提到的各種 bean, BeanFactory 介面是 Spring IoC 容器的核心介面,
說說 Spring AOP
面向切面編程,在我們的應用中,經常需要做一些事情,但是這些事情與核心業務無關,比如,要記錄所有 update方法的執行時間時間,操作人等等資訊,記錄到日志,
通過 spring 的 AOP 技術,就可以在不修改 update*的代碼的情況下完成該需求,
Spring AOP 實作原理
-
Spring AOP 中的動態代理主要有兩種方式, JDK 動態代理和 CGLIB 動態代理, JDK 動態代理通過反射來接收被代理的類,并且要求被代理的類必須實作一個介面, JDK 動態代理的核心是 InvocationHandler 介面和 Proxy 類,
-
如果目標類沒有實作介面,那么 Spring AOP 會選擇使用 CGLIB 來動態代理目標類, CGLIB( Code Generation Library),是一個代碼生成的類別庫,可以在運行時動態的生成某個類的子類,注意, CGLIB 是通過繼承的方式做的動態代理,因此如果某個類被標記為 final,那么它是無法使用 CGLIB 做動態代理的,
動態代理( cglib 與 JDK)
JDK 動態代理類和委托類需要都實作同一個介面,也就是說只有實作了某個介面的類可以使用 Java 動態代理機制,但是,事實上使用中并不是遇到的所有類都會給你實作一個接
口,因此,對于沒有實作介面的類,就不能使用該機制,而 CGLIB 則可以實作對類的動態代理,
Spring 事務實作方式
1、編碼方式
所謂編程式事務指的是通過編碼方式實作事務,即類似于 JDBC 編程實作事務管理,
2、宣告式事務管理方式
宣告式事務管理又有兩種實作方式:基于 xml 組態檔的方式;另一個實在業務方法上進行@Transaction 注解,將事務規則應用到業務邏輯中
Spring 事務底層原理
1、劃分處理單元——IOC
由于 spring 解決的問題是對單個資料庫進行區域事務處理的,具體的實作首相用 spring中的 IOC 劃分了事務處理單元,并且將對事務的各種配置放到了 ioc 容器中(設定事務管理器,設定事務的傳播特性及隔離機制),
2、AOP 攔截需要進行事務處理的類
Spring 事務處理模塊是通過 AOP 功能來實作宣告式事務處理的,具體操作(比如事務實行的配置和讀取,事務物件的抽象),用 TransactionProxyFactoryBean 介面來使用 AOP功能,生成 proxy 代理物件,通過 TransactionInterceptor 完成對代理方法的攔截,將事務處理的功能編織到攔截的方法中,讀取 ioc 容器事務配置屬性,轉化為 spring 事務處理需要的內部資料結構( TransactionAttributeSourceAdvisor),轉化為TransactionAttribute 表示的資料物件,
3、對事物處理實作(事務的生成、提交、回滾、掛起)
spring 委托給具體的事務處理器實作,實作了一個抽象和適配,適配的具體事務處理器: DataSource 資料源支持、 hibernate 資料源事務處理支持、 JDO 資料源事務處理支
持, JPA、 JTA 資料源事務處理支持,這些支持都是通過設計PlatformTransactionManager、 AbstractPlatforTransaction 一系列事務處理的支持, 為常用資料源支持提供了一系列的 TransactionManager,
4、結合
PlatformTransactionManager 實作了 TransactionInterception 介面,讓其與TransactionProxyFactoryBean 結合起來,形成一個 Spring 宣告式事務處理的設計體系,
如何自定義注解實作功能
-
創建自定義注解和創建一個介面相似,但是注解的 interface 關鍵字需要以@符號開頭,
-
注解方法不能帶有引數;
-
注解方法回傳值型別限定為:基本型別、 String、 Enums、 Annotation 或者是這些型別的陣列;
-
注解方法可以有默認值;
-
注解本身能夠包含元注解,元注解被用來注解其它注解,
Spring MVC 運行流程和啟動流程
運行流程
1.spring mvc 將所有的請求都提交給 DispatcherServlet,它會委托應用系統的其他模塊負責對請求 進行真正的處理作業,
2.DispatcherServlet 查詢一個或多個 HandlerMapping,找到處理請求的 Controller.
3.DispatcherServlet 請請求提交到目標 Controller
4.Controller 進行業務邏輯處理后,會回傳一個 ModelAndView
5.Dispathcher 查詢一個或多個 ViewResolver 視圖決議器,找到 ModelAndView 物件指定的視圖物件
6.視圖物件負責渲染回傳給客戶端,
啟動流程
在 web.xml 檔案中給 Spring MVC 的 Servlet 配置了 load-on-startup,所以程式啟動的 時候會初始化 Spring MVC,在 HttpServletBean 中將配置的 contextConfigLocation
屬性設定到 Servlet 中,然后在 FrameworkServlet 中創建了 WebApplicationContext, DispatcherServlet 根據 contextConfigLocation 配置的 classpath 下的 xml 檔案初始化了 Spring MVC 總的組件,
Spring 的單例實作原理
Spring 對 Bean 實體的創建是采用單例注冊表的方式進行實作的,而這個注冊表的快取是ConcurrentHashMap 物件,
Spring 框架中用到了哪些設計模式
-
代理模式—在 AOP 和 remoting 中被用的比較多,
-
單例模式—在 spring 組態檔中定義的 bean 默認為單例模式,
-
模板方法—用來解決代碼重復的問題,比如. RestTemplate, JmsTemplate,JpaTemplate,
-
前端控制器—Spring 提供了 DispatcherServlet 來對請求進行分發,
-
視圖幫助(View Helper )—Spring 提供了一系列的 JSP 標簽,高效宏來輔助將分散的代碼整合在視圖里,
-
依賴注入—貫穿于 BeanFactory / ApplicationContext 介面的核心理念,
-
工廠模式—BeanFactory 用來創建物件的實體,
Netty
為什么選擇 Netty
1) API 使用簡單,開發門檻低;
2) 功能強大,預置了多種編解碼功能,支持多種主流協議;
3) 定制能力強,可以通過 ChannelHandler 對通信框架進行靈活的擴展;
4) 性能高,通過與其它業界主流的 NIO 框架對比, Netty 的綜合性能最優;
5) 成熟、穩定, Netty 修復了已經發現的所有 JDK NIO BUG,業務開發人員不需要再為NIO 的 BUG 而煩惱;
6) 社區活躍,版本迭代周期短,發現的 BUG 可以被及時修復,同時,更多的新功能會被加入;
7) 經歷了大規模的商業應用考驗,質量已經得到驗證,在互聯網、大資料、網路游戲、企業應用、電信軟體等眾多行業得到成功商用,證明了它可以完全滿足不同行業的商業應用,
正是因為這些優點, Netty 逐漸成為 Java NIO 編程的首選框架,
說說業務中, Netty 的使用場景
-
構建高性能、低時延的各種 Java 中間件,例如 MQ、分布式服務框架、 ESB 訊息總線等,Netty 主要作為基礎通信框架提供高性能、低時延的通信服務;
-
公有或者私有協議堆疊的基礎通信框架,例如可以基于 Netty 構建異步、高性能的WebSocket 協議堆疊;
-
各領域應用,例如大資料、游戲等, Netty 作為高性能的通信框架用于內部各模塊的資料分發、傳輸和匯總等,實作模塊之間高性能通信,
原生的 NIO 在 JDK 1.7 版本存在 epoll bug
它會導致 Selector 空輪詢,最終導致 CPU 100%,官方聲稱在 JDK 1.6 版本的 update18 修復了該問題,但是直到 JDK 1.7 版本該問題仍舊存在,只不過該 BUG 發生概率降低了一些而已,它并沒有得到根本性解決,
什么是 TCP 粘包/拆包
1、要發送的資料大于 TCP 發送緩沖區剩余空間大小,將會發生拆包,
2、待發送資料大于 MSS(最大報文長度), TCP 在傳輸前將進行拆包,
3、要發送的資料小于 TCP 發送緩沖區的大小, TCP 將多次寫入緩沖區的資料一次發送出去,將會發生粘包,
4、接收資料端的應用層沒有及時讀取接識訓沖區中的資料,將發生粘包,
TCP 粘包/拆包的解決辦法
1、發送端給每個資料包添加包首部,首部中應該至少包含資料包的長度,這樣接收端在接收到資料后,通過讀取包首部的長度欄位,便知道每一個資料包的實際長度了,
2、發送端將每個資料包封裝為固定長度(不夠的可以通過補 0 填充),這樣接收端每次從接識訓沖區中讀取固定長度的資料就自然而然的把每個資料包拆分開來,
3、可以在資料包之間設定邊界,如添加特殊符號,這樣,接收端通過這個邊界就可以將不同的資料包拆分開,
Netty 執行緒模型
首先, Netty 使用 EventLoop 來處理連接上的讀寫事件,而一個連接上的所有請求都保證在一個 EventLoop 中被處理,一個 EventLoop 中只有一個 Thread,所以也就實作了一個連接上的所有事件只會在一個執行緒中被執行,一個 EventLoopGroup 包含多個 EventLoop,可以把一個 EventLoop 當做是 Reactor 執行緒模型中的一個執行緒,而一個 EventLoopGroup 類似于一個 ExecutorService
說說 Netty 的零拷貝
“零拷貝”是指計算機操作的程序中, CPU 不需要為資料在記憶體之間的拷貝消耗資源,而它通常是指計算機在網路上發送檔案時,不需要將檔案內容拷貝到用戶空間( User
Space)而直接在內核空間( Kernel Space)中傳輸到網路的方式,
Netty 內部執行流程
1.、Netty 的接收和發送 ByteBuffer 采用 DIRECT BUFFERS,使用堆外直接記憶體進行Socket 讀寫,不需要進行位元組緩沖區的二次拷貝,如果使用傳統的堆記憶體( HEAP
BUFFERS)進行 Socket 讀寫, JVM 會將堆記憶體 Buffer 拷貝一份到直接記憶體中,然后才寫入Socket 中,相比于堆外直接記憶體,訊息在發送程序中多了一次緩沖區的記憶體拷貝,
2、Netty 提供了組合 Buffer 物件,可以聚合多個 ByteBuffer 物件,用戶可以像操作一個 Buffer 那樣方便的對組合 Buffer 進行操作,避免了傳統通過記憶體拷貝的方式將幾個小
Buffer 合并成一個大的 Buffer,
3、Netty 的檔案傳輸采用了 transferTo 方法,它可以直接將檔案緩沖區的資料發送到

【系列文章】
大廠的面試總是備受關注,有目標的學習才能達到最終的目標!系列文章持續更新,希望小伙伴們支持,指正評論!真正的大師總有一顆學徒的心,加油!
看不透的百度同學:北京-百度-Java中級
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/286272.html
標籤:java
