2025年高頻javac面試題及答案Java中String、StringBuilder、StringBuffer的區(qū)別是什么？String是不可變類，底層使用final修飾的char數(shù)組存儲（JDK9后改為byte數(shù)組），每次對String的修改操作都會提供新的String對象，性能較低。StringBuilder和StringBuffer繼承自AbstractStringBuilder，內(nèi)部使用可變的char/byte數(shù)組，支持高效的字符串拼接。StringBuilder是非線程安全的，適用于單線程環(huán)境；StringBuffer通過synchronized修飾方法保證線程安全，適用于多線程環(huán)境。三者性能對比：StringBuilder>StringBuffer>String（頻繁拼接場景）。Java17有哪些重要特性？Java17作為LTS版本，核心特性包括：密封類（sealedclass）限制類的繼承，增強(qiáng)類型安全；模式匹配（PatternMatchingforinstanceof）簡化類型檢查邏輯，如`if(objinstanceofStrings){...}`直接獲取強(qiáng)轉(zhuǎn)后變量；switch表達(dá)式擴(kuò)展，支持模式匹配和更簡潔的語法；VectorAPI（孵化階段）支持SIMD操作提升數(shù)值計算性能；移除實驗性的AOT和JIT編譯器；增強(qiáng)偽隨機(jī)數(shù)提供器（RandomGenerator）提供更靈活的隨機(jī)數(shù)提供方式。談?wù)凧ava的值傳遞和引用傳遞。Java中只有值傳遞。基本數(shù)據(jù)類型傳遞的是值的副本，修改副本不影響原變量；引用數(shù)據(jù)類型傳遞的是對象引用的副本，副本和原引用指向同一對象，因此修改對象內(nèi)容會影響原對象，但重新賦值引用副本不會改變原引用。例如：```javavoidchange(intx){x=10;}//調(diào)用后原int變量不變voidchange(Useruser){user.setName("new");}//原User對象屬性被修改voidchange(Useruser){user=newUser();}//原引用仍指向舊對象```HashMap在JDK1.8中的底層結(jié)構(gòu)和1.7有何不同？JDK1.7的HashMap使用數(shù)組+鏈表結(jié)構(gòu)，哈希沖突時通過頭插法將新節(jié)點插入鏈表頭部；JDK1.8改為數(shù)組+鏈表+紅黑樹結(jié)構(gòu)，當(dāng)鏈表長度≥8且數(shù)組長度≥64時，鏈表轉(zhuǎn)換為紅黑樹（查詢時間復(fù)雜度從O(n)降至O(logn)），當(dāng)紅黑樹節(jié)點數(shù)≤6時退化為鏈表。此外，1.8的擴(kuò)容機(jī)制優(yōu)化為尾插法（避免多線程擴(kuò)容時的循環(huán)鏈表問題），計算哈希值時簡化高位運算（hash=key.hashCode()^(hash>>>16)），擴(kuò)容時節(jié)點索引計算通過`(oldCap&hash)==0`判斷是否需要移動，減少rehash次數(shù)。ConcurrentHashMap如何保證線程安全？JDK1.7和1.8的實現(xiàn)差異？JDK1.7使用分段鎖（Segment），每個Segment繼承ReentrantLock，默認(rèn)16個Segment，支持16個線程并發(fā)寫，鎖粒度為Segment；JDK1.8摒棄分段鎖，采用CAS+synchronized實現(xiàn)，鎖粒度細(xì)化到數(shù)組的單個節(jié)點（Node）。具體操作：put時通過CAS嘗試插入節(jié)點，失敗則使用synchronized鎖定該節(jié)點所在的鏈表/紅黑樹的頭節(jié)點，避免鎖住整個桶。讀操作無需加鎖（通過volatile修飾Node的val和next字段保證可見性）。1.8的優(yōu)化減少了鎖競爭，提升了高并發(fā)場景下的性能。線程的生命周期有哪些狀態(tài)？如何轉(zhuǎn)換？Java線程狀態(tài)定義在Thread.State枚舉中，共6種：NEW：線程創(chuàng)建但未調(diào)用start()RUNNABLE：包括操作系統(tǒng)的運行（running）和就緒（ready）狀態(tài)BLOCKED：等待synchronized鎖時進(jìn)入WAITING：調(diào)用wait()、join()、LockSupport.park()無超時參數(shù)時進(jìn)入TIMED_WAITING：調(diào)用sleep(time)、wait(time)、join(time)、parkNanos()等帶超時參數(shù)的方法時進(jìn)入TERMINATED：線程執(zhí)行完畢或異常終止?fàn)顟B(tài)轉(zhuǎn)換示例：NEW→start()→RUNNABLE；RUNNABLE→獲取不到鎖→BLOCKED；RUNNABLE→調(diào)用wait()→WAITING（其他線程調(diào)用notify()/notifyAll()喚醒）；RUNNABLE→調(diào)用sleep(1000)→TIMED_WAITING（超時后回到RUNNABLE）；所有狀態(tài)最終可能轉(zhuǎn)為TERMINATED。synchronized和ReentrantLock的區(qū)別？核心差異：鎖實現(xiàn)：synchronized是JVM層面的關(guān)鍵字，依賴monitorenter/monitorexit字節(jié)碼，自動釋放鎖；ReentrantLock是JDK層面的類（基于AQS），需手動調(diào)用unlock()釋放。公平性：synchronized默認(rèn)非公平鎖；ReentrantLock可通過構(gòu)造函數(shù)指定公平鎖（FairSync）或非公平鎖（NonfairSync）。條件變量：ReentrantLock支持多個Condition對象（如生產(chǎn)者-消費者模型中區(qū)分不同等待隊列），synchronized只有一個wait/notify隊列?？芍袛嘈裕篟eentrantLock的lockInterruptibly()方法支持線程在等待鎖時被中斷；synchronized無法中斷，只能等待鎖釋放。性能：JDK1.6后synchronized優(yōu)化（偏向鎖、輕量級鎖、鎖消除等），性能與ReentrantLock接近，高競爭場景下ReentrantLock更靈活。JVM的內(nèi)存區(qū)域如何劃分？各區(qū)域的作用及OOM場景？JVM內(nèi)存分為線程共享和線程私有區(qū)域：線程共享：堆（Heap）：存儲對象實例和數(shù)組，是GC的主要區(qū)域。OOM場景：對象數(shù)量過多或大對象無法分配（如無限循環(huán)創(chuàng)建對象，-Xmx設(shè)置過小）。方法區(qū)（MethodArea）：存儲類信息、常量、靜態(tài)變量（JDK7前為永久代，JDK8后改為元空間Metaspace，使用本地內(nèi)存）。OOM場景（元空間）：動態(tài)提供大量類（如CGLIB代理、反射），-XX:MaxMetaspaceSize設(shè)置過小。運行時常量池（RuntimeConstantPool）：方法區(qū)的一部分，存儲編譯期提供的常量和符號引用（JDK7后字符串常量池移至堆）。OOM場景（JDK7前）：大量字符串intern()操作導(dǎo)致永久代溢出。線程私有：程序計數(shù)器（PCRegister）：記錄當(dāng)前線程執(zhí)行的字節(jié)碼行號，無OOM。虛擬機(jī)棧（VMStack）：存儲棧幀（局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口）。OOM場景：線程請求的棧深度超過最大限制（如遞歸無終止條件，-Xss設(shè)置過?。?，拋出StackOverflowError；若允許動態(tài)擴(kuò)展（多數(shù)JVM不支持），擴(kuò)展失敗時拋出OOM。本地方法棧（NativeMethodStack）：為本地方法服務(wù)，HotSpot將其與虛擬機(jī)棧合并，OOM場景同虛擬機(jī)棧。Spring的IOC容器如何解決循環(huán)依賴？Spring通過三級緩存解決單例Bean的循環(huán)依賴：一級緩存（singletonObjects）：存儲已初始化完成的單例Bean。二級緩存（earlySingletonObjects）：存儲已實例化但未初始化完成的早期Bean（用于解決AOP代理的循環(huán)依賴）。三級緩存（singletonFactories）：存儲ObjectFactory工廠，用于提供早期Bean的引用（支持通過后置處理器提供代理對象）。流程示例：A依賴B，B依賴A。1.創(chuàng)建A實例（構(gòu)造器注入完成），將A的ObjectFactory（lambda表達(dá)式：()->getEarlyBeanReference(beanName,mbd,bean)）存入三級緩存。2.A需要注入B，觸發(fā)B的創(chuàng)建流程，B實例化后存入三級緩存。3.B需要注入A，從三級緩存獲取A的ObjectFactory，提供早期A的引用（可能是代理對象），存入二級緩存，并移除三級緩存中的A工廠。4.B完成屬性注入和初始化，存入一級緩存，移除二級緩存中的B。5.A獲取到二級緩存中的B引用，完成屬性注入和初始化，存入一級緩存，移除二級緩存中的A。注意：構(gòu)造器注入的循環(huán)依賴無法解決（實例化階段就需要依賴對象，此時三級緩存尚未提供），原型（prototype）Bean的循環(huán)依賴也無法解決（無緩存機(jī)制）。如何優(yōu)化MySQL的慢查詢？優(yōu)化步驟：1.開啟慢查詢?nèi)罩荆╯low_query_log），記錄執(zhí)行時間超過long_query_time（默認(rèn)10秒）或無索引的查詢（log_queries_not_using_indexes）。2.分析SQL執(zhí)行計劃（EXPLAIN），關(guān)注type（最好為const，最差為ALL）、key（實際使用的索引）、rows（掃描的行數(shù)）、Extra（是否Usingfilesort/Usingtemporary）。3.索引優(yōu)化：為WHERE、JOIN、ORDERBY、GROUPBY中的列添加索引，避免在過濾性差的列（如性別）上建索引。遵循最左匹配原則（聯(lián)合索引按順序使用），避免索引失效（如對索引列使用函數(shù)、類型轉(zhuǎn)換、!=、ISNULL等）。覆蓋索引（索引包含查詢所需的所有列）避免回表，如SELECTid,nameFROMuserWHEREage=20，若索引為(age,name,id)，則可直接從索引獲取數(shù)據(jù)。4.SQL改寫：避免SELECT，只查詢需要的列。拆分復(fù)雜的多表JOIN（超過3張表），減少數(shù)據(jù)量。用IN替代OR（IN可利用索引，OR可能全表掃描）。批量操作替代循環(huán)插入（如INSERTINTOuserVALUES(1),(2),(3)）。5.數(shù)據(jù)庫結(jié)構(gòu)優(yōu)化：垂直拆分（按列拆分）：將大字段（如TEXT）單獨存表，減少主表數(shù)據(jù)量。水平拆分（按行拆分）：通過分庫分表（如按ID取模）分散數(shù)據(jù)，降低單表容量。6.硬件優(yōu)化：增加內(nèi)存（減少磁盤IO）、使用SSD、調(diào)整MySQL配置（如innodb_buffer_pool_size設(shè)置為內(nèi)存的50%-70%）。分布式事務(wù)的常見解決方案有哪些？各自適用場景？1.兩階段提交（2PC）：流程：協(xié)調(diào)者（Coordinator）發(fā)送準(zhǔn)備（Prepare）指令，所有參與者（Participant）準(zhǔn)備事務(wù)并反饋；若全部準(zhǔn)備成功，協(xié)調(diào)者發(fā)送提交（Commit）指令，否則回滾。優(yōu)點：強(qiáng)一致性。缺點：同步阻塞（參與者在準(zhǔn)備階段鎖定資源）、單點故障（協(xié)調(diào)者宕機(jī)導(dǎo)致事務(wù)卡?。?、網(wǎng)絡(luò)問題可能導(dǎo)致數(shù)據(jù)不一致（如部分參與者未收到提交指令）。適用場景：數(shù)據(jù)庫支持（如XA協(xié)議，MySQL的InnoDB支持XA事務(wù)）、低并發(fā)的關(guān)鍵交易場景（如銀行轉(zhuǎn)賬）。2.補(bǔ)償事務(wù)（TCC）：流程：Try（嘗試執(zhí)行業(yè)務(wù)，預(yù)留資源）→Confirm（確認(rèn)提交，使用預(yù)留資源）→Cancel（取消，釋放預(yù)留資源）。優(yōu)點：無長時間資源鎖定，支持跨服務(wù)的事務(wù)。缺點：開發(fā)成本高（需實現(xiàn)三個階段的接口），Confirm/Cancel需冪等（防止重復(fù)調(diào)用）。適用場景：微服務(wù)架構(gòu)中跨服務(wù)的事務(wù)（如電商的下單-扣庫存-減積分）。3.最大努力通知：流程：主業(yè)務(wù)完成后，通過MQ異步通知從業(yè)務(wù)執(zhí)行，若失敗則重試（設(shè)置最大重試次數(shù)），最終達(dá)到一致。優(yōu)點：實現(xiàn)簡單，無鎖資源。缺點：弱一致性（有延遲）。適用場景：對一致性要求不高的場景（如短信通知、郵件提醒）。4.事務(wù)消息（基于可靠消息）：流程：發(fā)送方先發(fā)送半消息（MQ不投遞），執(zhí)行本地事務(wù)，成功則確認(rèn)消息（MQ投遞），失敗則回滾消息；接收方消費消息并執(zhí)行本地事務(wù)，失敗則重試。優(yōu)點：異步解耦，最終一致性。缺點：依賴MQ的可靠性（如RocketMQ支持事務(wù)消息）。適用場景：需要異步通信的分布式系統(tǒng)（如訂單系統(tǒng)通知庫存系統(tǒng)）。如何解決Redis的緩存雪崩、穿透、擊穿問題？緩存雪崩：大量緩存同一時間過期，請求直接打到數(shù)據(jù)庫。解決方案：設(shè)置隨機(jī)過期時間（如基礎(chǔ)時間+隨機(jī)數(shù)），避免集中失效；使用多級緩存（本地緩存+Redis）；數(shù)據(jù)庫層做限流降級（如Hystrix）。緩存穿透：查詢不存在的數(shù)據(jù)（如id=-1），緩存無命中，數(shù)據(jù)庫也無記錄，導(dǎo)致每次請求都查數(shù)據(jù)庫。解決方案：緩存空對象（設(shè)置短過期時間），避免重復(fù)查詢；使用布隆過濾器（BloomFilter）預(yù)處理，過濾不可能存在的key；接口層做參數(shù)校驗（如id必須>0）。緩存擊穿：熱點key過期，大量請求同時訪問該key，直接打到數(shù)據(jù)庫。解決方案：熱點key設(shè)置永不過期（異步更新）；使用互斥鎖（如Redis的setnx），僅允許一個線程更新緩存，其他線程等待；本地緩存緩存熱點數(shù)據(jù)（如GuavaCache）。JDK動態(tài)代理和CGLIB的區(qū)別？實現(xiàn)方式：JDK動態(tài)代理基于接口，通過Proxy類和InvocationHandler提供代理對象（只能代理接口方法）；CGLIB基于ASM字節(jié)碼增強(qiáng)，通過繼承目標(biāo)類提供子類（可代理非final類的非final方法）。性能：JDK1.8后動態(tài)代理性能提升，短生命周期對象JDK更優(yōu)；CGLIB因需要提供子類，初始化時間較長，但對多次調(diào)用的方法性能更優(yōu)。適用場景：目標(biāo)類有接口時用JDK動態(tài)代理（符合面向