redis-bitmaps 基礎概念:
redis 記憶體淘汰機制：
大致需求:指令碼批量匯入使用者資料到redis中，使用bitmap標記使用者是否在匯入的白名單中。使用者量級 億。
key使用了分片處理，把key分成了10w個， 每個key占用（1億/10w=1000)個bit。理想是key1用於標記uid 為1-1000的使用者，key2標記 uid為1001-2000的使用者,以此類推...;
offet但是沒有做分片處理，就導致了 key1 占用1000個bit。key2占用了2000個bit，但是前1000個全是0記在key1，是無效的儲存（因為前1000個使用者全都標記儲存在key1中）。以此類推，key3佔中3000個bit，前2000個bit是無效的儲存.....。key10w就占用了1億個bit，但是只有最後1000個bit是有效的儲存;
redis配置的記憶體淘汰機制為。allkeys-lru：在主鍵空間中，優先移除最近未使用的key。
1億占用redis記憶體計算就是（1億bit + 1億bit-1000bit + 1億bit-2000bit ........+1000bit）。是等差數列，求和=5000050000000bit = 625006250000b=610357666 kb=596052m =582g， 遠遠超出了redis記憶體，觸發redis淘汰機制。
記一次除錯
這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...
記一次 EqualsAndHashCode的疑惑
lombok的使用真的是讓開發人員欲罷不能，乙個 data不管有多少屬性全部搞定，以後加字段也不用從新生成get和set方法。不過這裡還是有乙個小坑需要注意一下，舉個例子 public class equalsandhashcodetest data noargsconstructor access...
記一次除錯
這是我最近幾個月來遇到的最棘手的乙個問題 昨天花了4個小時找出第一層次的原因 這個糾結啊，本來和老婆說好準時下班回家吃飯的，結果被這個問題拖了老久。這是乙個gradle的plugin，用來resolve公司內部的dependency的，弄完了跑測試專案的，拋乙個npe，而且npe還不在自己的 裡面。...