天天看點

2020年底兩個月面試了一些網際網路java職位

某司:

  1. 如何提高應單率~某個業務問題
  2. MySQL存儲引擎及差異,說了myisam的表行數沒啥用,因為業務中很少count*并且沒有where條件的情況
  3. 連接配接有心跳,設計一種資料結構管理他們,快速發現逾時等,按心跳時間戳排序,堆結構
  4. 講項目和業務中間穿插各種奇怪的場景問題
  5. 怎麼了解ioc,rd定義建立方式以及依賴,生成模闆,把建立以及初始化和依賴管理等等動作交給spring,是以将對象的部分控制權交給spring
  6. es的索引結構,是怎麼根據一個值快速找到文檔的 (反向索引,沒啥說的)
  7. pxc原理,為啥要用,和主從比較的優缺點(pxc高可用,強一緻性。DB是業務的最後一道防線(其實最底層的防線是日志),一緻性至關重要)
  8. Redis分布式鎖的使用,以及它所存在的問題,需不需要規避,哪種場景怎麼選(失效問題,誤删問題,主從模式下釋放或加失敗問題)
  9. 為什麼要用es,地理點位及評價
  10. 好多記不清了

某某司:

  1. final關鍵字使用及作用 類 方法 屬性 局部變量
  2. 對象配置設定過程 類加載->逃逸分析->TLAB->eden&from&to->old,另外gc就是由記憶體配置設定引起的
  3. cms流程 初始标記(标記出roots)->并發标記(根據roots向下一層繼續标記)->預處理(記不清了,應該是處理引用變更dirty card)–>最終标記–>并發清除
  4. 線程池 參數,shutdown 會中斷執行中的任務嗎?running的是不會被中斷的,io阻塞的是runnable狀态也不會被中斷.
  5. MySQL需不需要主鍵,為啥需要,為啥一般都是數字 B+樹索引結構,葉子要排序,數字比較快沒有多餘的計算啥的
  6. 事務特性,以及innodb分别怎麼保證 借大佬的話:(一緻性是目标,需要其他的三個性質保證一緻性。隔離性 mvcc, 持久性 redo log, 原子性 redo/undo)
  7. sql優化器 (沒答上來,沒接觸過)
  8. 慢sql優化思路 (explain 檢視執行計劃,合理的使用索引,利用好聯合索引減少回表, join 盡量别要, 無論對将來的大表還是分表, join都不太友好)
  9. 聚簇索引與非聚簇索引 (聚簇主鍵索引檔案即資料檔案,非聚簇索引葉子存的是位址)
  10. 為啥是b+樹 不是b樹和二叉樹 (預讀,4k&16k,磁盤尋址次數)
  11. Redis分布式鎖,為啥用 (互斥場景,判定set是否成功, 不互斥的場景,也可以作标記使用,這種場景也可以不用)
  12. volatile關鍵字 可見性, 程式執行有序(happen-before規則), 禁止重排序
  13. monitor對象有哪些屬性 (隻答了 _owner,等待隊列兩個,其實還有重入次數,還有别的)
  14. 線程的狀态有哪幾種 (NEW,RUNNABLE,WAITING,TIMED_WAITING,BLOCKED,TERMINATED)
  15. 好多記不清了

某某某司

16. 整場都是我在講項目以及業務,以及問題及各種解決方案優劣勢比較

17. 二面也是

某某某某司

18. MySQL事務及索引相關

19. Redis資料類型 結構 以及删除政策

20. 作業系統,select poll epoll

21.網卡收到的資料是怎麼被應用程式感覺到的?(中斷處理例程)

22. url展示詳細過程

某某某某某司:

  1. gc算法 CMS收集原理;
  2. CMS與G1的差別 (處理dirty card不太一樣,cms收集老年代,G1收集整個堆,都是分代算法,都依賴基礎的标記整理,複制,清除);
  3. 對象配置設定過程 ;
  4. jvm運作資料區 ;
  5. 堆正常但是程序經常被kill,啥原因; 我會往直接記憶體(堆外記憶體)上考慮
  6. jvm參數 ; 最大值,新老比例,eden&from&to比例,gc日志
  7. 線程池參數 拒絕政策 ;拒絕, 不處理,。。。。。
  8. 直接記憶體使用場景; 多是io使用
  9. guava記憶體删除政策 ; get的時候會檢查所有過期的key
  10. Future在抛異常的時候isDone傳回的是true嗎,不想用get但是想在任務完成的時候收到通知,怎麼辦 是true,擴充ListenableFuture
  11. MySQL索引結構 與二叉樹對比的優勢 (os的預讀, io次數即磁盤尋址次數)
  12. rpc調用過程 (幾個組成部分 注冊中心 producer consumer. consumer動态代理進行網絡通信,producer使用wrapper生成代碼在優化反射)
  13. Redis叢集方式分片 需要虛拟節點作映射
  14. 靈活的配置設定線程池的兩個size (統計,在coreSize之外的次數, 隊列裡的任務數等,調整coreSize以及maxSize的值,或者 直接走配置中心,手動調整)
  15. 四個Java程序部署在同一台實體機,有一個程序在某段時間進行頻繁的磁盤io,導緻我的應用響應緩慢。 怎麼解決或規避,負載均衡的政策是在哪一端做 (根據響應時間作負載均衡,負載均衡當時答的在用戶端做)
  16. mq基本原理 如何保證資料不丢失,有沒有重複消息 (在保證消息不丢失的情況下,避免不了要重試,重試就與可能受到重複消息,是以需要業務方幂等)
  17. 啥是緩存擊穿,怎麼解決.key不過期,資料更新時主動緩存或者攔截key隻允許一個線程查db
  18. 活動項目怎麼抽象的,補償是怎麼做的; 流程抽象,多活動複用,補償就是重試,有記錄表,資料有狀态,每次重試前先檢查我方以及依賴方的狀态
  19. 分布式鎖以及事務問題
  20. 遇到的線上問題,怎麼排查 (根據鍊路追蹤找問題節點,如果大批量的RT激增,需要看受影響的業務的公共特性,比如DB,緩存等等多數不是因為機器的活某個服務的問題)
  21. 訂單流程的并發怎麼處理,狀态不一緻怎麼處理的(标記狀态,加後續流程攔截,沒有采用簡單的加鎖,1是影響其他業務性能 2是不确定PXC架構是否可以正常加行鎖,目前還在研究中)
  22. 發單政策,輪選
  23. 為啥選擇pxc,強一緻,高可用。db是業務的最後一道防線,db的一緻性至關重要
  24. 如果大量的請求接單,怎麼扛并發業務和技術兩個角度分别準備怎麼做,業務上利用緩沖buffer搶單進池子,大頂堆結構,排序按某些名額打分,達到最大時間限制時,拿出頂部接單,其餘的都傳回失敗

總結:

  1. 八股還是有點用的,明知道會問卻不去了解,隻能說明你态度或者智商或者處事有問題, 吹噓八股無用論的,有種面試都說"沒用,我不答"
  2. 需要平時注意線上各種問題解決方案,以及更優方案,以及方案确定時的考慮,哪怕不是自己發現的,哪怕不是自己解決的,了解并學到别人的思路那就是自己的
  3. 純背八股是不太可取的,随便來倆靈活的問題賊容易被問住
  4. 多思考每一道面試題産生的背景,比如新生代:老年代一般是1:2,那麼為什麼呢,有沒有新生代很大老年代很小的場景
  5. 比如Java記憶體配置設定過程,為什麼需要逃逸分析,為什麼要有tlab
  6. 比如線程池大小為什麼要那樣設定,為什麼要選那樣的隊列
  7. 比如非阻塞io,為什麼需要,誕生的背景,進化曆程,為什麼是select poll epoll這麼個發展曆程
  8. 不管是簡單複雜, 小型或大型, 獨立或合作開發的業務或基礎元件, 肯定有一些亮點在等着你去發現。
  9. 最後深惡痛絕一下, 看代碼先不看有沒有啥高端技術, 有沒有啥模式。隻要沒有【注釋】就都是 【屎】。

所有

算法題:反轉單連結清單 從第m開始反轉n個節點

算法題:自己實作bitmap

算法題:無鎖計數器,按key計數

算法題:從一個數字組成的集合中找出出現次數最多的1個或幾個數,要求循環盡可能的少,不考慮空間

算法題: 歸并排序

算法題: 力扣42

算法題: 找多叉樹的公共節點

算法題: 找出二叉樹中和為給定值的路徑

算法題: 力扣41

算法題: 快速排序

算法題: 手寫lru

算法題: 二叉樹右視圖

算法題: 雙端棧