學(xué)這個https://interview.huihut.com/#/

---

• this 指針被隱含地聲明為: ClassName *const this，這意味著不能給 this 指針賦值；

---

• 內(nèi)聯(lián)函數(shù)
  • 缺點： inline 函數(shù)無法隨著函數(shù)庫升級而升級。因為在編譯器就編進去了，inline函數(shù)的改變需要重新編譯，不像 non-inline 可以直接鏈接。
  • 虛函數(shù)（virtual）可以是內(nèi)聯(lián)函數(shù)（inline）嗎？一般都說不可以，但是在不表現(xiàn)出多態(tài)時，是有可能被內(nèi)聯(lián)的，比如說直接通過對象調(diào)用，編譯器就可能內(nèi)聯(lián)。

---

• 內(nèi)存屏障：
  • 大多數(shù)現(xiàn)代計算機為了提高性能而采取亂序執(zhí)行，這使得內(nèi)存屏障成為必須。
    語義上，內(nèi)存屏障之前的所有寫操作都要寫入內(nèi)存；內(nèi)存屏障之后的讀操作都可以獲得同步屏障之前的寫操作的結(jié)果。因此，對于敏感的程序塊，寫操作之后、讀操作之前可以插入內(nèi)存屏障。

---

• 不可以同時用const和static修飾成員函數(shù)。

  • C++編譯器在實現(xiàn)const的成員函數(shù)的時候為了確保該函數(shù)不能修改類的實例的狀態(tài)，會在函數(shù)中添加一個隱式的參數(shù)const this*。但當一個成員為static的時候，該函數(shù)是沒有this指針的。也就是說此時const的用法和static是沖突的。
  • 我們也可以這樣理解：兩者的語意是矛盾的。static的作用是表示該函數(shù)只作用在類型的靜態(tài)變量上，與類的實例沒有關(guān)系；而const的作用是確保函數(shù)不能修改類的實例的狀態(tài)，與類型的靜態(tài)變量沒有關(guān)系。因此不能同時用它們。

---

• STL中的sort：
  • STL中的sort()，在數(shù)據(jù)量大時，采用quicksort，分段遞歸排序；一旦分段后的數(shù)量小于某個門限值，改用Insertion sort，避免quicksort深度遞歸帶來的過大的額外負擔，如果遞歸層次過深，還會改用heapsort。

---

• mutable:
  • 使用場景：對可能要發(fā)生變化的成員前，加上存儲描述符mutable。
  • 為什么要有這種去除常量標志的需求？
    • 邏輯常量性：對用戶而言是常量，但在用戶不能訪問的細節(jié)上不是常量。

---

• shared_ptr 初始化
  • 盡量避免使用raw pointer構(gòu)建shared_ptr嗎，使用std::make_shared();
  • std::shared_ptr ptr2(new int());
    • 此方法在堆上創(chuàng)建了兩塊內(nèi)存：1：存儲int。2：控制塊上用于引用計數(shù)的內(nèi)存，管理附加此內(nèi)存的 shared_ptr 對象的計數(shù)，最初計數(shù)將為1。
  • std::shared_ptr ptr = std::make_shared();
    • std::make_shared 一次性為int對象和用于引用計數(shù)的數(shù)據(jù)都分配了內(nèi)存，而new操作符只是為int分配了內(nèi)存。
  • 優(yōu)勢一是減少了內(nèi)存碎片，二是效率高，三是還能用move語義，性能更好。

---

• 范式化設(shè)計優(yōu)缺點:
  • 優(yōu)點: 可以盡量得減少數(shù)據(jù)冗余，使得更新快，體積小
  • 缺點:對于查詢需要多個表進行關(guān)聯(lián)，減少寫得效率增加讀得效率，更難進行索引優(yōu)化
• 反范式化:
  • 優(yōu)點:可以減少表的關(guān)聯(lián)，可以更好得進行索引優(yōu)化
  • 缺點:數(shù)據(jù)冗余以及數(shù)據(jù)異常，數(shù)據(jù)得修改需要更多的成本

---

• mysql 主從復(fù)制+讀寫分離
  • 為了提高數(shù)據(jù)庫的并發(fā)性能。
  • 讀寫分離一般master負責(zé)寫入數(shù)據(jù)，兩臺slave負責(zé)讀取數(shù)據(jù)。
    • 讀寫分離好像不是依賴mysql的設(shè)置，一般是用框架或者自定義邏輯。
  • 讀寫分離后，從機需要同步臟數(shù)據(jù)，一般是 binlog 和 delaylog 的配合完成：
  • 當Master節(jié)點進行insert、update、delete操作時，會按順序?qū)懭氲?strong>binlog中。
  • salve從庫連接master主庫，Master有多少個slave就會創(chuàng)建多少個binlog dump線程。
  • 當Master節(jié)點的binlog發(fā)生變化時，binlog dump 線程會通知所有的salve節(jié)點，并將相應(yīng)的binlog內(nèi)容推送給slave節(jié)點。
  • I/O線程接收到 binlog 內(nèi)容后，將內(nèi)容寫入到本地的 relay-log。
  • SQL線程讀取I/O線程寫入的relay-log，并且根據(jù) relay-log 的內(nèi)容對從數(shù)據(jù)庫做對應(yīng)的操作。

---

• Redis 集群簡介
  • Redis 客戶端可以直接連接任何一節(jié)點獲取集群中的鍵值對。Redis 集群是一個網(wǎng)狀結(jié)構(gòu)，沒有中心節(jié)點的說法，每個節(jié)點都通過 TCP 連接跟其他每個節(jié)點連接。這些 TCP 連接會永久保持。
  • 自動通過hash分割數(shù)據(jù)到不同的節(jié)點上。
  • 集群使用了主從復(fù)制模型，每個主節(jié)點master應(yīng)至少有一個從節(jié)點slave。假設(shè)某個主節(jié)點故障，其所有子節(jié)點會廣播一個數(shù)據(jù)包給其他主節(jié)點來請求選票，一旦某個從節(jié)點收到了大多數(shù)主節(jié)點的回應(yīng)，那么它就贏得了選舉，被推選為主節(jié)點，負責(zé)處理之前舊的主節(jié)點負責(zé)的哈希槽。

---

• 算法題拓展：1~n的數(shù)字，缺兩個數(shù)字：
  • 缺一個數(shù)字的很常見，用亦或比較優(yōu)。
  • 缺兩個的直接用這個則不好，求和相減也只能知道兩個數(shù)的和，那么則需要思考如何轉(zhuǎn)換為一個。
  • 將數(shù)組中的元素與 1 ~ n 全部進行異或運算，，記為c。由于a!=b。所以c!=0；那么一定有一位是1。用d=（c-(c&(c-1)))就可以得到c的最右邊的為1的位，以這一位為分界線，為1的分為一組，不為1的分成另一組，這樣就將問題轉(zhuǎn)化成問題1的情況了。那a、b自然也就出來了。

---

• Redis：hash、set、zset
  • hash 是哈希表。
    • 實現(xiàn)原理，其在存儲內(nèi)容較少的時候使用ziplist 壓縮列表，內(nèi)容多的時候使用hashtable 哈希表，存儲的是string的鍵值對。
    • 用途：比如購物車緩存，uid對應(yīng)一個hash，里面存（商品名 : 數(shù)量）。再比如做計數(shù)器，HINCRBY 操作可以直接加一。（日期 : 訪問量）、（文章id：點贊數(shù)）等。
  • set 是無序集合。
    • 實現(xiàn)原理：編碼可以是 intset 或者 hashtable。往里存入一個string。
    • 無序集合的用途：不允許重復(fù)。做并集，搽劑，交集等操作。比如共同好友。
  • zset 有序集合：
    • 實現(xiàn)原理：skip_list跳表和hashtable哈希表。skip_list跳表詳解見下方。
    • 存入時，每個value需要對應(yīng)一個分數(shù)，按照分數(shù)排序。
    • 用途：用于需要排序的表，比如排行榜，分數(shù)榜之類的。還可以交集并集。
      • 博客中還提到了限流也可以用排序set做，很神奇，記錄一下：滑動窗口限流，我們把一個用戶的訪問時間戳作為score和value。我們只需統(tǒng)計某個用戶在指定時間戳區(qū)間內(nèi)的次數(shù)，限制這個次數(shù)來決定是否訪問。

---

• Redis中的跳表：
  • 跳表：90年提出的。平均 O(logN)，最差 O(N)。能與平衡樹媲美，但操作還簡單，空間換時間。

    • 最簡單的結(jié)構(gòu)如下圖，上層元素跳著排，下層比上層跳的少，最后一層所有元素。查找時，從上層查找。
      

    • redis中用跳表，利于查找區(qū)間，插入、刪除時也比較方便，不會設(shè)計紅黑樹的染色旋轉(zhuǎn)等。

    • redis中加強了一下：首先，最底層元素有后驅(qū)指針，是前后都可以遍歷的。再者，對于是否作為上層節(jié)點，是依靠概率的。
      

---

• Redis 6.0 加入了 多線程
  • 6.0之前，核心處理是單線程的，其他操作可能是多線程的，真正處理語句和數(shù)據(jù)是單線程的，好處是無鎖開銷，切換線程的開銷。但也無法用到多CPU帶來的效率提升。

---

• 如何避免死鎖：
  • 代碼中可以按順序獲取鎖；
  • 可以設(shè)置超時時間(redis分布式鎖)；
  • 銀行家算法：還有已知進程資源需求的情況下，在啟動時就判斷是否有死鎖的可能。

---

• Redis 過期策略：
  • 定時： 定時器，每個過期時間都一個定時器，太消耗資源了，沒人用。
  • 惰性：訪問到這個鍵值了之后，才查看，過期了則淘汰。
  • 定期：一段時間清理一次，設(shè)置10則是100ms清理一次；并且當maxmemory滿了也會清理。

---

• Redis 的清理策略：當前已用內(nèi)存超過maxmemory限定時，觸發(fā)主動清理策略
  • 設(shè)置過期時間的 + LRU 最近最少使用的；
  • 設(shè)置過期時間的 + ramdom 隨機的；
  • 設(shè)置過期時間的 + ttl 即將要過期的；
  • 全部數(shù)據(jù)中 + LRU；
  • 全部數(shù)據(jù) + ramdom；
  • 不淘汰，寫入失敗。
  • Redis 的 LRU 的實現(xiàn)：通過給每個對象一個時間戳。但維護 LRU隊列 需要額外開銷。Redis為了效率，策略是隨機取出若干個key，然后按照訪問時間排序后，淘汰掉最不經(jīng)常使用的。

---

總結(jié)

以上是生活随笔為你收集整理的阿龙的学习笔记---202107学习的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。