1. ?分布式訂單ID生成? 短時間高并發(fā)下如何保證唯一性？我先回答了雪花-like, 上段實習中, 我們項目的全局GUID生成器是我寫的, 考慮了短時間內大量產生的情況, 向后借用, 未考慮時鐘回撥然后想起來當時和leader討論,  單獨的GUID生成中心, 分批向各個ds批發(fā)號段.. 或者是用tacplus的自增id, 但是這樣效率太低2. ?CPU 性能瓶頸分析使用 prof 工具監(jiān)視熱點函數(shù)的性能消耗3. 上段實習工作內容? 難點?    背包/倉庫/道具 ?重構模塊追問?：    在兩周內重構1萬行代碼，如何保證代碼質量？是否引入單元測試或自動化驗證？    10天完成15天任務，如何協(xié)調開發(fā)與測試資源？是否犧牲技術債？4. 問了一點網(wǎng)絡: 網(wǎng)絡通信與實時系統(tǒng)視頻會議與代碼共享的鏈路設計追問?：解釋從你的設備到面試官屏幕的完整網(wǎng)絡路徑（如NAT穿透、協(xié)議選擇）5. 游戲服務器同步機制? 和互聯(lián)網(wǎng)開發(fā)的區(qū)別服務器作為權威狀態(tài)源，定期向客戶端廣播游戲世界的完整或增量狀態(tài)（如玩家位置、血量）電商無狀態(tài)服務可通過REST API+RPC橫向擴展，而游戲服務器需維護長連接和會話狀態(tài)。6. 系統(tǒng)設計 分布式事務與最終一致性?游戲道具交易涉及多個系統(tǒng)（背包、倉庫、郵件），如何設計分布式事務？對比電商訂單支付+庫存扣減。?回答方向?：?Saga模式?：將事務拆分為多個可補償步驟（如“扣道具-發(fā)郵件-記錄日志”，失敗則回滾）。對比：電商更傾向異步消息隊列?（如Kafka）實現(xiàn)最終一致性。7. 游戲服務器宕機后如何快速恢復玩家狀態(tài)？電商系統(tǒng)如何設計類似容災機制？定時落DB+游戲整體運行在共享內存, 方便resume7. 游戲后端請求鏈路分析采用自定義的可靠UDP協(xié)議?（KCP），平衡延遲與可靠性. 玩家操作（如移動、技能釋放）需攜帶時間戳和操作序列號，用于服務端驗證順序, 請求直達, 客戶端直接和服務器感覺面試內容很不"八股", 答得稀里糊涂的, 上面的順序不是面試提問順序, 想起來什么說什么, 大家做個參考

萬萬沒想到系列，本來最不抱希望的反而一周速通了。分享個Timeline，后續(xù)再補充面經(jīng)。4.14 一面4.16 二面4.17 三面4.21 hr面21 號當晚oc24號帶薪offer郵件開得挺滿意的，接了，春招結束，不等騰訊和理想了(理想的池子都要泡發(fā)了)再見了團子，感謝秋招收留，以后點外賣只用你

字節(jié) 抖音 一面掛3.4投遞很快就約面了，沒有筆試，我選的3.18的3.18 一面面試官很年輕感覺比我就大一兩屆，一上來就散發(fā)著一種很拽的氣質，說話感覺是在教育我，有點不適數(shù)組和鏈表訪問的時間復雜度數(shù)組訪問為什么快為什么有了頭地址和長度就知道在哪為什么知道地址就知道數(shù)據(jù)，難道數(shù)據(jù)都存在地址里嗎我有點沒聽懂他的意思，最后他說你應該去了解虛擬內存和物理內存，我才明白他想問啥，我說我知道這個，他不想聽了直接打斷了我問下一個limit10000 10優(yōu)化，我說了個大概，他繼續(xù)往深層問，就沒回答上來了手撕：hot100 2 兩數(shù)相加 秒了最后讓他評價一下 說我作為應屆生應該要有自己的亮點，對于知識應該深層了解3.20 感謝信總結：抖音難度還是比其他的要高的，對比起我同學面的飛書，我覺得飛書的還是很簡單的，八股很基礎，手撕也很常見，只能說選部門的時候還是要慎重

自我介紹 項目java中的線程池？如果要自己設計一個線程池要怎么做？線程池中的隊列是用來保存運行中的線程還是等待中的線程？線程池有哪些拒絕策略？最大核心線程數(shù)是能運行的最多的線程數(shù)嗎？線程池中有些線程在運行，有些線程是阻塞在等待，要對線程進行調度，那么這個調度的過程是阻塞的還是非阻塞的？（沒太理解）要自己設計LRU要怎么做？對于緩存要設置過期時間，過期的緩存要處理，有什么方案嗎？除了自己設計的方案，有了解Redis中的緩存淘汰策略嗎？緩存+數(shù)據(jù)庫的設計模型中，讀寫的過程大概是怎么樣的？數(shù)據(jù)更新的邏輯大概是怎么樣的？緩存與數(shù)據(jù)庫不一致的問題，有什么解法嗎？對于數(shù)據(jù)庫并發(fā)更新的問題，有什么解決方案...