Java面試通關要點彙總集之框架篇參考答案

框架篇

Spring

  • 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的事件
摘抄自: http://www.importnew.com/1585...
  • 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註解方式
摘抄自: http://www.importnew.com/1585...
  • Spring IOC 如何實現
Spring中的 org.springframework.beans 包和 org.springframework.context包構成了Spring框架IoC容器的基礎。
BeanFactory 接口提供了一個先進的配置機制,使得任何類型的對象的配置成爲可能。ApplicationContex接口對BeanFactory(是一個子接口)進行了擴展,在BeanFactory的基礎上添加了其餘功能,好比與Spring的AOP更容易集成,也提供了處理message resource的機制(用於國際化)、事件傳播以及應用層的特別配置,好比針對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則能夠實現對類的動態代理。
摘抄自: http://www.importnew.com/2201...
  • Spring 事務實現方式
一、編碼方式
所謂編程式事務指的是經過編碼方式實現事務,即相似於JDBC編程實現事務管理。
二、聲明式事務管理方式
聲明式事務管理又有兩種實現方式:基於xml配置文件的方式;另外一個實在業務方法上進行@Transaction註解,將事務規則應用到業務邏輯中
  • Spring 事務底層原理
a、劃分處理單元——IOC
因爲spring解決的問題是對單個數據庫進行局部事務處理的,具體的實現首相用spring中的IOC劃分了事務處理單元。而且將對事務的各類配置放到了ioc容器中(設置事務管理器,設置事務的傳播特性及隔離機制)。
b、AOP攔截須要進行事務處理的類
Spring事務處理模塊是經過AOP功能來實現聲明式事務處理的,具體操做(好比事務實行的配置和讀取,事務對象的抽象),用TransactionProxyFactoryBean接口來使用AOP功能,生成proxy代理對象,經過TransactionInterceptor完成對代理方法的攔截,將事務處理的功能編織到攔截的方法中。讀取ioc容器事務配置屬性,轉化爲spring事務處理須要的內部數據結構(TransactionAttributeSourceAdvisor),轉化爲TransactionAttribute表示的數據對象。
c、對事物處理實現(事務的生成、提交、回滾、掛起)
spring委託給具體的事務處理器實現。實現了一個抽象和適配。適配的具體事務處理器:DataSource數據源支持、hibernate數據源事務處理支持、JDO數據源事務處理支持,JPA、JTA數據源事務處理支持。這些支持都是經過設計PlatformTransactionManager、AbstractPlatforTransaction一系列事務處理的支持。 爲經常使用數據源支持提供了一系列的TransactionManager。
d、結合
PlatformTransactionManager實現了TransactionInterception接口,讓其與TransactionProxyFactoryBean結合起來,造成一個Spring聲明式事務處理的設計體系。
  • 如何自定義註解實現功能
建立自定義註解和建立一個接口類似,可是註解的interface關鍵字須要以@符號開頭。
註解方法不能帶有參數;
註解方法返回值類型限定爲:基本類型、String、Enums、Annotation或者是這些類型的數組;
註解方法能夠有默認值;
註解自己可以包含元註解,元註解被用來註解其它註解。
摘抄自: http://www.importnew.com/2028...
  • Spring MVC 運行流程
1.spring mvc將全部的請求都提交給DispatcherServlet,它會委託應用系統的其餘模塊負責對請求 進行真正的處理工做。
2.DispatcherServlet查詢一個或多個HandlerMapping,找處處理請求的Controller.
3.DispatcherServlet請請求提交到目標Controller
4.Controller進行業務邏輯處理後,會返回一個ModelAndView
5.Dispathcher查詢一個或多個ViewResolver視圖解析器,找到ModelAndView對象指定的視圖對象
6.視圖對象負責渲染返回給客戶端。
摘抄自: http://blog.csdn.net/liangzi_...
  • Spring MVC 啓動流程
在 web.xml 文件中給 Spring MVC 的 Servlet 配置了 load-on-startup,因此程序啓動的
時候會初始化 Spring MVC,在 HttpServletBean 中將配置的 contextConfigLocation
屬性設置到 Servlet 中,而後在 FrameworkServlet 中建立了 WebApplicationContext,
DispatcherServlet 根據 contextConfigLocation 配置的 classpath 下的 xml 文件初始化了
Spring MVC 總的組件。
摘自: 《SpringMVC 源代碼分析與實踐》
  • Spring 的單例實現原理
Spring 對 Bean 實例的建立是採用單例註冊表的方式進行實現的,而這個註冊表的緩存是 ConcurrentHashMap 對象。
摘抄自: http://blog.720ui.com/2017/de...
  • Spring 框架中用到了哪些設計模式
代理模式—在AOP和remoting中被用的比較多。
單例模式—在spring配置文件中定義的bean默認爲單例模式。
模板方法—用來解決代碼重複的問題。好比. RestTemplate, JmsTemplate, JpaTemplate。
前端控制器—Spring提供了DispatcherServlet來對請求進行分發。
視圖幫助(View Helper )—Spring提供了一系列的JSP標籤,高效宏來輔助將分散的代碼整合在視圖裏。
依賴注入—貫穿於BeanFactory / ApplicationContext接口的核心理念。
工廠模式—BeanFactory用來建立對象的實例。
摘抄自: http://www.importnew.com/1585...
  • Spring 其餘產品(Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等)

Netty

  • 爲何選擇 Netty
1) API使用簡單,開發門檻低;
2) 功能強大,預置了多種編解碼功能,支持多種主流協議;
3) 定製能力強,能夠經過 ChannelHandler 對通訊框架進行靈活的擴展;
4) 性能高,經過與其它業界主流的NIO框架對比,Netty的綜合性能最優;
5) 成熟、穩定,Netty修復了已經發現的全部JDK NIO BUG,業務開發人員不須要再爲NIO的BUG而煩惱;
6) 社區活躍,版本迭代週期短,發現的BUG能夠被及時修復,同時,更多的新功能會被加入;
7) 經歷了大規模的商業應用考驗,質量已經獲得驗證。在互聯網、大數據、網絡遊戲、企業應用、電信軟件等衆多行業獲得成功商用,證實了它能夠徹底知足不一樣行業的商業應用。
正是由於這些優勢,Netty逐漸成爲Java NIO編程的首選框架。
摘抄自: http://ifeve.com/netty-2-6/
  • 說說業務中,Netty 的使用場景
構建高性能、低時延的各類Java中間件,例如MQ、分佈式服務框架、ESB消息總線等,Netty主要做爲基礎通訊框架提供高性能、低時延的通訊服務;
公有或者私有協議棧的基礎通訊框架,例如能夠基於Netty構建異步、高性能的WebSocket協議棧;
各領域應用,例如大數據、遊戲等,Netty做爲高性能的通訊框架用於內部各模塊的數據分發、傳輸和彙總等,實現模塊之間高性能通訊。
摘抄自: http://www.voidcn.com/article...
  • 原生的 NIO 在 JDK 1.7 版本存在 epoll bug
它會致使Selector空輪詢,最終致使CPU 100%。官方聲稱在JDK 1.6版本的update18修復了該問題,可是直到JDK 1.7版本該問題仍舊存在,只不過該BUG發生機率下降了一些而已,它並無獲得根本性解決。
摘抄自: http://blog.csdn.net/broadvie...
  • 什麼是TCP 粘包/拆包
一、要發送的數據大於TCP發送緩衝區剩餘空間大小,將會發生拆包。
二、待發送數據大於MSS(最大報文長度),TCP在傳輸前將進行拆包。
三、要發送的數據小於TCP發送緩衝區的大小,TCP將屢次寫入緩衝區的數據一次發送出去,將會發生粘包。
四、接收數據端的應用層沒有及時讀取接收緩衝區中的數據,將發生粘包。
摘抄自: https://blog.insanecoder.top/...
  • TCP粘包/拆包的解決辦法
一、發送端給每一個數據包添加包首部,首部中應該至少包含數據包的長度,這樣接收端在接收到數據後,經過讀取包首部的長度字段,便知道每個數據包的實際長度了。
二、發送端將每一個數據包封裝爲固定長度(不夠的能夠經過補0填充),這樣接收端每次從接收緩衝區中讀取固定長度的數據就天然而然的把每一個數據包拆分開來。
三、能夠在數據包之間設置邊界,如添加特殊符號,這樣,接收端經過這個邊界就能夠將不一樣的數據包拆分開。
摘抄自: https://blog.insanecoder.top/...
  • Netty 線程模型
首先,Netty使用EventLoop來處理鏈接上的讀寫事件,而一個鏈接上的全部請求都保證在一個EventLoop中被處理,一個EventLoop中只有一個Thread,因此也就實現了一個鏈接上的全部事件只會在一個線程中被執行。一個EventLoopGroup包含多個EventLoop,能夠把一個EventLoop當作是Reactor線程模型中的一個線程,而一個EventLoopGroup相似於一個ExecutorService
做者:一字馬胡
連接: https://www.jianshu.com/p/128...
來源:簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權,非商業轉載請註明出處。
  • 說說 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方法,它能夠直接將文件緩衝區的數據發送到目標Channel,避免了傳統經過循環write方式致使的內存拷貝問題。

摘抄自:http://blog.onlycatch.com/pos...html

  • Netty 重連實現
1.心跳機制檢測鏈接存活
2.啓動時鏈接重試
3.運行中鏈接斷開時重試
摘抄自: http://www.spring4all.com/art...

後期更多猛料放出,關注 spring4all 公衆號關注實時動態:
前端

本文由博客一文多發平臺 OpenWrite 發佈!
相關文章
相關標籤/搜索