某司:
- 如何提高應單率~某個業務問題
- MySQL存儲引擎及差異,說了myisam的表行數沒啥用,因為業務中很少count*并且沒有where條件的情況
- 連接配接有心跳,設計一種資料結構管理他們,快速發現逾時等,按心跳時間戳排序,堆結構
- 講項目和業務中間穿插各種奇怪的場景問題
- 怎麼了解ioc,rd定義建立方式以及依賴,生成模闆,把建立以及初始化和依賴管理等等動作交給spring,是以将對象的部分控制權交給spring
- es的索引結構,是怎麼根據一個值快速找到文檔的 (反向索引,沒啥說的)
- pxc原理,為啥要用,和主從比較的優缺點(pxc高可用,強一緻性。DB是業務的最後一道防線(其實最底層的防線是日志),一緻性至關重要)
- Redis分布式鎖的使用,以及它所存在的問題,需不需要規避,哪種場景怎麼選(失效問題,誤删問題,主從模式下釋放或加失敗問題)
- 為什麼要用es,地理點位及評價
- 好多記不清了
某某司:
- final關鍵字使用及作用 類 方法 屬性 局部變量
- 對象配置設定過程 類加載->逃逸分析->TLAB->eden&from&to->old,另外gc就是由記憶體配置設定引起的
- cms流程 初始标記(标記出roots)->并發标記(根據roots向下一層繼續标記)->預處理(記不清了,應該是處理引用變更dirty card)–>最終标記–>并發清除
- 線程池 參數,shutdown 會中斷執行中的任務嗎?running的是不會被中斷的,io阻塞的是runnable狀态也不會被中斷.
- MySQL需不需要主鍵,為啥需要,為啥一般都是數字 B+樹索引結構,葉子要排序,數字比較快沒有多餘的計算啥的
- 事務特性,以及innodb分别怎麼保證 借大佬的話:(一緻性是目标,需要其他的三個性質保證一緻性。隔離性 mvcc, 持久性 redo log, 原子性 redo/undo)
- sql優化器 (沒答上來,沒接觸過)
- 慢sql優化思路 (explain 檢視執行計劃,合理的使用索引,利用好聯合索引減少回表, join 盡量别要, 無論對将來的大表還是分表, join都不太友好)
- 聚簇索引與非聚簇索引 (聚簇主鍵索引檔案即資料檔案,非聚簇索引葉子存的是位址)
- 為啥是b+樹 不是b樹和二叉樹 (預讀,4k&16k,磁盤尋址次數)
- Redis分布式鎖,為啥用 (互斥場景,判定set是否成功, 不互斥的場景,也可以作标記使用,這種場景也可以不用)
- volatile關鍵字 可見性, 程式執行有序(happen-before規則), 禁止重排序
- monitor對象有哪些屬性 (隻答了 _owner,等待隊列兩個,其實還有重入次數,還有别的)
- 線程的狀态有哪幾種 (NEW,RUNNABLE,WAITING,TIMED_WAITING,BLOCKED,TERMINATED)
- 好多記不清了
某某某司
16. 整場都是我在講項目以及業務,以及問題及各種解決方案優劣勢比較
17. 二面也是
某某某某司
18. MySQL事務及索引相關
19. Redis資料類型 結構 以及删除政策
20. 作業系統,select poll epoll
21.網卡收到的資料是怎麼被應用程式感覺到的?(中斷處理例程)
22. url展示詳細過程
某某某某某司:
- gc算法 CMS收集原理;
- CMS與G1的差別 (處理dirty card不太一樣,cms收集老年代,G1收集整個堆,都是分代算法,都依賴基礎的标記整理,複制,清除);
- 對象配置設定過程 ;
- jvm運作資料區 ;
- 堆正常但是程序經常被kill,啥原因; 我會往直接記憶體(堆外記憶體)上考慮
- jvm參數 ; 最大值,新老比例,eden&from&to比例,gc日志
- 線程池參數 拒絕政策 ;拒絕, 不處理,。。。。。
- 直接記憶體使用場景; 多是io使用
- guava記憶體删除政策 ; get的時候會檢查所有過期的key
- Future在抛異常的時候isDone傳回的是true嗎,不想用get但是想在任務完成的時候收到通知,怎麼辦 是true,擴充ListenableFuture
- MySQL索引結構 與二叉樹對比的優勢 (os的預讀, io次數即磁盤尋址次數)
- rpc調用過程 (幾個組成部分 注冊中心 producer consumer. consumer動态代理進行網絡通信,producer使用wrapper生成代碼在優化反射)
- Redis叢集方式分片 需要虛拟節點作映射
- 靈活的配置設定線程池的兩個size (統計,在coreSize之外的次數, 隊列裡的任務數等,調整coreSize以及maxSize的值,或者 直接走配置中心,手動調整)
- 四個Java程序部署在同一台實體機,有一個程序在某段時間進行頻繁的磁盤io,導緻我的應用響應緩慢。 怎麼解決或規避,負載均衡的政策是在哪一端做 (根據響應時間作負載均衡,負載均衡當時答的在用戶端做)
- mq基本原理 如何保證資料不丢失,有沒有重複消息 (在保證消息不丢失的情況下,避免不了要重試,重試就與可能受到重複消息,是以需要業務方幂等)
- 啥是緩存擊穿,怎麼解決.key不過期,資料更新時主動緩存或者攔截key隻允許一個線程查db
- 活動項目怎麼抽象的,補償是怎麼做的; 流程抽象,多活動複用,補償就是重試,有記錄表,資料有狀态,每次重試前先檢查我方以及依賴方的狀态
- 分布式鎖以及事務問題
- 遇到的線上問題,怎麼排查 (根據鍊路追蹤找問題節點,如果大批量的RT激增,需要看受影響的業務的公共特性,比如DB,緩存等等多數不是因為機器的活某個服務的問題)
- 訂單流程的并發怎麼處理,狀态不一緻怎麼處理的(标記狀态,加後續流程攔截,沒有采用簡單的加鎖,1是影響其他業務性能 2是不确定PXC架構是否可以正常加行鎖,目前還在研究中)
- 發單政策,輪選
- 為啥選擇pxc,強一緻,高可用。db是業務的最後一道防線,db的一緻性至關重要
- 如果大量的請求接單,怎麼扛并發業務和技術兩個角度分别準備怎麼做,業務上利用緩沖buffer搶單進池子,大頂堆結構,排序按某些名額打分,達到最大時間限制時,拿出頂部接單,其餘的都傳回失敗
總結:
- 八股還是有點用的,明知道會問卻不去了解,隻能說明你态度或者智商或者處事有問題, 吹噓八股無用論的,有種面試都說"沒用,我不答"
- 需要平時注意線上各種問題解決方案,以及更優方案,以及方案确定時的考慮,哪怕不是自己發現的,哪怕不是自己解決的,了解并學到别人的思路那就是自己的
- 純背八股是不太可取的,随便來倆靈活的問題賊容易被問住
- 多思考每一道面試題産生的背景,比如新生代:老年代一般是1:2,那麼為什麼呢,有沒有新生代很大老年代很小的場景
- 比如Java記憶體配置設定過程,為什麼需要逃逸分析,為什麼要有tlab
- 比如線程池大小為什麼要那樣設定,為什麼要選那樣的隊列
- 比如非阻塞io,為什麼需要,誕生的背景,進化曆程,為什麼是select poll epoll這麼個發展曆程
- 不管是簡單複雜, 小型或大型, 獨立或合作開發的業務或基礎元件, 肯定有一些亮點在等着你去發現。
- 最後深惡痛絕一下, 看代碼先不看有沒有啥高端技術, 有沒有啥模式。隻要沒有【注釋】就都是 【屎】。
所有
算法題:反轉單連結清單 從第m開始反轉n個節點
算法題:自己實作bitmap
算法題:無鎖計數器,按key計數
算法題:從一個數字組成的集合中找出出現次數最多的1個或幾個數,要求循環盡可能的少,不考慮空間
算法題: 歸并排序
算法題: 力扣42
算法題: 找多叉樹的公共節點
算法題: 找出二叉樹中和為給定值的路徑
算法題: 力扣41
算法題: 快速排序
算法題: 手寫lru
算法題: 二叉樹右視圖
算法題: 雙端棧