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

java線程池面試題

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

　　四種線程池

　　ExecutorService executorService =固定大小線程池

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

　　可緩存線程池 Executors.newCachedThreadPool(); 線程池?zé)o限大，而系統(tǒng)資源(內(nèi)存等)有限，會(huì)導(dǎo)致機(jī)器內(nèi)存溢出OOM。

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

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

/* 自定義線程池。

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

         * public ThreadPoolExecutor(

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

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

             * long keepAliveTime,--保持活著的空間時(shí)間

             * TimeUnit unit,--時(shí)間單位

             * BlockingQueueworkQueue,--排隊(duì)等待的自定義隊(duì)列

             * ThreadFactoty threadFactory,

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

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

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

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

　　（2）若大于corePoolSize，則會(huì)將任務(wù)加入隊(duì)列，

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

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

　　JDK拒絕策略

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

　　（2）DiscardOldestPolicy:丟棄最老的一個(gè)請(qǐng)求，嘗試再次提交當(dāng)前任務(wù)。

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

new ThreadPoolExecutor(   

   2, 3, 30, TimeUnit.SECONDS,    

    new SynchronousQueue(),    

    new RecorderThreadFactory("CookieRecorderPool"),    

     new ThreadPoolExecutor.CallerRunsPolicy());  

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

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

　　26、Reactor模式

Reactor單線程模型

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

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

　　Reactor多線程模型

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

　　主從Reactor模型

　　主Reactor用于響應(yīng)連接請(qǐng)求，從Reactor用于處理IO操作請(qǐng)求!??

特點(diǎn)是：服務(wù)端用于接收客戶端連接的不再是1個(gè)單獨(dú)的NIO線程(Acceptor線程)，而是一個(gè)獨(dú)立的NIO線程池。??

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

?

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

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

　　java jvm 面試題

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

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

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

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

（3）該類對(duì)應(yīng)的java.lang.Class對(duì)象沒有任何地方被引用

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

　　29、可以作為GC Roots的對(duì)象包括哪些

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

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

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

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

　　30、JVM運(yùn)行時(shí)內(nèi)存模型

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

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

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

　　32、判斷對(duì)象是否存活的兩種方法

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

（2）可達(dá)性分析

　　33、Java對(duì)象的初始化過程

34、類加載雙親委派模型

　　從上到下分三個(gè)類加載器：

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

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

　　雙親委派模型：

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

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

　　Zookeeper面試題

　　35、Zookeeper的常用應(yīng)用場(chǎng)景有哪些

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

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

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

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

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

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

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

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

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

　　38、ZK集群最少需要幾臺(tái)機(jī)器?

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

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

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

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

作為注冊(cè)中心，推薦Eureka，因?yàn)樽?cè)服務(wù)更重要的是可用性。

　　Mysql面試題

　　39、InnoDB和MyISAM存儲(chǔ)引擎的區(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ù)庫事務(wù)必須具備ACID特性

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

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

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

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

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

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

　　43、Select For Update使用場(chǎng)景

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

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

　　XA-DTP模型

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

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

　　TCC模型

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

　　45、Mysql-binlog日志復(fù)制方式

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

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

（3）混合復(fù)制

　　46、mysql主從復(fù)制原理

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

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

　　基于日志點(diǎn)的復(fù)制：從主服務(wù)器的哪個(gè)二進(jìn)制日志的偏移量進(jìn)行增量同步，如果指定錯(cuò)誤會(huì)造成遺漏或重復(fù)。 

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

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

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

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

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

　　49、消費(fèi)者宕機(jī)：怎么保證消息隊(duì)列消息不丟失?

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

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

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

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

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

原因：因?yàn)橛锌赡躌abbitMQ接收到了消息，但是還沒來得及持久化到磁盤，他自己就宕機(jī)了，這個(gè)時(shí)候消息還是會(huì)丟失的。如果要完全100%保證寫入RabbitMQ的數(shù)據(jù)必須落地磁盤，不會(huì)丟失，需要依靠其他的機(jī)制。

　　Spring源碼面試題

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

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

　　52、spring事務(wù)的傳播行為和隔離級(jí)別

　　spring事務(wù)七個(gè)事務(wù)傳播行為

　　在TransactionDefinition接口中定義了七個(gè)事務(wù)傳播行為：

　　PROPAGATION_REQUIRED 如果存在一個(gè)事務(wù)，則支持當(dāng)前事務(wù)。如果沒有事務(wù)則開啟一個(gè)新的事務(wù)。

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

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

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

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

　　PROPAGATION_NEVER 總是非事務(wù)地執(zhí)行，如果存在一個(gè)活動(dòng)事務(wù)，則拋出異常

　　PROPAGATION_NESTED如果一個(gè)活動(dòng)的事務(wù)存在，則運(yùn)行在一個(gè)嵌套的事務(wù)中. 如果沒有活動(dòng)事務(wù), 則按TransactionDefinition.PROPAGATION_REQUIRED 屬性執(zhí)行

　　Spring事務(wù)的五種隔離級(jí)別

　　在TransactionDefinition接口中定義了五個(gè)不同的事務(wù)隔離級(jí)別

　　ISOLATION_DEFAULT 這是一個(gè)PlatfromTransactionManager默認(rèn)的隔離級(jí)別，使用數(shù)據(jù)庫默認(rèn)的事務(wù)隔離級(jí)別. 另外四個(gè)與JDBC的隔離級(jí)別相對(duì)應(yīng)

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

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

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

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

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

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

1~24道中高級(jí)JAVA工程師面試題及答案請(qǐng)看鏈接：http://www.dabaquan.cn/javazixun/2169.html

53~64道中高級(jí)JAVA工程師面試題及答案請(qǐng)看鏈接：http://www.dabaquan.cn/javazixun/2192.html

相關(guān)推薦

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

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

秋招中高級(jí)Java面試題，10道詳解，死磕就對(duì)了

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

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

騰訊Java高級(jí)工程師高頻面試題