阿里菜鳥網絡一面

我的技術博客:www.zhenganwen.topjava

上午坐在圖書館前草坪的椅子上看《Netty權威指南》,差很少到了飯點,正準備起身去食堂吃飯,這時迎來一個突如其來的電話,上面顯示:「浙江-杭州」。(所以前並未約面試,不知這就是阿里巴巴菜鳥網絡的面試電話)mysql

  • 先介紹一下你本身吧
    • 略……
  • 你作的項目中,你以爲最有挑戰的一件事是什麼事啊?
    • 我以爲最有挑戰的是一次商品搜索功能的實現,當時原本是準備用Solr作的,可是當時的項目用的是SpringBoot,以前學Solr的時候是用Solr是和Spring整合,我用SpringBoot集成Solr發現版本差別很大,API也不用了,而後Solr初始配置繁瑣,當時就想換一個搜索框架。而後我據說Elasticsearch挺好用的,因而就從0開始研究它的API,最後實現了商品搜索必需的一些功能,如關鍵字檢索、結果高亮、聚合等。雖然我對ES的底層瞭解很少,但這一次是我獨立對一個陌生框架的學習並實現了須要的基本功能。
  • 就是你以爲用ES替換Solr比較有技術含量是吧?
    • 不是的。只是說有這麼一個難題吧,如今Solr沒辦法用了,要逃離溫馨區接觸一個陌生的ES,從無到有的將商品檢索功能實現,不說有多麼高性能,起碼實現了基本的功能。
  • ES的源碼,你有看過嗎?
    • emmm……,沒有。

在本身的簡歷中寫一些不知底層原理沒有讀過源碼的花裏胡哨的框架技術等於給本身埋坑面試

  • Java的源碼有沒有看過?redis

    • Java的源碼,多線程的看過一些,集合的也看過一些。
  • 那你給我講一下ConcurrentHashMapHashMap的區別。算法

    • ConcurrentHashMap的核心思想就是下降鎖粒度以提升併發性能。HashMap不是線程安全的,HashTable雖然是線程安全的,但其相對於HashMap來講,只是簡單地將每一個訪問集合的方法都加了一個synchronized關鍵字,也就是說任何訪問集合的線程都須要先獲取集合對象對應的鎖,這樣的話同一時刻只能有一個線程操做Map,併發性能弱,若是併發線程較多還會引發屢次上下文切換。而ConcurrentHashMap採用鎖分段的技術,默認在集合內部維護了16把鎖,每幾個Bucket做爲一個組,每一個組對應一把鎖,這樣最多就能支持16個線程同時訪問Map了。
  • 每一個Bucket對應一把鎖是吧?sql

    • 我記得好像是一把鎖對應幾個Bucket
  • HashMap在併發場景下,它不安全的點是哪裏?緩存

    • 就是可能會形成Bucket中的鏈表造成環形鏈表,致使後續的Map.get操做可能會形成無限循環,致使CPU的100%佔用。
  • 仔細說一下造成環形鏈表的過程。(解析參考安全

    • HashMap在元素個數到達閥值(容量x複雜引子)後會進行擴容,首先新建一個擴容後的空Map,而後遍歷Entry將其Rehash到新的Map上。Rehash(對應方法transfer)中有一行代碼是Entry next = e.next,其中e是當前遍歷到的Entry。假設如今有兩個線程A、B都在Rehash,B遍歷到Entry3剛獲得next(好比Entry2)時就消耗完時間片被掛起了,此時對於B來講e=Entry3,next=Entry2。這時A搶到CPU執行權,暢通無阻的執行完了Rehash操做:網絡

    • 而後B恢復執行,將Entry3從新哈希到了本身新Map的第3個桶上,而且e=next指向了Entry2,next=e.next指向了Entry3,因而將Entry2從新哈希到本身新Map的第3個同上,發現桶裏已有Entry3,因而將Entry3的next指針指向Entry2,這在A中的新Map上表現爲Entry2和Entry3造成了環形鏈表:數據結構

      其實我當時答得並不許確……

  • 桶裏底層放的數據結構是怎樣的?

    • 低版本的放的是鏈表,後來爲了不哈希衝突帶來的時間複雜度線性增加改成了紅黑樹。
  • ConcurrentHashMap和HashMap,他們除了一個線程安全一個線程不安全,還有其餘的區別嗎?

    • emmm……一下想不起來
  • 看到你項目中寫使用消息中間件實現短信發送功能的請求方和發送短信方之間的解耦,用的是什麼中間件?

    • activemq
  • 若是你發短信,發送失敗了怎麼辦?

    • 這個沒有考慮過
  • 那叫你優化的話,你怎麼優化?

    • 我以爲發送短信方不管是否發送成功都要給請求方一個ack,也就是要有一個反饋,讓請求方知道。
  • 因此,具體該怎麼作?請求方將號碼給到mq,短信發送方怎麼作?發送成功了怎麼作、失敗了又怎麼作?ack怎麼作?一套流程,你說個一、二、三、四、5步出來。

    • 徹底懵了……跟着黑馬項目視頻作的項目,工程能力是真的差!根本沒有思考業務如何實現、爲什麼這樣實現、這樣實現後會不會有什麼問題、有問題又該如何解決。

不要以爲項目用了不少框架就很厲害,若是面試官問你是否看過源碼、如何排除故障、如何解決故障你卻答不上來,那這個項目就是在給本身埋坑。簡歷上的項目最好寫那種有一些本身思考在裏面的,而不是培訓機構那些填鴨式的項目。

  • 好的,沒事,說不上來也不要緊。(面試官人很好,屢次鼓勵和引導我,感謝:))
  • 什麼是雙親委派機制?
    • 是JDK類加載的一個模型。JDK有三個類加載器:用來加載核心類庫的引導類加載器、用來加載擴展類庫的擴展類加載器、用來加載自定義類的應用程序類加載器。雙親委派機制就是當JVM收到一個類加載請求時,不會直接讓當前類的類加載器加載該類,而是將請求委派給其上層類加載器,直到請求到達最頂端的引導類加載器,而後逐層向下遞歸加載該類,某一層找到了該類則直接加載並返回,不然若是到了當前類的類加載器還找不到,就會拋出沒有該類的異常。
  • 雙親委派有什麼好處?
    • 避免自定義的類覆蓋核心類庫的行爲。好比咱們本身也能夠定義一個java.lang.Object,若是沒有雙親委派機制,那麼java.lang.Object的類加載請求就可能被應用程序類加載器受理,它則會加載咱們自定義的java.lang.Object從而屏蔽了核心類庫的Object,這樣的話會損害JVM
  • 有幾種狀況會致使Full GC
    • 第一就是分配擔保時擔保失敗。在進行Minor GC時,新生代若是採用複製算法會將Eden和From Survivor中的存活對象複製到To Survivor,To Survivor空間不夠時會讓老年代進行分配擔保,一種極端的狀況就是新生代的對象所有存活,意味着會有不少對象進入老年代,若是這時老年代沒有足夠的可用空間,將致使Full GC
  • 嗯,你說的這是老年代空間不足會致使Full GC,還有其餘狀況嗎?
    • emmm……一時想不起來了
  • synchronized修飾一個類,那麼是否是這個類全部的方法都會加鎖?
    • synchronized的語法規則是隻能修飾方法和代碼塊
  • synchronized修飾靜態方法和實例方法有什麼區別?
    • 一個鎖定的是當前類的Class對象,一個鎖的是當前this對象
  • 那你給我講一下synchronized鎖的膨脹過程是怎樣的?
    • 您指的是偏向鎖、輕量級鎖和重量級鎖嗎?就是若是臨界區只有一個線程訪問,這時會將鎖對象的Mark Word中的偏向線程ID指向該線程,此後該線程進入臨界區將省去鎖獲取-釋放,畢竟鎖獲取-釋放是有開銷的。可是若是訪問臨界區的線程變多了,這時撤銷偏向和重置偏向會有必定的開銷,於是膨脹成輕量級鎖,思路是會在線程的棧中存一份鎖對象的Mark Word副本,稱之爲Displaced Mark Word,並該內存的指針存入鎖對象的Mark Word。每一個線程在獲取鎖的時候都須要CAS替換該指針,使其指向本身棧中的Displaced Mark Word。CAS替換失敗則說明併發程度較高,膨脹成重量級鎖,具備排他性。
  • CAS有什麼缺點嘛?
    • CPU開銷較大,由於自旋會一直佔用CPU,若是CAS一直更新不成功那麼就會一直佔用CPU。
  • 還有嗎?
    • emm……想不起來。(ABA問題啊,當時緊張沒想到……)
  • 什麼是彙集索引,什麼是非彙集索引?
    • 是指BTree和B+Tree嗎?
  • 不是,你說的只是索引的實現方式
    • emm不太清楚,應該是索引關鍵之和對應的記錄不放在一塊兒吧
  • 我如今有一張表,裏面有ABC三個字段,有一個ABC三列聯合索引,根據AB兩個字段去查可否利用索引?
    • 不能,由於複合索引只對第一個聲明的字段有效
    • 哦,不對,能夠利用索引。由於索引是先按A有序而後在按B有序最後再按C有序的。根據AB兩個字段查,會在總體按A有序的狀況下快速定位A條件的對應區間,而後在這個區間中A平等B有序又能夠快速定位B條件對應的區間。
  • DB的事務怎麼實現的,你有了解嗎?
    • 不太瞭解……
  • MySQL的主從同步怎麼作的
    • 讀寫分離、數據源動態切換。(錯了,應該是在master執行的每一個sql語句都會被記錄在日誌中發往slave執行)
  • 系統間解耦,不用MQ,還有其餘方式嗎
    • 遠程服務調用吧,如dubbo或者是Http
  • 那你這樣就沒有解耦了,遠程調用時同步的
    • 不太能想出來
  • 那我提醒你一下,中間件是一個獨立的系統,你要確保有一個獨立的數據源在那就好了
    • redis好像能夠吧
  • 可是redis是緩存啊,不穩定,你爲何不直接說mysql、db就能夠了
  • 面試大概到這裏就能夠了,你有什麼想問個人?
    • 我還有下次面試的機會嗎?
  • 這須要等評估在作決定,有第二面的話會在一個星期內聯繫你,過了一個星期沒消息的話就沒過。
    • 您能對我這次面試的表現提些建議嗎?
  • 系統中用到的東西,底層的實現原理,該如何優化,爲何要優化,這些都要搞清楚,否則一問你項目就答不上來的話不太好,實現邏輯要搞清楚。
    • 好,謝謝老師
相關文章
相關標籤/搜索