redis hash 數據結構大家通常都會用到，而 bitmap 則是一種更省內存的數據結構，可以用來快速查詢、去重等。
今天用兩個 setbit 命令，讓 redis bitmap 內存占用飆升到 512 MB......
設置 bitmap 前 redis 內存如下：
圖1：
操作 bitmap，只用兩個 setbit 操作。注意了....
圖2：
一頓騷操作后，redis 內存使用如下：
圖3：
內存暴漲，發現沒有？？？
為什么？
bitmap 內存暴漲原因：
bitmap 在 redis 中按 string 來存儲，因此上限是 512MB（2^32 bits）. 因此當我的第二個 setbit 值為 2^32-1=4294967295 時，由於 redis 沒有采用壓縮實現，就會直接申請到 512MB 內存空間來存儲 2^32-1 bit 位置的值 1，中間的 bit 也會全填上 0.
而 guava 中 EWAHCompressedBitmap 是一種壓縮的 bitmap 實現，將 64 bit 作為一個 word（一個 long 的長度），4個 word 作為一組，並在每一組的第一個 word 引入了 Running Length Word （攜帶跨度信息 word，類似路標）概念，其他三個 word 為 Literal Word（直接存儲信息的 word）。在壓縮 bitmap 實現下，本文的兩個 setbit 操作就不會使 EWAHCompressedBitmap 內存占用暴漲，而是只會使用 2組 word，即 64 bytes.
不過即使通過壓縮節省了空間，google 官方仍建議使用者從小到大來插入數據......
所以為了測試，給 redis bitmap 試了兩個騷操作，結果證明 redis bitmap 沒有用壓縮結構實現.
參考文章：
小灰的 bitmap 算法整合版：https://mp.weixin.qq.com/s/xxauNrJY9HlVNvLrL5j2hg
redis bitmap command：https://redis.io/commands/setbit