https://github.com/baidu/uid-generator
snowflake算法
uid-generator是基於Twitter開源的snowflake算法實現的。
snowflake將long的64位分為了3部分，時間戳、工作機器id和序列號，位數分配如下。
其中，時間戳部分的時間單位一般為毫秒。也就是說1台工作機器1毫秒可產生4096個id（2的12次方）。
源碼實現分析
與原始的snowflake算法不同，uid-generator支持自定義時間戳、工作機器id和序列號等各部分的位數，以應用於不同場景。默認分配方式如下。
-
sign(1bit)
固定1bit符號標識，即生成的UID為正數。 -
delta seconds (28 bits)
當前時間，相對於時間基點"2016-05-20"的增量值，單位：秒，最多可支持約8.7年（注意：1. 這里的單位是秒，而不是毫秒！ 2.注意這里的用詞，是“最多”可支持8.7年，為什么是“最多”，后面會講） -
worker id (22 bits)
機器id，最多可支持約420w次機器啟動。內置實現為在啟動時由數據庫分配，默認分配策略為用后即棄，后續可提供復用策略。 -
sequence (13 bits)
每秒下的並發序列，13 bits可支持每秒8192個並發。（注意下這個地方，默認支持qps最大為8192個）
DefaultUidGenerator
DefaultUidGenerator的產生id的方法與基本上就是常見的snowflake算法實現，僅有一些不同，如以秒為為單位而不是毫秒。
DefaultUidGenerator的產生id的方法如下。
CachedUidGenerator
CachedUidGenerator支持緩存生成的id。
基本實現原理
關於CachedUidGenerator，文檔上是這樣介紹的。
【采用RingBuffer來緩存已生成的UID, 並行化UID的生產和消費】
使用RingBuffer緩存生成的id。RingBuffer是個環形數組，默認大小為8192個，里面緩存着生成的id。
獲取id
會從ringbuffer中拿一個id，支持並發獲取
填充id
RingBuffer填充時機
-
程序啟動時，將RingBuffer填充滿，緩存着8192個id
-
在調用getUID()獲取id時，檢測到RingBuffer中的剩余id個數小於總個數的50%，將RingBuffer填充滿，使其緩存8192個id
-
定時填充（可配置是否使用以及定時任務的周期）
【UidGenerator通過借用未來時間來解決sequence天然存在的並發限制】
因為delta seconds部分是以秒為單位的，所以1個worker 1秒內最多生成的id書為8192個（2的13次方）。
從上可知，支持的最大qps為8192，所以通過緩存id來提高吞吐量。
為什么叫借助未來時間？
因為每秒最多生成8192個id，當1秒獲取id數多於8192時，RingBuffer中的id很快消耗完畢，在填充RingBuffer時，生成的id的delta seconds 部分只能使用未來的時間。
（因為使用了未來的時間來生成id，所以上面說的是，【最多】可支持約8.7年）
源碼剖析
獲取id
RingBuffer緩存已生成的id
（注意：這里的RingBuffer不是Disruptor框架中的RingBuffer，但是借助了很多Disruptor中RingBuffer的設計思想，比如使用緩存行填充解決偽共享問題）
RingBuffer為環形數組，默認容量為sequence可容納的最大值（8192個），可以通過boostPower參數設置大小。
tail指針、Cursor指針用於環形數組上讀寫slot：
-
Tail指針
表示Producer生產的最大序號(此序號從0開始，持續遞增)。Tail不能超過Cursor，即生產者不能覆蓋未消費的slot。當Tail已趕上curosr，此時可通過rejectedPutBufferHandler指定PutRejectPolicy -
Cursor指針
表示Consumer消費到的最小序號(序號序列與Producer序列相同)。Cursor不能超過Tail，即不能消費未生產的slot。當Cursor已趕上tail，此時可通過rejectedTakeBufferHandler指定TakeRejectPolicy
CachedUidGenerator采用了雙RingBuffer，Uid-RingBuffer用於存儲Uid、Flag-RingBuffer用於存儲Uid狀態(是否可填充、是否可消費)
由於數組元素在內存中是連續分配的，可最大程度利用CPU cache以提升性能。但同時會帶來「偽共享」FalseSharing問題，為此在Tail、Cursor指針、Flag-RingBuffer中采用了CacheLine 補齊方式。
RingBuffer填充時機
-
程序啟動時，將RingBuffer填充滿，緩存着8192個id
-
在調用getUID()獲取id時，檢測到RingBuffer中的剩余id個數小於總個數的50%，將RingBuffer填充滿，使其緩存8192個id
-
定時填充（可配置是否使用以及定時任務的周期）
填充RingBuffer
生成id（上面代碼中的uidProvider.provide調用的就是這個方法）
填充緩存行解決“偽共享”
關於偽共享，可以參考這篇文章《偽共享（false sharing），並發編程無聲的性能殺手》
可以參考下面文章
一個Java對象到底占用多大內存？https://www.cnblogs.com/magialmoon/p/3757767.html
寫Java也得了解CPU--偽共享 https://www.cnblogs.com/techyc/p/3625701.html