JAVA面試匯總

    1. IOC控制反轉(zhuǎn)的優(yōu)點？
      將對象的創(chuàng)建權(quán)交付于IOC容器進行托管，使得具有如下優(yōu)點
      • a. 統(tǒng)一管理；
      • b. 以工廠模式對用戶提供對象，羅列對象組供用戶進行挑選，使得邏輯更清晰；
      • c. 不需要用戶直接new對象，可以在獲取對象的時候做些額外的操作（getBean()方法進行）;
    1. dubbo 提供者和dubbo的消費者是如何進行通信的，dubbo提供者數(shù)據(jù)變更，消費者如何感知？
      • a. Dubbo啟動時，Consumer和Provider都會把自身的URL格式化為字符串，然后注冊到zookeeper相應(yīng)節(jié)點下，作為一個臨時節(jié)點，當(dāng)連斷開時，節(jié)點被刪除；
      • b. Consumer在啟動時，不僅僅會注冊自身到 …/consumers/目錄下，同時還會訂閱…/providers目錄，實時獲取其上Provider的URL字符串信息。
      • c. Provider和Consumer向Zookeeper注冊臨時節(jié)點，當(dāng)連接斷開時刪除相應(yīng)的注冊節(jié)點。

      • d. Consumer訂閱Providers節(jié)點的子節(jié)點，實時感知Provider的變化情況，實時同步自身的Invoker對象，保證RPC的可用性。


        image.png
    1. CGLIB和JDK提供的InvocationHandler代理對象生成對應(yīng)代理情況是在哪個步驟中完成的？
      CGLIB是在代碼運行時對字節(jié)碼進行修改和動態(tài)生成，繼承子類覆寫目標(biāo)類方法，JDK提供的則需要有接口類作為前提，在運行時動態(tài)生成。

  • 4.JWT如何在token上做對WEB服務(wù)器無狀態(tài)處理？
    JWT的token分為三部分：header、payload、signature，signature對header和payload數(shù)據(jù)進行簽名。

  • 5.1 MYSQL的協(xié)議格式？

總體流程

===========傳輸層協(xié)議================
1. 三次握手建立 TCP 連接。
===========應(yīng)用層協(xié)議================
2. 建立 MySQL 連接，也就是認證階段。
    服務(wù)端 -> 客戶端：發(fā)送握手初始化包 (Handshake Initialization Packet)。
    客戶端 -> 服務(wù)端：發(fā)送驗證包 (Client Authentication Packet)。
    服務(wù)端 -> 客戶端：認證結(jié)果消息。
 
3. 認證通過之后，客戶端開始與服務(wù)端之間交互，也就是命令執(zhí)行階段。
    客戶端 -> 服務(wù)端：發(fā)送命令包 (Command Packet)。
    服務(wù)端 -> 客戶端：發(fā)送回應(yīng)包 (OK Packet, or Error Packet, or Result Set Packet)。
 
4. 斷開 MySQL 連接。
    客戶端 -> 服務(wù)器：發(fā)送退出命令包。
 ==========傳輸層協(xié)議==================
5. 四次握手斷開 TCP 連接

服務(wù)端發(fā)送至客戶端的協(xié)議格式：

image.png

協(xié)議版本號：服務(wù)端所使用的mysql協(xié)議的版本號
服務(wù)器線程ID：服務(wù)端為此客戶端所創(chuàng)建的線程的ID
挑戰(zhàn)隨機數(shù)：MySQL數(shù)據(jù)庫用戶認證采用的是挑戰(zhàn)/應(yīng)答的方式，服務(wù)器生成該挑戰(zhàn)數(shù)并發(fā)送給客戶端，由客戶端進行處理并返回相應(yīng)結(jié)果，然后服務(wù)器檢查是否與預(yù)期的結(jié)果相同，從而完成用戶認證的過程。
服務(wù)器權(quán)能標(biāo)志：用于與客戶端協(xié)商通訊方式

客戶端發(fā)送至服務(wù)器端：

image.png

客戶端權(quán)能標(biāo)志：客戶端收到服務(wù)器發(fā)來的初始化報文后，會對服務(wù)器發(fā)送的權(quán)能標(biāo)志進行修改，保留自身所支持的功能，然后將權(quán)能標(biāo)返回給服務(wù)器，從而保證服務(wù)器與客戶端通訊的兼容性。
消息長度：客戶端發(fā)送請求時所支持的最大消息長度值
字符編碼表示通訊過程中使用的字符編碼，與服務(wù)器在認證報文中發(fā)送的相同
用戶名：客戶端登陸的用戶名
挑戰(zhàn)認證數(shù)據(jù)：客戶端用戶密碼使用服務(wù)器發(fā)送的挑戰(zhàn)隨機數(shù)進行加密后，生成挑戰(zhàn)認證數(shù)據(jù)，返回給服務(wù)器用于服務(wù)端的認證

認證流程：

服務(wù)器發(fā)送隨機字符串 (scramble) 給客戶端。
客戶端作如下計算，然后客戶端將 token 發(fā)送給服務(wù)端。

stage1_hash = SHA1(明文密碼)

token = SHA1(scramble + SHA1(stage1_hash)) XOR stage1_hash

服務(wù)端作如下計算，比對 SHA1(stage1_hash) 和 mysql.user.password 是否相同。

stage1_hash = token XOR SHA1(scramble + mysql.user.password)

  • 5.2 MYSQL的innodb引擎重要的幾個參數(shù)優(yōu)化？
    內(nèi)存優(yōu)化參數(shù)：

    • innodb_buffer_pool_size：主要緩存innodb表的索引，數(shù)據(jù)，插入數(shù)據(jù)時的緩沖，建議設(shè)置成內(nèi)存的60%~70%。
    • innodb_additional_mem_pool_size：存放Innodb的內(nèi)部目錄，這個值不用分配太大，系統(tǒng)可以自動調(diào)。通常設(shè)置16Ｍ夠用了，如果表比較多，可以適當(dāng)?shù)脑龃蟆?br> 日志優(yōu)化參數(shù)
    • innodb_log_file_size：這個值分配的大小和數(shù)據(jù)庫的寫入速度，事務(wù)大小，異常重啟后的恢復(fù)有很大的關(guān)系。一般取256M可以兼顧性能和recovery的速度。
    • innodb_log_buffer_size：事務(wù)在內(nèi)存中的緩沖，也就是日志緩沖區(qū)的大小， 默認設(shè)置即可，具有大量事務(wù)的可以考慮設(shè)置為16M
    • innodb_flush_logs_at_trx_commit：這個參數(shù)只有3個值（0：每秒寫入，1每次提交寫入，2事務(wù)提交會觸發(fā)log buffer 到log file的刷新，但并不會觸發(fā)磁盤文件系統(tǒng)到磁盤的同步。此外，每秒會有一次文件系統(tǒng)到磁盤同步操作）.默認為1，性能更高的可以設(shè)置為0或是2，這樣可以適當(dāng)?shù)臏p少磁盤IO（但會丟失一秒鐘的事務(wù)。），游戲庫的MySQL建議設(shè)置為0。主庫請不要更改了。
      IO分配
    • innodb_file_per_table：使每個Innodb的表，有自已獨立的表空間。如刪除文件后可以回收那部分空間。默認是關(guān)閉的，建議打開（innodb_file_per_table=1）
    • innodb_open_files：限制Innodb能打開的表的數(shù)據(jù)。
    • innodb_data_home_dir：放置表空間數(shù)據(jù)的目錄，默認在mysql的數(shù)據(jù)目錄，設(shè)置到和MySQL安裝文件不同的分區(qū)可以提高性能。

  • 6.zookeeper如何保證數(shù)據(jù)一致性？
    Paxos算法（參考后續(xù)文章《Paxos算法》）比較復(fù)雜，為了簡化實現(xiàn)，Zookeeper使用了一種叫ZAB（ZooKeeper Atomic
    Broadcast，ZooKeeper原子消息廣播協(xié)議）的算法協(xié)議?；赯AB算法，Zookeeper集群保證數(shù)據(jù)更新的一致性，并且通過集群方式保證了Zookeeper系統(tǒng)高可用。但是Zookeeper系統(tǒng)中所有服務(wù)器都存儲相同的數(shù)據(jù)，也就是數(shù)據(jù)沒有分片存儲，因此不滿足分區(qū)耐受性。
    因為Zookeeper系統(tǒng)的多臺服務(wù)器存儲相同的數(shù)據(jù)并且每次數(shù)據(jù)更新都要所有服務(wù)器投票表決， 所以和一般的分布式系統(tǒng)相反，Zookeeper集群的性能會隨著服務(wù)器數(shù)量的增加而下降。

  • 7.kafka如何保證數(shù)據(jù)一致性及重試不出現(xiàn)數(shù)據(jù)重復(fù)機制、kafka的partition的幾種優(yōu)點？
    參考后續(xù)文章《kafka基礎(chǔ)原理》

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容