高頻web后端工程師面試題及答案Java中如何解決循環(huán)依賴？Spring通過三級(jí)緩存機(jī)制處理循環(huán)依賴。一級(jí)緩存singletonObjects存儲(chǔ)已完成初始化的Bean實(shí)例；二級(jí)緩存earlySingletonObjects存儲(chǔ)提前暴露的未初始化Bean（用于解決AOP代理問題）；三級(jí)緩存singletonFactories存儲(chǔ)ObjectFactory工廠，用于提供早期Bean引用。當(dāng)A依賴B、B依賴A時(shí)，創(chuàng)建A的流程為：實(shí)例化A→將A的ObjectFactory存入三級(jí)緩存→執(zhí)行屬性注入時(shí)發(fā)現(xiàn)需要B→觸發(fā)B的創(chuàng)建流程→B實(shí)例化后存入三級(jí)緩存→B屬性注入時(shí)需要A→從A的三級(jí)緩存獲取ObjectFactory提供早期A實(shí)例（可能是代理對(duì)象）→將早期A存入二級(jí)緩存并移除三級(jí)緩存→B完成初始化后存入一級(jí)緩存→回到A的屬性注入，從一級(jí)緩存獲取B→A完成初始化后存入一級(jí)緩存，同時(shí)移除二級(jí)緩存中的早期引用。需注意構(gòu)造器注入無法解決循環(huán)依賴，因?yàn)闃?gòu)造器調(diào)用發(fā)生在實(shí)例化階段，此時(shí)三級(jí)緩存尚未提供；而@Lazy注解通過延遲加載將依賴包裝為代理對(duì)象，可繞過實(shí)例化階段的直接依賴。MySQL中覆蓋索引和回表的區(qū)別是什么？覆蓋索引指查詢所需的所有字段都包含在索引中，無需回表查詢主鍵對(duì)應(yīng)的行數(shù)據(jù)。例如，若有聯(lián)合索引（name,age），執(zhí)行selectname,agefromuserwherename='張三'時(shí)，索引本身已包含name和age，直接通過索引獲取數(shù)據(jù)。回表則是查詢字段不在索引中，需先通過索引找到主鍵，再根據(jù)主鍵到聚簇索引（主鍵索引）中查找完整行數(shù)據(jù)。例如，索引（name）查詢selectfromuserwherename='張三'，需先通過name索引找到主鍵id，再用id到聚簇索引獲取其他字段。覆蓋索引能顯著減少I/O消耗，優(yōu)化查詢性能，設(shè)計(jì)索引時(shí)應(yīng)盡量讓常用查詢字段包含在索引中。Redis分布式鎖的實(shí)現(xiàn)需要注意哪些問題？核心要點(diǎn)包括：1.鎖的原子性：加鎖需使用setkeyvalueNXPXmilliseconds原子操作，避免setnx和expire分開執(zhí)行導(dǎo)致鎖無法釋放；2.鎖的過期時(shí)間：需根據(jù)業(yè)務(wù)執(zhí)行時(shí)間設(shè)置合理過期時(shí)間，過短可能導(dǎo)致業(yè)務(wù)未完成鎖已釋放，過長(zhǎng)可能導(dǎo)致死鎖；3.鎖的續(xù)期：若業(yè)務(wù)執(zhí)行時(shí)間超過過期時(shí)間，需通過看門狗（如Redisson的自動(dòng)續(xù)期機(jī)制）在鎖過期前自動(dòng)延長(zhǎng)有效期；4.鎖的釋放：釋放時(shí)需驗(yàn)證鎖的持有者（通過唯一value標(biāo)識(shí)），避免誤刪其他客戶端的鎖，可使用Lua腳本保證原子性（ifredis.call('get',KEYS[1])==ARGV[1]thenreturnredis.call('del',KEYS[1])end）；5.可重入性：支持同一線程多次加鎖，需記錄加鎖次數(shù)（如Redisson的可重入鎖通過hash結(jié)構(gòu)存儲(chǔ)鎖計(jì)數(shù)）；6.集群環(huán)境下的一致性：使用Redlock算法（向多個(gè)獨(dú)立Redis實(shí)例加鎖，多數(shù)成功則認(rèn)為加鎖成功）可提升集群環(huán)境的可靠性，但需權(quán)衡性能和一致性。Kafka如何保證消息不丟失？需從生產(chǎn)者、Broker、消費(fèi)者三端處理。生產(chǎn)者端：設(shè)置acks=all（所有ISR副本確認(rèn)），開啟重試（retries>0），使用冪等性（enable.idempotence=true）避免重復(fù)發(fā)送；Broker端：設(shè)置min.insync.replicas≥2（至少2個(gè)同步副本），確保消息寫入多數(shù)副本后才確認(rèn)；保留消息（log.retention.hours足夠大），避免日志過早刪除；消費(fèi)者端：關(guān)閉自動(dòng)提交（mit=false），手動(dòng)提交offset需在消息處理完成后執(zhí)行，避免處理未完成時(shí)提交offset導(dǎo)致消息丟失；處理消息時(shí)做好異常捕獲，確保失敗時(shí)能重試或記錄到死信隊(duì)列。分布式事務(wù)的TCC模式具體如何實(shí)現(xiàn)？TCC（Try-Confirm-Cancel）分為三個(gè)階段：1.Try階段：預(yù)留資源，檢查業(yè)務(wù)參數(shù)合法性，凍結(jié)相關(guān)資源（如訂單服務(wù)預(yù)扣庫(kù)存、支付服務(wù)預(yù)占額度）；2.Confirm階段：正式提交資源，將Try階段預(yù)留的資源確認(rèn)使用（如庫(kù)存扣減、額度扣除）；3.Cancel階段：回滾資源，釋放Try階段預(yù)留的資源（如庫(kù)存解凍、額度恢復(fù)）。實(shí)現(xiàn)時(shí)需注意：Try需冪等（多次調(diào)用結(jié)果一致），Confirm/Cancel需可重試（網(wǎng)絡(luò)波動(dòng)可能導(dǎo)致重復(fù)調(diào)用），且需記錄事務(wù)日志（用于故障時(shí)的事務(wù)恢復(fù)）。例如，電商下單場(chǎng)景：訂單服務(wù)Try預(yù)提供訂單（狀態(tài)為“待確認(rèn)”），庫(kù)存服務(wù)Try預(yù)扣庫(kù)存（標(biāo)記為“已鎖定”），支付服務(wù)Try預(yù)占賬戶余額（標(biāo)記為“已凍結(jié)”）；所有Try成功后執(zhí)行Confirm，訂單狀態(tài)改為“已支付”，庫(kù)存正式扣減，余額正式扣除；若任一Try失敗，則執(zhí)行Cancel，訂單取消，庫(kù)存解鎖，余額解凍。JVM內(nèi)存模型中各區(qū)域的作用及常見異常有哪些？JVM內(nèi)存分為五部分：1.程序計(jì)數(shù)器：記錄當(dāng)前線程執(zhí)行的字節(jié)碼行號(hào)，線程私有，無內(nèi)存溢出問題；2.虛擬機(jī)棧：存儲(chǔ)方法調(diào)用的棧幀（局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、返回地址），線程私有，若線程請(qǐng)求的棧深度超過限制會(huì)拋出StackOverflowError；若棧擴(kuò)展失敗（動(dòng)態(tài)擴(kuò)展場(chǎng)景）會(huì)拋出OutOfMemoryError；3.本地方法棧：與虛擬機(jī)棧類似，用于本地方法調(diào)用，異常類型相同；4.堆：存儲(chǔ)對(duì)象實(shí)例和數(shù)組，線程共享，是GC的主要區(qū)域，若對(duì)象過多無法分配內(nèi)存會(huì)拋出OutOfMemoryError:Javaheapspace；5.方法區(qū)（元空間，JDK8后）：存儲(chǔ)類信息、常量、靜態(tài)變量、即時(shí)編譯代碼等，線程共享，若類信息過多（如動(dòng)態(tài)提供大量Class）會(huì)拋出OutOfMemoryError:Metaspace。MySQL的間隙鎖（GapLock）在什么場(chǎng)景下會(huì)觸發(fā)？如何避免？間隙鎖是InnoDB在可重復(fù)讀隔離級(jí)別下為解決幻讀問題引入的鎖，鎖定索引記錄之間的間隙（包括索引前、后間隙），防止其他事務(wù)插入新記錄。觸發(fā)場(chǎng)景：當(dāng)使用范圍查詢（如whereidbetween10and20）且查詢字段是索引字段時(shí)，若記錄不存在或存在但需鎖定范圍，InnoDB會(huì)對(duì)該范圍內(nèi)的間隙加鎖。例如，表中有id=5、id=25的記錄，執(zhí)行updateusersetstatus=1whereidbetween10and20，會(huì)鎖定(5,25)的間隙，阻止其他事務(wù)插入id=15的記錄。間隙鎖可能導(dǎo)致死鎖（如兩個(gè)事務(wù)同時(shí)鎖定同一間隙并嘗試插入），可通過以下方式避免：1.將隔離級(jí)別改為讀提交（RC），InnoDB在RC下僅使用記錄鎖（RowLock）；2.優(yōu)化查詢條件，避免范圍鎖（如明確查詢存在的記錄）；3.使用覆蓋索引，減少鎖的范圍；4.對(duì)業(yè)務(wù)允許的場(chǎng)景，添加字段讓范圍查詢變?yōu)榈戎挡樵儯ㄈ缭黾訝顟B(tài)字段限制）。Redis的持久化機(jī)制RDB和AOF的區(qū)別及選擇策略？RDB（快照持久化）通過定時(shí)（如save9001）或手動(dòng)（save/bgsave）提供二進(jìn)制快照文件（dump.rdb），記錄某一時(shí)刻的內(nèi)存數(shù)據(jù)。優(yōu)點(diǎn)：文件緊湊，恢復(fù)速度快；缺點(diǎn)：可能丟失最后一次快照后的所有數(shù)據(jù)（取決于快照間隔）。AOF（日志持久化）記錄所有寫操作命令（appendonly.aof），通過重寫（bgrewriteaof）壓縮日志。優(yōu)點(diǎn)：數(shù)據(jù)丟失少（可配置每秒同步、每次寫同步）；缺點(diǎn)：文件較大，恢復(fù)速度慢。選擇策略：1.對(duì)數(shù)據(jù)一致性要求不高的場(chǎng)景（如緩存），可僅用RDB；2.對(duì)數(shù)據(jù)一致性要求高的場(chǎng)景（如會(huì)話存儲(chǔ)），建議RDB+AOF結(jié)合（AOF保證實(shí)時(shí)性，RDB加速恢復(fù)）；3.AOF配置推薦appendfsync=everysec（每秒同步，兼顧性能和安全），RDB配置save6010000（減少快照頻率，降低CPU消耗）。微服務(wù)中如何實(shí)現(xiàn)服務(wù)限流？常見限流算法有令牌桶、漏桶、滑動(dòng)窗口。1.令牌桶：以固定速率向桶中添加令牌（如100個(gè)/秒），請(qǐng)求需獲取令牌才能通過，支持突發(fā)流量（桶容量限制最大突發(fā)量）；2.漏桶：請(qǐng)求進(jìn)入漏桶后以固定速率流出（如100個(gè)/秒），超過容量的請(qǐng)求被拒絕，適合平滑流量；3.滑動(dòng)窗口：將時(shí)間劃分為多個(gè)窗口（如1分鐘劃分為6個(gè)10秒窗口），統(tǒng)計(jì)窗口內(nèi)的請(qǐng)求數(shù)，超過閾值則拒絕，精度高于固定窗口。實(shí)現(xiàn)工具：Sentinel（支持QPS、線程數(shù)限流，提供熱點(diǎn)參數(shù)限流）、GuavaRateLimiter（令牌桶實(shí)現(xiàn)）、Nginx（通過limit_req模塊實(shí)現(xiàn)漏桶限流）。例如，電商大促時(shí)對(duì)商品詳情接口設(shè)置QPS=5000，使用Sentinel的@SentinelResource注解標(biāo)記接口，配置限流規(guī)則，超出部分返回“系統(tǒng)繁忙”提示。HTTP2相比HTTP1.1有哪些改進(jìn)？1.二進(jìn)制分幀：HTTP1.1基于文本，HTTP2將消息拆分為二進(jìn)制幀（HeaderFrame、DataFrame），更高效解析；2.多路復(fù)用：通過流（Stream）標(biāo)識(shí)（31位整數(shù)）在一個(gè)TCP連接上并發(fā)處理多個(gè)請(qǐng)求/響應(yīng)，解決HTTP1.1的隊(duì)頭阻塞問題（一個(gè)請(qǐng)求阻塞不影響其他請(qǐng)求）；3.頭部壓縮：使用HPACK算法壓縮請(qǐng)求頭，減少重復(fù)字段（如Cookie）的傳輸體積；4.服務(wù)器推送：服務(wù)器可主動(dòng)向客戶端推送關(guān)聯(lián)資源（如HTML請(qǐng)求時(shí)推送CSS、JS），減少客戶端請(qǐng)求次數(shù)；5.流量控制：每個(gè)流可設(shè)置發(fā)送窗口大小，防止接收方處理能力不足導(dǎo)致的阻塞。例如，訪問一個(gè)包含10張圖片的頁面，HTTP1.1需建立多個(gè)TCP連接或順序加載（受限于keep-alive的并發(fā)數(shù)），而HTTP2通過一個(gè)連接并行傳輸所有圖片的DataFrame，顯著提升加載速度。MyBatis的一級(jí)緩存和二級(jí)緩存有何區(qū)別？如何配置？一級(jí)緩存（本地緩存）是SqlSession級(jí)別的緩存，同一SqlSession內(nèi)執(zhí)行相同查詢會(huì)直接從緩存獲取，無需訪問數(shù)據(jù)庫(kù)。失效場(chǎng)景：SqlSession關(guān)閉、執(zhí)行增刪改操作、手動(dòng)調(diào)用clearCache()。二級(jí)緩存（全局緩存）是Mapper級(jí)別的緩存，多個(gè)SqlSession共享（需配置），基于namespace隔離。開啟二級(jí)緩存需：1.在mybatis-config.xml中設(shè)置<settingname="cacheEnabled"value="true"/>；2.在Mapper接口或XML中添加@CacheNamespace注解（注解方式）或<cache/>標(biāo)簽（XML方式）；3.實(shí)體類需實(shí)現(xiàn)Serializable接口。注意：二級(jí)緩存默認(rèn)存儲(chǔ)查詢結(jié)果，若表數(shù)據(jù)頻繁更新，需設(shè)置緩存刷新策略（如flushInterval）或關(guān)閉二級(jí)緩存，避免臟讀。如何設(shè)計(jì)高并發(fā)場(chǎng)景下的接口冪等性？?jī)绲刃灾付啻握{(diào)用同一接口產(chǎn)生的效果與一次調(diào)用相同。實(shí)現(xiàn)方案：1.全局唯一ID：請(qǐng)求時(shí)提供唯一ID（如UUID、雪花ID），服務(wù)端通過數(shù)據(jù)庫(kù)唯一索引或Redis記錄已處理的ID，重復(fù)請(qǐng)求直接返回結(jié)果；2.狀態(tài)機(jī)：通過狀態(tài)字段控制操作（如訂單狀態(tài)“未支付→支付中→已支付”，重復(fù)支付請(qǐng)求檢查狀態(tài)為“已支付”則直接返回）；3.token機(jī)制：客戶端先獲取token（如調(diào)用/genToken接口），請(qǐng)求時(shí)攜帶token，服務(wù)端驗(yàn)證token有效性并刪除（防止重復(fù)使用），可通過Redis存儲(chǔ)token（設(shè)置過期時(shí)間）；4.數(shù)據(jù)庫(kù)樂觀鎖：通過版本號(hào)（version）或時(shí)間戳（update_time）實(shí)現(xiàn)，更新時(shí)檢查版本號(hào)是否匹配（updatetablesetcount=count-1,version=version+1whereid=1andversion=oldVersion）；5.防重表：請(qǐng)求前插入防重表（唯一索引為請(qǐng)求ID），插入成功則處理業(yè)務(wù)，失敗則認(rèn)為重復(fù)請(qǐng)求。例如，支付接口使用全局唯一ID+Redis記錄，服務(wù)端接收到請(qǐng)求后檢查ID是否存在，存在則返回已處理結(jié)果，不存在則處理并記錄ID。ZooKeeper在分布式系統(tǒng)中的常見應(yīng)用場(chǎng)景有哪些？1.服務(wù)注冊(cè)與發(fā)現(xiàn)：服務(wù)啟動(dòng)時(shí)在ZooKeeper的/services節(jié)點(diǎn)下創(chuàng)建臨時(shí)子節(jié)點(diǎn)（如/provider/:8080），注冊(cè)中心監(jiān)聽該節(jié)點(diǎn)獲取可用服務(wù)列表；服務(wù)下線時(shí)臨時(shí)節(jié)點(diǎn)自動(dòng)刪除，實(shí)現(xiàn)動(dòng)態(tài)發(fā)現(xiàn)；2.分布式鎖：通過創(chuàng)建臨時(shí)順序節(jié)點(diǎn)（/lock/seq-），獲取最小節(jié)點(diǎn)的客戶端獲得鎖，其他客戶端監(jiān)聽前一節(jié)點(diǎn)的刪除事件實(shí)現(xiàn)公平鎖；3.配置中心：將配置存儲(chǔ)在ZooKeeper的/conf節(jié)點(diǎn)，客戶端監(jiān)聽節(jié)點(diǎn)變化，配置更新時(shí)自動(dòng)拉取；4.集群管理：通過監(jiān)聽子節(jié)點(diǎn)變化（如/servers）感知集群節(jié)點(diǎn)上下線，實(shí)現(xiàn)負(fù)載均衡；5.分布式協(xié)調(diào)：解決腦裂問題（如雙主系統(tǒng)中通過ZooKeeper選舉主節(jié)點(diǎn)，只有主節(jié)點(diǎn)可寫）。需注意ZooKeeper的CP特性（強(qiáng)一致性，分區(qū)時(shí)可能不可用），適合對(duì)一致性要求高的場(chǎng)景。如何優(yōu)化慢SQL？步驟如下：1.定位慢SQL：通過MySQL的慢查詢?nèi)罩荆╯low_query_log）或監(jiān)控工具（如PerconaToolkit的pt-query-digest）獲取執(zhí)行時(shí)間長(zhǎng)的SQL；2.分析執(zhí)行計(jì)劃：使用explain命令查看SQL的執(zhí)行計(jì)劃，關(guān)注type（最好為const，最差為ALL）、key（使用的索引）、rows（掃描的行數(shù)）、Extra（是否Usingfilesort/Usingtemporary）；3.優(yōu)化索引：添加缺失的索引（如對(duì)where/orderby/groupby字段創(chuàng)建索引），避免索引失效（如避免在索引字段使用函數(shù)、類型轉(zhuǎn)換）；4.優(yōu)化查詢邏輯：減少select（使用覆蓋索引），拆分復(fù)雜查詢（如將多表join拆分為單表查詢+內(nèi)存組裝），避免子查詢（改用join或臨時(shí)表）；5.分頁優(yōu)化：大數(shù)據(jù)量分頁（如limit100000,10）時(shí)，使用覆蓋索引+子查詢（selectfromuserwhereid>(selectidfromuserlimit99990,1)limit10）避免全表掃描；6.數(shù)據(jù)庫(kù)層面優(yōu)化：調(diào)整innodb_buffer_pool_size（增大緩存池），啟用查詢緩存（MySQL8.0已廢棄），升級(jí)硬件（如SSD提升I/O速度）。Java線程池的核心參數(shù)有哪些？如何合理配置？核心參數(shù)：1.corePoolSize：核心線程數(shù)，線程池長(zhǎng)期保留的線程數(shù)；2.maximumPoolSize：最大線程數(shù)，線程池允許的最大線程數(shù)；3.keepAliveTime：非核心線程的空閑存活時(shí)間；4.unit：時(shí)間單位；5.workQueue：任務(wù)隊(duì)列（ArrayBlockingQueue、LinkedBlockingQueue、SynchronousQueue等）；6.threadFactory：線程工廠（用于設(shè)置線程名稱、優(yōu)先級(jí)）；7.handler：拒絕策略（AbortPolicy、CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy）。配置策略：1.CPU密集型任務(wù)（如計(jì)算、加密）：corePoolSize=CPU核心數(shù)+1（避免線程切換開銷）；2.I/O密集型任務(wù)（如數(shù)據(jù)庫(kù)查詢、網(wǎng)絡(luò)請(qǐng)求）：corePoolSize=CPU核心數(shù)×2（I/O等待時(shí)線程空閑，需更多線程利用CPU）；3.任務(wù)隊(duì)列：短耗時(shí)任務(wù)用SynchronousQueue（無緩沖，直接提交給線程），長(zhǎng)耗時(shí)任務(wù)用LinkedBlockingQueue（避免任務(wù)堆積）；4.拒絕策略：關(guān)鍵業(yè)務(wù)用AbortPolicy（拋出異常提醒），非關(guān)鍵業(yè)務(wù)用DiscardOldestPolicy（丟棄舊任務(wù)）。例如，處理用戶訂單的線程池，corePoolSize=8（4核CPU×2），maximumPoolSize=16，workQueue=LinkedBlockingQueue(1000)，handler=CallerRunsPolicy（讓調(diào)用線程處理，降低提交速度）。Redis的過期鍵刪除策略和內(nèi)存淘汰機(jī)制有何區(qū)別？過期鍵刪除策略處理已過期的鍵，內(nèi)存淘汰機(jī)制處理內(nèi)存不足時(shí)的鍵刪除。1.過期鍵刪除策略：定時(shí)刪除：設(shè)置定時(shí)器在鍵過期時(shí)立即刪除（CPU消耗大）；惰性刪除：訪問鍵時(shí)檢查是否過期，過期則刪除（內(nèi)存占用高）；定期刪除：每隔一段時(shí)間掃描部分鍵，刪除過期鍵（Redis采用惰性刪除+定期刪除結(jié)合）。2.內(nèi)存淘汰機(jī)制：當(dāng)內(nèi)存達(dá)到maxmemory時(shí)，按策略刪除鍵，Redis支持的策略有：noeviction（拒絕寫操作）；allkeys-lru（刪除最近最少使用的鍵）；allkeys-random（隨機(jī)刪除鍵）；volatile-lru（僅刪除設(shè)置過期時(shí)間的最近最少使用鍵）；volatile-random（僅刪除設(shè)置過期時(shí)間的隨機(jī)鍵）；volatile-ttl（僅刪除設(shè)置過期時(shí)間且剩余時(shí)間最短的鍵）。生產(chǎn)環(huán)境推薦allkeys-lru（適用于緩存場(chǎng)景）或volatile-lru（適用于混合存儲(chǔ)場(chǎng)景）。如何設(shè)計(jì)一個(gè)高可用的分布式系統(tǒng)？關(guān)鍵措施包括：1.冗余部署：核心服務(wù)多實(shí)例部署（如Nginx負(fù)載均衡、K8s的ReplicaSet），避免單點(diǎn)故障；2.故障檢測(cè)：通過心跳機(jī)制（如ZooKeeper的臨時(shí)節(jié)點(diǎn)、Eureka的心跳續(xù)約）或健康檢查（如SpringBootActuator的/health接口）檢測(cè)節(jié)點(diǎn)狀態(tài)，自動(dòng)隔離故障節(jié)點(diǎn)；3.自動(dòng)恢復(fù)：使用K8s的自愈機(jī)制（Pod失敗時(shí)自動(dòng)重啟）、Hystrix的熔斷（服務(wù)不可用時(shí)快速失敗，一段時(shí)間后嘗試恢復(fù)）；4.數(shù)據(jù)一致性：通過分布式事務(wù)（TCC、事務(wù)補(bǔ)償）、最終一致性（消息隊(duì)列異步同步）保證數(shù)據(jù)一致；5.流量治理：通過限流（Sentinel）、降級(jí)（關(guān)閉非核心功能）、負(fù)載均衡（Nginx、LVS）應(yīng)對(duì)流量突增；6.異地多活：關(guān)鍵服務(wù)部署在多個(gè)機(jī)房（如阿里云的多可用區(qū)），通過DNS解析或GSLB（全局負(fù)載均衡）將流量導(dǎo)向健康機(jī)房，避免區(qū)域性故障。SpringAOP的實(shí)現(xiàn)原理是什么？如何處理循環(huán)依賴中的AOP代理？SpringAOP基于動(dòng)態(tài)代理實(shí)現(xiàn)，有兩種方式：1.JDK動(dòng)態(tài)代理：為實(shí)現(xiàn)接口的類提供代理（Proxy.newProxyInstance），通過InvocationHandler攔截方法調(diào)用；2.CGLIB代理：為未實(shí)現(xiàn)接口的類提供代理（通過ASM修改字節(jié)碼），通過MethodInterceptor攔截方法調(diào)用。AOP處理循環(huán)依賴時(shí)，三級(jí)緩存中的ObjectFactory會(huì)提前提供代理對(duì)象（若需要AOP），并存入二級(jí)緩存earlySingletonObjects。例如，A依賴B，A需要被代理，創(chuàng)建A時(shí)實(shí)例化后提供ObjectFactory（返回A的代理），B創(chuàng)建時(shí)獲取A的代理（從三級(jí)緩存的工廠提供），A初始化完成后，最終的代理對(duì)象會(huì)替換二級(jí)緩存中的早期代理（實(shí)際為同一對(duì)象，因代理是單例），避免循環(huán)依賴導(dǎo)致的代理不一致問題。MySQL的主從復(fù)制是如何實(shí)現(xiàn)的？常見的復(fù)制延遲問題如何解決？主從復(fù)制通過二進(jìn)制日志（Binlog）實(shí)現(xiàn)，步驟：1.主庫(kù)將寫操作記錄到Binlog（開啟binlog，binlog_format=ROW/STATEMENT/MIXED）；2.從庫(kù)的I/O線程連接主庫(kù)，請(qǐng)求Binlog更新，主庫(kù)的BinlogDump線程發(fā)送Binlog事件；3.從庫(kù)將接收的Binlog事件寫入中繼日志（RelayLog）；4.從庫(kù)的SQL線程讀取RelayLog，執(zhí)行其中的事件，同步主庫(kù)數(shù)據(jù)。復(fù)制延遲常見原因：主庫(kù)寫壓力大（Binlog提供快于從庫(kù)執(zhí)行）、從庫(kù)硬件性能差（CPU/磁盤慢）、大事務(wù)（從庫(kù)需執(zhí)行長(zhǎng)時(shí)間的事務(wù)）。解決方法：1.優(yōu)化主庫(kù)SQL（減少大事務(wù)，拆分復(fù)雜操作）；2.升級(jí)從庫(kù)硬件（使用SSD、增加CPU核心）；3.并行復(fù)制（MySQL5.7+的writeset并行復(fù)制，按庫(kù)/表/行并行執(zhí)行RelayLog事件）；4.讀寫分離時(shí)，對(duì)實(shí)時(shí)性要求高的讀操作直接訪問主庫(kù)；5.調(diào)整從庫(kù)參數(shù)（如innodb_flush_log_at_trx_commit=2，減少磁盤I/O）。如何實(shí)現(xiàn)接口的熔斷和降級(jí)？熔斷（CircuitBreaker）指當(dāng)服務(wù)失敗率超過閾值時(shí)，自動(dòng)拒絕后續(xù)請(qǐng)求，一段時(shí)間后嘗試恢復(fù)；降級(jí)（Degradation）指在系統(tǒng)壓力大時(shí)，關(guān)閉非核心功能，保證核心功能可用。實(shí)現(xiàn)工具：Hystrix（已停止維護(hù)）、Sentinel、Resilience4J。以Sentinel為例：1.