面試官：Redis的共享對象池了解嗎？

• 2022 年 3 月 8 日
• 筆記

我正在面試間里焦急地等待著，突然聽到了門外的腳步聲，隨即門被打開，穿著乾淨滿臉清秀的青年走了進來，一股男士香水的淡香撲面而來。

面試官：「平時在工作中用過Redis嗎？」

我：「用的比較多。」我心中暗喜，Redis我熟啊，什麼五種數據類型、兩種持久化方式倒背如流啊。

面試官：「Redis的共享對象池了解嗎？」

「這個。。沒有太深入了解。」我支支吾吾的說到，手心已經冒出冷汗。

面試官：「回去等消息吧。」

這句話說的乾淨利落，然後就沒有然後了。失敗是成功的媽媽，我不氣餒，決定馬上惡補一下。

共享對象池

創建大量重複的整數類型勢必會耗費大量記憶體，所以在Redis內部維護了一個從0到9999的整數對象池，這就是共享對象池。

為了驗證和理解，我們使用object refcount命令查看一下對象引用數，效果如下：

127.0.0.1:6379> set one-more-num1 404
OK
127.0.0.1:6379> object refcount one-more-num1
(integer) 2
172.24.130.22:6379> set one-more-num2 404
OK
127.0.0.1:6379> object refcount one-more-num2
(integer) 3

設置one-more-num1為404後，直接使用共享池中的整數對象，所以引用數為2（另外一個引用在對象池上）；再設置one-more-num2為404後，引用數變成了3。

不過需要注意的是：當設置最大記憶體值（maxmemory）並且啟用LRU相關淘汰策略（如：volatile-lru、allkeys-lru）時，共享對象池將會被禁止使用。

為什麼沒有字元串對象池？

共享對象池中一個關鍵操作是判斷對象是否相等。

Redis中只有整數類型的對象池，是因為整數的比較演算法的時間複雜度是O(1)，也只保留了10000個整數為了防止對象池的過度浪費。

相對而言，字元串的比較演算法的時間複雜度是O(n)，特別是長字元串的比較更加消耗性能。

而且，整數類型被重複使用的概率很大，字元串被重複使用的概率相比就會小很多很多，所以在Redis中只用整數類型的對象共享池。

面試官你等著瞧吧，今天你對我愛答不理，明天我讓你高攀不起，哈哈哈。。。

參考文獻：
《Redis設計與實現》
《Redis開發與運維》
《Redis 深度歷險：核心原理與應用實踐》

竟然已經看到這裡了，你我定是有緣人，留下你的點贊和關注，他日必成大器。

微信公眾號：萬貓學社

微信掃描二維碼

關注後回復「電子書」

獲取12本Java必讀技術書籍