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

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

面試官：“平時在工作中用過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 深度歷險：核心原理與應用實踐》

Redis

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。