Java框架面試題有哪些

這篇文章主要介紹“Java框架面試題有哪些”，在日常操作中，相信很多人在Java框架面試題有哪些問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Java框架面試題有哪些”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

Spring

• BeanFactory 和 ApplicationContext 有什么區(qū)別

BeanFactory 可以理解為含有bean集合的工廠類(lèi)。BeanFactory 包含了種bean的定義，以便在接收到客戶(hù)端請(qǐng)求時(shí)將對(duì)應(yīng)的bean實(shí)例化。 BeanFactory還能在實(shí)例化對(duì)象的時(shí)生成協(xié)作類(lèi)之間的關(guān)系。此舉將bean自身與bean客戶(hù)端的配置中解放出來(lái)。BeanFactory還包含了bean生命周期的控制，調(diào)用客戶(hù)端的初始化方法（initialization methods）和銷(xiāo)毀方法（destruction methods）。 從表面上看，application context如同bean factory一樣具有bean定義、bean關(guān)聯(lián)關(guān)系的設(shè)置，根據(jù)請(qǐng)求分發(fā)bean的功能。但application context在此基礎(chǔ)上還提供了其他的功能。 提供了支持國(guó)際化的文本消息 統(tǒng)一的資源文件讀取方式 已在監(jiān)聽(tīng)器中注冊(cè)的bean的事件 

• Spring Bean 的生命周期

Spring Bean的生命周期簡(jiǎn)單易懂。在一個(gè)bean實(shí)例被初始化時(shí)，需要執(zhí)行一系列的初始化操作以達(dá)到可用的狀態(tài)。同樣的，當(dāng)一個(gè)bean不在被調(diào)用時(shí)需要進(jìn)行相關(guān)的析構(gòu)操作，并從bean容器中移除。 Spring bean factory 負(fù)責(zé)管理在spring容器中被創(chuàng)建的bean的生命周期。Bean的生命周期由兩組回調(diào)（call back）方法組成。 初始化之后調(diào)用的回調(diào)方法。 銷(xiāo)毀之前調(diào)用的回調(diào)方法。 Spring框架提供了以下四種方式來(lái)管理bean的生命周期事件： InitializingBean和DisposableBean回調(diào)接口 針對(duì)特殊行為的其他Aware接口 Bean配置文件中的Custom init()方法和destroy()方法 @PostConstruct和@PreDestroy注解方式 

• Spring IOC 如何實(shí)現(xiàn)

Spring中的 org.springframework.beans 包和 org.springframework.context包構(gòu)成了Spring框架IoC容器的基礎(chǔ)。 BeanFactory 接口提供了一個(gè)先進(jìn)的配置機(jī)制，使得任何類(lèi)型的對(duì)象的配置成為可能。ApplicationContex接口對(duì)BeanFactory（是一個(gè)子接口）進(jìn)行了擴(kuò)展，在BeanFactory的基礎(chǔ)上添加了其他功能，比如與Spring的AOP更容易集成，也提供了處理message resource的機(jī)制（用于國(guó)際化）、事件傳播以及應(yīng)用層的特別配置，比如針對(duì)Web應(yīng)用的WebApplicationContext。 org.springframework.beans.factory.BeanFactory 是Spring IoC容器的具體實(shí)現(xiàn)，用來(lái)包裝和管理前面提到的各種bean。BeanFactory接口是Spring IoC 容器的核心接口。

• 說(shuō)說(shuō) Spring AOP

面向切面編程，在我們的應(yīng)用中，經(jīng)常需要做一些事情，但是這些事情與核心業(yè)務(wù)無(wú)關(guān)，比如，要記錄所有update方法的執(zhí)行時(shí)間時(shí)間，操作人等等信息，記錄到日志， 通過(guò)spring的AOP技術(shù)，就可以在不修改update的代碼的情況下完成該需求。

• Spring AOP 實(shí)現(xiàn)原理

Spring AOP中的動(dòng)態(tài)代理主要有兩種方式，JDK動(dòng)態(tài)代理和CGLIB動(dòng)態(tài)代理。JDK動(dòng)態(tài)代理通過(guò)反射來(lái)接收被代理的類(lèi)，并且要求被代理的類(lèi)必須實(shí)現(xiàn)一個(gè)接口。JDK動(dòng)態(tài)代理的核心是InvocationHandler接口和Proxy類(lèi)。 如果目標(biāo)類(lèi)沒(méi)有實(shí)現(xiàn)接口，那么Spring AOP會(huì)選擇使用CGLIB來(lái)動(dòng)態(tài)代理目標(biāo)類(lèi)。CGLIB（Code Generation Library），是一個(gè)代碼生成的類(lèi)庫(kù)，可以在運(yùn)行時(shí)動(dòng)態(tài)的生成某個(gè)類(lèi)的子類(lèi)，注意，CGLIB是通過(guò)繼承的方式做的動(dòng)態(tài)代理，因此如果某個(gè)類(lèi)被標(biāo)記為final，那么它是無(wú)法使用CGLIB做動(dòng)態(tài)代理的。

• 動(dòng)態(tài)代理（cglib 與 JDK）

JDK 動(dòng)態(tài)代理類(lèi)和委托類(lèi)需要都實(shí)現(xiàn)同一個(gè)接口。也就是說(shuō)只有實(shí)現(xiàn)了某個(gè)接口的類(lèi)可以使用Java動(dòng)態(tài)代理機(jī)制。但是，事實(shí)上使用中并不是遇到的所有類(lèi)都會(huì)給你實(shí)現(xiàn)一個(gè)接口。因此，對(duì)于沒(méi)有實(shí)現(xiàn)接口的類(lèi)，就不能使用該機(jī)制。而CGLIB則可以實(shí)現(xiàn)對(duì)類(lèi)的動(dòng)態(tài)代理。 

• Spring 事務(wù)實(shí)現(xiàn)方式

1、編碼方式 所謂編程式事務(wù)指的是通過(guò)編碼方式實(shí)現(xiàn)事務(wù)，即類(lèi)似于JDBC編程實(shí)現(xiàn)事務(wù)管理。 2、聲明式事務(wù)管理方式 聲明式事務(wù)管理又有兩種實(shí)現(xiàn)方式：基于xml配置文件的方式；另一個(gè)實(shí)在業(yè)務(wù)方法上進(jìn)行@Transaction注解，將事務(wù)規(guī)則應(yīng)用到業(yè)務(wù)邏輯中

• Spring 事務(wù)底層原理

a、劃分處理單元——IOC 由于spring解決的問(wèn)題是對(duì)單個(gè)數(shù)據(jù)庫(kù)進(jìn)行局部事務(wù)處理的，具體的實(shí)現(xiàn)首相用spring中的IOC劃分了事務(wù)處理單元。并且將對(duì)事務(wù)的各種配置放到了ioc容器中（設(shè)置事務(wù)管理器，設(shè)置事務(wù)的傳播特性及隔離機(jī)制）。 b、AOP攔截需要進(jìn)行事務(wù)處理的類(lèi) Spring事務(wù)處理模塊是通過(guò)AOP功能來(lái)實(shí)現(xiàn)聲明式事務(wù)處理的，具體操作（比如事務(wù)實(shí)行的配置和讀取，事務(wù)對(duì)象的抽象），用TransactionProxyFactoryBean接口來(lái)使用AOP功能，生成proxy代理對(duì)象，通過(guò)TransactionInterceptor完成對(duì)代理方法的攔截，將事務(wù)處理的功能編織到攔截的方法中。讀取ioc容器事務(wù)配置屬性，轉(zhuǎn)化為spring事務(wù)處理需要的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（TransactionAttributeSourceAdvisor），轉(zhuǎn)化為T(mén)ransactionAttribute表示的數(shù)據(jù)對(duì)象。 c、對(duì)事物處理實(shí)現(xiàn)（事務(wù)的生成、提交、回滾、掛起） spring委托給具體的事務(wù)處理器實(shí)現(xiàn)。實(shí)現(xiàn)了一個(gè)抽象和適配。適配的具體事務(wù)處理器：DataSource數(shù)據(jù)源支持、hibernate數(shù)據(jù)源事務(wù)處理支持、JDO數(shù)據(jù)源事務(wù)處理支持，JPA、JTA數(shù)據(jù)源事務(wù)處理支持。這些支持都是通過(guò)設(shè)計(jì)PlatformTransactionManager、AbstractPlatforTransaction一系列事務(wù)處理的支持。 為常用數(shù)據(jù)源支持提供了一系列的TransactionManager。 d、結(jié)合 PlatformTransactionManager實(shí)現(xiàn)了TransactionInterception接口，讓其與TransactionProxyFactoryBean結(jié)合起來(lái)，形成一個(gè)Spring聲明式事務(wù)處理的設(shè)計(jì)體系。

• 如何自定義注解實(shí)現(xiàn)功能

創(chuàng)建自定義注解和創(chuàng)建一個(gè)接口相似，但是注解的interface關(guān)鍵字需要以@符號(hào)開(kāi)頭。 注解方法不能帶有參數(shù)； 注解方法返回值類(lèi)型限定為：基本類(lèi)型、String、Enums、Annotation或者是這些類(lèi)型的數(shù)組； 注解方法可以有默認(rèn)值； 注解本身能夠包含元注解，元注解被用來(lái)注解其它注解。 摘抄自：http://www.importnew.com/20286.html

• Spring MVC 運(yùn)行流程

1.spring mvc將所有的請(qǐng)求都提交給DispatcherServlet,它會(huì)委托應(yīng)用系統(tǒng)的其他模塊負(fù)責(zé)對(duì)請(qǐng)求 進(jìn)行真正的處理工作。 2.DispatcherServlet查詢(xún)一個(gè)或多個(gè)HandlerMapping,找到處理請(qǐng)求的Controller. 3.DispatcherServlet請(qǐng)請(qǐng)求提交到目標(biāo)Controller 4.Controller進(jìn)行業(yè)務(wù)邏輯處理后，會(huì)返回一個(gè)ModelAndView 5.Dispathcher查詢(xún)一個(gè)或多個(gè)ViewResolver視圖解析器,找到ModelAndView對(duì)象指定的視圖對(duì)象 6.視圖對(duì)象負(fù)責(zé)渲染返回給客戶(hù)端。 

• Spring MVC 啟動(dòng)流程

在 web.xml 文件中給 Spring MVC 的 Servlet 配置了 load-on-startup,所以程序啟動(dòng)的 時(shí)候會(huì)初始化 Spring MVC，在 HttpServletBean 中將配置的 contextConfigLocation 屬性設(shè)置到 Servlet 中，然后在 FrameworkServlet 中創(chuàng)建了 WebApplicationContext, DispatcherServlet 根據(jù) contextConfigLocation 配置的 classpath 下的 xml 文件初始化了 Spring MVC 總的組件。

• Spring 的單例實(shí)現(xiàn)原理

Spring 對(duì) Bean 實(shí)例的創(chuàng)建是采用單例注冊(cè)表的方式進(jìn)行實(shí)現(xiàn)的，而這個(gè)注冊(cè)表的緩存是 ConcurrentHashMap 對(duì)象。 

• Spring 框架中用到了哪些設(shè)計(jì)模式

代理模式—在AOP和remoting中被用的比較多。 單例模式—在spring配置文件中定義的bean默認(rèn)為單例模式。 模板方法—用來(lái)解決代碼重復(fù)的問(wèn)題。比如. RestTemplate, JmsTemplate, JpaTemplate。 前端控制器—Spring提供了DispatcherServlet來(lái)對(duì)請(qǐng)求進(jìn)行分發(fā)。 視圖幫助(View Helper )—Spring提供了一系列的JSP標(biāo)簽，高效宏來(lái)輔助將分散的代碼整合在視圖里。 依賴(lài)注入—貫穿于BeanFactory / ApplicationContext接口的核心理念。 工廠模式—BeanFactory用來(lái)創(chuàng)建對(duì)象的實(shí)例。

• Spring 其他產(chǎn)品（Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等）

Netty

• 為什么選擇 Netty

1. API使用簡(jiǎn)單，開(kāi)發(fā)門(mén)檻低；

2. 功能強(qiáng)大，預(yù)置了多種編解碼功能，支持多種主流協(xié)議；

3. 定制能力強(qiáng)，可以通過(guò) ChannelHandler 對(duì)通信框架進(jìn)行靈活的擴(kuò)展；

4. 性能高，通過(guò)與其它業(yè)界主流的NIO框架對(duì)比，Netty的綜合性能最優(yōu)；

5. 成熟、穩(wěn)定，Netty修復(fù)了已經(jīng)發(fā)現(xiàn)的所有JDK NIO BUG，業(yè)務(wù)開(kāi)發(fā)人員不需要再為NIO的BUG而煩惱；

6. 社區(qū)活躍，版本迭代周期短，發(fā)現(xiàn)的BUG可以被及時(shí)修復(fù)，同時(shí)，更多的新功能會(huì)被加入；

7. 經(jīng)歷了大規(guī)模的商業(yè)應(yīng)用考驗(yàn)，質(zhì)量已經(jīng)得到驗(yàn)證。在互聯(lián)網(wǎng)、大數(shù)據(jù)、網(wǎng)絡(luò)游戲、企業(yè)應(yīng)用、電信軟件等眾多行業(yè)得到成功商用，證明了它可以完全滿足不同行業(yè)的商業(yè)應(yīng)用。 正是因?yàn)檫@些優(yōu)點(diǎn)，Netty逐漸成為Java NIO編程的首選框架。

• 說(shuō)說(shuō)業(yè)務(wù)中，Netty 的使用場(chǎng)景

構(gòu)建高性能、低時(shí)延的各種Java中間件，例如MQ、分布式服務(wù)框架、ESB消息總線等，Netty主要作為基礎(chǔ)通信框架提供高性能、低時(shí)延的通信服務(wù)； 公有或者私有協(xié)議棧的基礎(chǔ)通信框架，例如可以基于Netty構(gòu)建異步、高性能的WebSocket協(xié)議棧； 各領(lǐng)域應(yīng)用，例如大數(shù)據(jù)、游戲等，Netty作為高性能的通信框架用于內(nèi)部各模塊的數(shù)據(jù)分發(fā)、傳輸和匯總等，實(shí)現(xiàn)模塊之間高性能通信。

原生的 NIO 在 JDK 1.7 版本存在 epoll bug

它會(huì)導(dǎo)致Selector空輪詢(xún)，最終導(dǎo)致CPU 100%。官方聲稱(chēng)在JDK 1.6版本的update18修復(fù)了該問(wèn)題，但是直到JDK 1.7版本該問(wèn)題仍舊存在，只不過(guò)該BUG發(fā)生概率降低了一些而已，它并沒(méi)有得到根本性解決。

• 什么是TCP 粘包/拆包

1、要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包。 2、待發(fā)送數(shù)據(jù)大于MSS（最大報(bào)文長(zhǎng)度），TCP在傳輸前將進(jìn)行拆包。 3、要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫(xiě)入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會(huì)發(fā)生粘包。 4、接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包。 TCP粘包/拆包的解決辦法

1、發(fā)送端給每個(gè)數(shù)據(jù)包添加包首部，首部中應(yīng)該至少包含數(shù)據(jù)包的長(zhǎng)度，這樣接收端在接收到數(shù)據(jù)后，通過(guò)讀取包首部的長(zhǎng)度字段，便知道每一個(gè)數(shù)據(jù)包的實(shí)際長(zhǎng)度了。 2、發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度（不夠的可以通過(guò)補(bǔ)0填充），這樣接收端每次從接收緩沖區(qū)中讀取固定長(zhǎng)度的數(shù)據(jù)就自然而然的把每個(gè)數(shù)據(jù)包拆分開(kāi)來(lái)。 3、可以在數(shù)據(jù)包之間設(shè)置邊界，如添加特殊符號(hào)，這樣，接收端通過(guò)這個(gè)邊界就可以將不同的數(shù)據(jù)包拆分開(kāi)。 

• Netty 線程模型

首先，Netty使用EventLoop來(lái)處理連接上的讀寫(xiě)事件，而一個(gè)連接上的所有請(qǐng)求都保證在一個(gè)EventLoop中被處理，一個(gè)EventLoop中只有一個(gè)Thread，所以也就實(shí)現(xiàn)了一個(gè)連接上的所有事件只會(huì)在一個(gè)線程中被執(zhí)行。一個(gè)EventLoopGroup包含多個(gè)EventLoop，可以把一個(gè)EventLoop當(dāng)做是Reactor線程模型中的一個(gè)線程，而一個(gè)EventLoopGroup類(lèi)似于一個(gè)ExecutorService 

• 說(shuō)說(shuō) Netty 的零拷貝

“零拷貝”是指計(jì)算機(jī)操作的過(guò)程中，CPU不需要為數(shù)據(jù)在內(nèi)存之間的拷貝消耗資源。而它通常是指計(jì)算機(jī)在網(wǎng)絡(luò)上發(fā)送文件時(shí)，不需要將文件內(nèi)容拷貝到用戶(hù)空間（User Space）而直接在內(nèi)核空間（Kernel Space）中傳輸?shù)骄W(wǎng)絡(luò)的方式。

• Netty 內(nèi)部執(zhí)行流程

1. Netty的接收和發(fā)送ByteBuffer采用DIRECT BUFFERS，使用堆外直接內(nèi)存進(jìn)行Socket讀寫(xiě)，不需要進(jìn)行字節(jié)緩沖區(qū)的二次拷貝。如果使用傳統(tǒng)的堆內(nèi)存（HEAP BUFFERS）進(jìn)行Socket讀寫(xiě)，JVM會(huì)將堆內(nèi)存Buffer拷貝一份到直接內(nèi)存中，然后才寫(xiě)入Socket中。相比于堆外直接內(nèi)存，消息在發(fā)送過(guò)程中多了一次緩沖區(qū)的內(nèi)存拷貝。

2. Netty提供了組合Buffer對(duì)象，可以聚合多個(gè)ByteBuffer對(duì)象，用戶(hù)可以像操作一個(gè)Buffer那樣方便的對(duì)組合Buffer進(jìn)行操作，避免了傳統(tǒng)通過(guò)內(nèi)存拷貝的方式將幾個(gè)小Buffer合并成一個(gè)大的Buffer。

3. Netty的文件傳輸采用了transferTo方法，它可以直接將文件緩沖區(qū)的數(shù)據(jù)發(fā)送到目標(biāo)Channel，避免了傳統(tǒng)通過(guò)循環(huán)write方式導(dǎo)致的內(nèi)存拷貝問(wèn)題。Netty 重連實(shí)現(xiàn)

1.心跳機(jī)制檢測(cè)連接存活 2.啟動(dòng)時(shí)連接重試 3.運(yùn)行中連接斷開(kāi)時(shí)重試 

到此，關(guān)于“Java框架面試題有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！