今天動力節(jié)點java培訓機構(gòu)小編為大家匯總了史上最全的中高級JAVA工程師面試題及答案（二），分別是java線程池面試題、java jvm 面試題、Zookeeper面試題、Mysql面試題及Mysql性能診斷和優(yōu)化面試題，希望能夠幫助到正在找工作的中高級JAVA程序員，下面就隨小編一起來看看吧。

java線程池面試題

　　25、Executors框架的四種線程池及拒絕策略

　　四種線程池

　　ExecutorService executorService =固定大小線程池

　　Executors.newFixedThreadPool(60); 設置固定值會造成高并發(fā)線程排隊等待空閑線程，尤其是當讀取大數(shù)據(jù)量時線程處理時間長而不釋放線程，導致無法創(chuàng)建新線程。

　　可緩存線程池 Executors.newCachedThreadPool(); 線程池無限大，而系統(tǒng)資源(內(nèi)存等)有限，會導致機器內(nèi)存溢出OOM。

　　定長且可定時、周期線程池 Executors.newScheduledThreadPool(5);

　　單線程線程池 Executors.newSingledThreadPool();

/* 自定義線程池。

         * 構(gòu)造參數(shù)：

         * public ThreadPoolExecutor(

             * int corePoolSize,--當前線程池核心線程數(shù)

             * int maximumPoolSize,--當前線程池最大線程數(shù)

             * long keepAliveTime,--保持活著的空間時間

             * TimeUnit unit,--時間單位

             * BlockingQueueworkQueue,--排隊等待的自定義隊列

             * ThreadFactoty threadFactory,

             * RejectedExecutionHandler handler--隊列滿以后，其他任務被拒絕執(zhí)行的方法

         * ){.........}

　　在使用有界隊列時，若有新的任務需要執(zhí)行，

　　（1）若線程池實際線程數(shù)小于corePoolSize，則優(yōu)先創(chuàng)建線程，

　　（2）若大于corePoolSize，則會將任務加入隊列，

　　（3）若隊列已滿，則在總線程數(shù)不大于maximumPoolSize的前提下，創(chuàng)建新的線程，

　　（4）若線程數(shù)大于maximumPoolSize，則執(zhí)行拒絕策略。或其他自定義方式。

　　JDK拒絕策略

　　（1）AbortPolicy：默認，直接拋出異常，系統(tǒng)正常工作。

　　（2）DiscardOldestPolicy:丟棄最老的一個請求，嘗試再次提交當前任務。

　　（3）CallerRunsPolicy:只要線程池未關(guān)閉，該策略直接在調(diào)用者線程中，運行當前被丟棄的任務。用線程池中的線程執(zhí)行，而是交給調(diào)用方來執(zhí)行, 如果添加到線程池失敗，那么主線程會自己去執(zhí)行該任務，不會等待線程池中的線程去執(zhí)行

new ThreadPoolExecutor(   

   2, 3, 30, TimeUnit.SECONDS,    

    new SynchronousQueue(),    

    new RecorderThreadFactory("CookieRecorderPool"),    

     new ThreadPoolExecutor.CallerRunsPolicy());  

　　（4）DiscardPolicy：丟棄無法處理的任務，不給予任何處理。

　　（5）自定義拒絕策略 如果需要自定義策略，可以實現(xiàn)RejectedExecutionHandler接口。

　　26、Reactor模式

Reactor單線程模型

一個Acceptor線程，監(jiān)聽Accept事件，負責接收客戶端的連接SocketChannel，SocketChannel注冊到Selector上并關(guān)心可讀可寫事件。一個Reactor線程，負責輪訓selector，將selector注冊的就緒事件的key讀取出來，拿出attach任務Handler根據(jù)事件類型分別去執(zhí)行讀寫等。

　　單線程模型的瓶頸：比如：拿一個客戶端來說，進行多次請求，如果Handler中數(shù)據(jù)讀出來后處理的速度比較慢(非IO操作：解碼-計算-編碼-返回)會造成客戶端的請求被積壓，導致響應變慢!所以引入Reactor多線程模型!

　　Reactor多線程模型

Reactor多線程就是把Handler中的IO操作，非IO操作分開。操作IO的線程稱為IO線程，操作非IO的線程叫做工作線程。客戶端的請求(IO操作：讀取出來的數(shù)據(jù))可以直接放進工作線程池(非IO操作：解碼-計算-編碼-返回)中，這樣異步處理，客戶端發(fā)送的請求就得到返回了不會一直阻塞在Handler中。但是當用戶進一步增加的時候，Reactor線程又會出現(xiàn)瓶頸，因為Reactor中既有IO操作，又要響應連接請求。為了分擔Reactor的負擔，所以引入了主從Reactor模型!

　　主從Reactor模型

　　主Reactor用于響應連接請求，從Reactor用于處理IO操作請求!??

特點是：服務端用于接收客戶端連接的不再是1個單獨的NIO線程(Acceptor線程)，而是一個獨立的NIO線程池。??

Acceptor線程池接收到客戶端TCP連接請求處理完成后(可能包含接入認證等)，將新創(chuàng)建的SocketChannel注冊到I/O線程池(sub reactor線程池)的某個I/O線程上，由它負責SocketChannel的讀寫和編解碼工作。

?

Acceptor線程池只用于客戶端的登錄、握手和安全認證，一旦鏈路建立成功，就將鏈路注冊到后端subReactor線程池的I/O線程上，有I/O線程負責后續(xù)的I/O操作。??

第三種模型比起第二種模型，是將Reactor分成兩部分，mainReactor負責監(jiān)聽server socket，accept新連接，并將建立的socket分派給subReactor。subReactor負責多路分離已連接的socket，讀寫網(wǎng) 絡數(shù)據(jù)，對業(yè)務處理功能，其扔給worker線程池完成。通常，subReactor個數(shù)上可與CPU個數(shù)等同。

　　java jvm 面試題

　　27、Object的內(nèi)存布局

　　28、方法區(qū)卸載Class的條件

　　（1）該類所有的實例已經(jīng)被回收 

（2）加載該類的ClassLoader已經(jīng)被回收 

（3）該類對應的java.lang.Class對象沒有任何地方被引用

　　Ps：方法區(qū)除了回收無用class，也回收廢棄常量，即沒有被引用常量

　　29、可以作為GC Roots的對象包括哪些

　　（1）虛擬機棧(棧幀中的局部變量表)中引用的變量 

（2）方法區(qū)中類靜態(tài)屬性引用的對象 

（3）方法區(qū)中常量引用的對象 

（4）本地方法棧中JNI引用的變量

　　30、JVM運行時內(nèi)存模型

　　方法區(qū)、堆、虛擬機棧、本地方法棧、程序計數(shù)器

　　31、Netty的ByteBuffer的引用計數(shù)器機制

　　從netty的4.x版本開始，netty使用引用計數(shù)機制進行部分對象的管理，通過該機制netty可以很好的實現(xiàn)自己的共享資源池。如果應用需要一個資源，可以從netty自己的共享資源池中獲取，新獲取的資源對象的引用計數(shù)被初始化為1，可以通過資源對象的retain方法增加引用計數(shù)，當引用計數(shù)為0的時候該資源對象擁有的資源將會被回收。

　　32、判斷對象是否存活的兩種方法

　　（1）引用計數(shù)法：缺點是對循環(huán)引用的對象無法回收 

（2）可達性分析

　　33、Java對象的初始化過程

34、類加載雙親委派模型

　　從上到下分三個類加載器：

　　BootStrap classloader：啟動類加載器，負責將Java_HOME/lib下的類庫加載到虛擬機內(nèi)存中，比如rt.jar Extension classloader:擴展類加載器，負責將JAVA_HOME/lib/ext下的類庫加載到虛擬機內(nèi)存中。

 Application classloader：應用程序類加載器，負責加載classpath環(huán)境變量下指定的類庫。如果程序中沒有自定義過類加載器，那么這個就是程序中默認的類加載器。

　　雙親委派模型：

　　如果一個類加載器收到類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器完成。每個類加載器都是如此，只有當父加載器在自己的搜索范圍內(nèi)找不到指定的類時(即ClassNotFoundException)，子加載器才會嘗試自己去加載。

　　防止自定義的一些跟jdk標準庫中沖突的全限定名的類被加載，導致標準庫函數(shù)不可用。

　　Zookeeper面試題

　　35、Zookeeper的常用應用場景有哪些

　　分布式鎖：獲取父節(jié)點下的最小節(jié)點作為獲得鎖的一方

　　命名服務：通過在zookeeper節(jié)點下創(chuàng)建全局唯一的一個path

　　配置管理：配置放在zk上，所有應用監(jiān)聽節(jié)點改變。

　　集群管理：GroupMembers集群管理，是否有機器退出和加入

　　36、Zookeeper的分布式數(shù)據(jù)一致性算法

　　?ZAB原子消息廣播協(xié)議*。

　　一種是基于basic paxos實現(xiàn)的，另外一種是基于fast paxos算法實現(xiàn)的。

　　37、Zookeeper數(shù)據(jù)同步的簡單描述

　　在ZooKeeper中所有的客戶端事務請求都由一個主服務器也就是Leader來處理，其他服務器為Follower，Leader將客戶端的事務請求轉(zhuǎn)換為事務Proposal，并且將Proposal分發(fā)給集群中其他所有的Follower，然后Leader等待Follwer反饋，當有過半數(shù)(>=N/2+1)的Follower反饋信息后，Leader將再次向集群內(nèi)Follower廣播Commit信息，Commit為將之前的Proposal提交;

　　38、ZK集群最少需要幾臺機器?

　　三臺，2N+1，保證奇數(shù)，主要是為了leader選舉算法中的“超過半數(shù)有效(>=N/2+1)”

　　38、Zookeeper和Eureka的區(qū)別

　　ZK保證Cp,即一致性，分區(qū)容錯性，比如當master節(jié)點因為網(wǎng)絡故障和其他節(jié)點失去聯(lián)系的時候，剩余節(jié)點會重新進行Master選舉。問題在于Master選舉的時間太長30~210s，選舉期間整個zk集群是不可用的，這就導致選舉期間的注冊服務癱瘓。??

Eureka保證Ap，高可用性，它沒有所謂主從節(jié)點概念，各節(jié)點平等。某節(jié)點掛掉不影響其他節(jié)點功能，其他節(jié)點照樣提供查詢和注冊功能。Eureka客戶端發(fā)現(xiàn)Eureka節(jié)點掛掉直接切換到其他正常的節(jié)點上去。只不過可能查到的數(shù)據(jù)不是最新的，也就是Eureka不保證數(shù)據(jù)的強一致性。??

作為注冊中心，推薦Eureka，因為注冊服務更重要的是可用性。

　　Mysql面試題

　　39、InnoDB和MyISAM存儲引擎的區(qū)別

　　Starting from MySQL 5.5.5, the default storage engine for new tables isInnoDB rather than MyISAM.

　　40、Btree索引和Hash索引的區(qū)別

　　Btree索引適合范圍查找，Hash索引適合精確查找

　　41、數(shù)據(jù)庫的ACID特性

　　數(shù)據(jù)庫事務必須具備ACID特性

 原子性：Atomic，所有的操作執(zhí)行成功，才算整個事務成功 

一致性：Consistency，不管事務success或fail，不能破壞關(guān)系數(shù)據(jù)的完整性以及業(yè)務邏輯上的一致性 

隔離性：Isolation，每個事務擁有獨立數(shù)據(jù)空間，多個事務的數(shù)據(jù)修改相互隔離。事務查看數(shù)據(jù)更新時，數(shù)據(jù)要么是另一個事務修改前的狀態(tài)，要么是修改后狀態(tài)，不應該查看到中間狀態(tài)數(shù)據(jù)。

持久性：Durability，事務執(zhí)行成功，數(shù)據(jù)必須永久保存。重啟DB，數(shù)據(jù)需要恢復到事務執(zhí)行成功后的狀態(tài)。

原子性、一致性、持久性DBMS通過日志來實現(xiàn)。??隔離性DBMS通過鎖來實現(xiàn)

　　42、Mysql數(shù)據(jù)庫的隔離級別

　　43、Select For Update使用場景

　　select for update 的使用場景，為了避免自己看到的數(shù)據(jù)并不是數(shù)據(jù)庫存儲的最新數(shù)據(jù)并且看到的數(shù)據(jù)只能由自己修改，需要用 for update 來限制。

　　44、分布式事務模型之XA和TCC的區(qū)別和聯(lián)系?

　　XA-DTP模型

　　最早的分布式事務模型是 X/Open 國際聯(lián)盟提出的 X/Open Distributed Transaction Processing(DTP)模型，也就是大家常說的 X/Open XA 協(xié)議，簡稱XA 協(xié)議。??

DTP 模型中包含一個全局事務管理器(TM，Transaction Manager)和多個資源管理器(RM，Resource Manager)。全局事務管理器負責管理全局事務狀態(tài)與參與的資源，協(xié)同資源一起提交或回滾;資源管理器則負責具體的資源操作。

　　TCC模型

　　TCC(Try-Confirm-Cancel)分布式事務模型相對于 XA 等傳統(tǒng)模型，其特征在于它不依賴資源管理器(RM)對分布式事務的支持，而是通過對業(yè)務邏輯的分解來實現(xiàn)分布式事務。Try-Confirm-Cancel Try 操作對應2PC 的一階段準備(Prepare);Confirm 對應 2PC 的二階段提交(Commit)，Cancel 對應 2PC 的二階段回滾(Rollback)，可以說 TCC 就是應用層的 2PC。

　　45、Mysql-binlog日志復制方式

　 （1）基于段的復制 記錄的是執(zhí)行的語句

（2）基于行的復制 記錄是表中每一行的操作 

（3）混合復制

　　46、mysql主從復制原理

　　從服務器的IO線程讀取主服務器的二進制日志變更，寫入到中繼日志relaylog中，如果IO線程追趕上了主服務器的日志，則進入sleep狀態(tài)，直到主服務器發(fā)送喚醒信號，從服務器上的SQL線程重放relaylog中的日志。

　　47、基于日志點的復制和GTID的復制有何區(qū)別?

　　基于日志點的復制：從主服務器的哪個二進制日志的偏移量進行增量同步，如果指定錯誤會造成遺漏或重復。 

基于GTID的復制：從服務器會告訴主服務器，已經(jīng)在從服務器上已經(jīng)執(zhí)行完了哪些gtid值，然后主庫會把從庫未執(zhí)行的事務gtid值發(fā)送給從庫執(zhí)行。同一個事務只在指定的從庫上執(zhí)行一次。

　　Mysql性能診斷和優(yōu)化面試題

　　48、聚簇索引和非聚簇索引的區(qū)別

　　聚簇索引：就是指主索引文件和數(shù)據(jù)文件為同一份文件，聚簇索引主要用在Innodb存儲引擎中。如主鍵。B+Tree的葉子節(jié)點上的data就是數(shù)據(jù)本身。 

非聚簇索引：就是指B+Tree的葉子節(jié)點上的data，并不是數(shù)據(jù)本身，而是數(shù)據(jù)存放的地址

　　49、消費者宕機：怎么保證消息隊列消息不丟失?

　　比如activemq或者rabbitmq生產(chǎn)者消息投遞到消息隊列后，消費者拿到消息后，默認是自動簽收機制，消息隊列將刪除這條消息，但是如果僅僅是拿到但是沒有來得及處理業(yè)務邏輯時，消費者就宕機，那么此消息將會丟失，以后也不會再收到。 

解決辦法：消費端要設置簽收機制為手動簽收，只有當消息最終被處理，才告訴消息隊列已經(jīng)消費，此時消息隊列再刪除這條消息。

　　50、MQ集群宕機：怎么保證消息不丟失?

　　生產(chǎn)者投遞消息到mq服務器，如果不保證消息和隊列的持久化，那么當mq宕機時消息將徹底丟失，所以需要對消息做持久化存儲，可以存儲到磁盤或者數(shù)據(jù)庫中，當mq服務器恢復時，消費端可以繼續(xù)消費mq服務器中的消息。

　　但是，比如RabbitMQ的消息持久化，是不承諾100%的消息不丟失的!??

原因：因為有可能RabbitMQ接收到了消息，但是還沒來得及持久化到磁盤，他自己就宕機了，這個時候消息還是會丟失的。如果要完全100%保證寫入RabbitMQ的數(shù)據(jù)必須落地磁盤，不會丟失，需要依靠其他的機制。

　　Spring源碼面試題

　　51、springmvc如何解決循環(huán)依賴的問題

　　當使用構(gòu)造器方式初始化一個bean，而且此時多個Bean之間有循環(huán)依賴的情況，spring容器就會拋出異常! 解決辦法：初始化bean的時候(注意此時的bean必須是單例，否則不能提前暴露一個創(chuàng)建中的bean)使用set方法進行注入屬性，此時bean對象會先執(zhí)行構(gòu)造器實例化，接著將實例化后的bean放入一個map中，并提供引用。當需要通過set方式設置bean的屬性的時候，spring容器就會從map中取出被實例化的bean。比如A對象需要set注入B對象，那么從Map中取出B對象即可。以此類推，不會出現(xiàn)循環(huán)依賴的異常。

　　52、spring事務的傳播行為和隔離級別

　　spring事務七個事務傳播行為

　　在TransactionDefinition接口中定義了七個事務傳播行為：

　　PROPAGATION_REQUIRED 如果存在一個事務，則支持當前事務。如果沒有事務則開啟一個新的事務。

　　PROPAGATION_SUPPORTS 如果存在一個事務，支持當前事務。如果沒有事務，則非事務的執(zhí)行。但是對于事務同步的事務管理器，PROPAGATION_SUPPORTS與不使用事務有少許不同。

　　PROPAGATION_MANDATORY 如果已經(jīng)存在一個事務，支持當前事務。如果沒有一個活動的事務，則拋出異常。

　　PROPAGATION_REQUIRES_NEW 總是開啟一個新的事務。如果一個事務已經(jīng)存在，則將這個存在的事務掛起。

　　PROPAGATION_NOT_SUPPORTED 總是非事務地執(zhí)行，并掛起任何存在的事務。

　　PROPAGATION_NEVER 總是非事務地執(zhí)行，如果存在一個活動事務，則拋出異常

　　PROPAGATION_NESTED如果一個活動的事務存在，則運行在一個嵌套的事務中. 如果沒有活動事務, 則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執(zhí)行

　　Spring事務的五種隔離級別

　　在TransactionDefinition接口中定義了五個不同的事務隔離級別

　　ISOLATION_DEFAULT 這是一個PlatfromTransactionManager默認的隔離級別，使用數(shù)據(jù)庫默認的事務隔離級別. 另外四個與JDBC的隔離級別相對應

　　ISOLATION_READ_UNCOMMITTED 這是事務最低的隔離級別，它充許別外一個事務可以看到這個事務未提交的數(shù)據(jù)。這種隔離級別會產(chǎn)生臟讀，不可重復讀和幻像讀

　　ISOLATION_READ_COMMITTED 保證一個事務修改的數(shù)據(jù)提交后才能被另外一個事務讀取。另外一個事務不能讀取該事務未提交的數(shù)據(jù)。這種事務隔離級別可以避免臟讀出現(xiàn)，但是可能會出現(xiàn)不可重復讀和幻像讀。

　　ISOLATION_REPEATABLE_READ 這種事務隔離級別可以防止臟讀，不可重復讀。但是可能出現(xiàn)幻像讀。它除了保證一個事務不能讀取另一個事務未提交的數(shù)據(jù)外，還保證了避免下面的情況產(chǎn)生(不可重復讀)。

　　ISOLATION_SERIALIZABLE 這是花費最高代價但是最可靠的事務隔離級別。事務被處理為順序執(zhí)行。除了防止臟讀，不可重復讀外，還避免了幻像讀。

以上就是動力java培訓機構(gòu)小編介紹的“史上最全的中高級JAVA工程師面試題及答案（二）”的內(nèi)容，希望對大家有幫助，更多java最新面試題請繼續(xù)關(guān)注動力節(jié)點java培訓機構(gòu)官網(wǎng)，每天會有精彩內(nèi)容分享與你。

由于“史上最全的中高級JAVA工程師面試題及答案”內(nèi)容太多，本文已滿，請看下文鏈接：

1~24道中高級JAVA工程師面試題及答案請看鏈接：http://www.ilovecolors.com.cn/javazixun/2169.html

53~64道中高級JAVA工程師面試題及答案請看鏈接：http://www.ilovecolors.com.cn/javazixun/2192.html

相關(guān)推薦

面試題總結(jié)—高級Java工程師面試題

Java高級開發(fā)工程師面試題

秋招中高級Java面試題，10道詳解，死磕就對了

最新Java工程師面試題整理[社招篇]

大家都在收藏的中級常見Java工程師面試題

騰訊Java高級工程師高頻面試題