：41位時間戳的三個坑（時鐘回撥、workerId、位運算）)
老炮踩坑錄 · D08 · 技術深挖系列· 基于「企業(yè)融合平臺」真實源碼· 逐行拆解手寫 Snowflake ID 生成器· 關鍵詞3大坑 · 位運算 · 時鐘回撥 · 序列溢出 · workerId撞車 · CPU假死引子面試必問雪花算法這個項目里居然有人手寫了2026 年Java 21 LTS 成了生產(chǎn)標配Java 26 都發(fā)布了。分布式 ID 這個老話題依然是面試高頻考點——分庫分表后全局 ID 怎么生成十有八九會引出雪花算法然后面試官追一句“時鐘回撥怎么處理”很多人背過 Twitter Snowflake 的 64 位結構面試時能默寫1 41 5 5 12 64但真讓你打開源碼逐行看位運算是怎么拼裝的、時鐘回撥是怎么檢測的、序列溢出是怎么處理的——大部分人都停在 “看懂結構圖” 這一步?jīng)]真正讀過一行實現(xiàn)。巧了我翻的這個 2022 年的老項目里有人手寫了完整的雪花算法從位結構設計到 Spring 集成一個都不落(la)。今天這篇我就拿著項目里真實的SnowflakeIdGenerator.java逐行拆給你看64 位 long 是怎么一段一段拼出來的synchronized為什么必須加時鐘回撥 3 毫秒就能讓線上報 500錯誤先看全貌雪花算法長什么樣子打開SnowflakeIdGenerator.java類注釋直接畫了一張結構圖/** * Twitter_Snowflake * SnowFlake的結構如下(每部分用-分開): * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 * 1位標識由于long基本類型在Java中是帶符號的最高位是符號位正數(shù)是0負數(shù)是1 * 41位時間截(毫秒級)注意41位時間截不是存儲當前時間的時間截而是存儲時間截的差值 * 41位的時間截可以使用69年 * 10位的數(shù)據(jù)機器位可以部署在1024個節(jié)點 * 12位序列毫秒內的計數(shù)支持每個節(jié)點每毫秒產(chǎn)生4096個ID序號 * 加起來剛好64位為一個Long型。 */publicclassSnowflakeIdGenerator{// ...}注釋寫得規(guī)規(guī)矩矩一看就是從 Twitter 原版翻譯過來的。但光看注釋不夠我們得一段一段拆開看。64 位 long 的位結構設計每一比特都不浪費五段劃分圖示如下段位數(shù)作用容量符號位1保證 ID 為正Java long 帶符號固定 0時間戳41毫秒級時間差值約 69 年數(shù)據(jù)中心 ID5區(qū)分機房0~31機器 ID5區(qū)分同機房節(jié)點0~31序列號12同毫秒內遞增0~4095起始時間戳為什么是 2015 年privatefinallongtwepoch1420041600000L;// 2015-01-01 00:00:00 UTC注意41 位存的不是System.currentTimeMillis()而是當前時間 - twepoch的差值。為什么因為 41 位最多表示2^41 - 1 2,199,023,255,551毫秒換算成年2,199,023,255,551 / 1000 / 60 / 60 / 24 / 365 ≈ 69.7 年如果從 1970 年算起到 2039 年就溢出了。但從 2015 年算起能撐到2084 年。這就是為什么twepoch很重要——它決定了 ID 生成器的壽命。你完全可以把它設成項目上線的那天最大化利用這 41 位。位移量低位段位數(shù)之和 高位段移位量privatefinallongsequenceBits12L;privatefinallongworkerIdShiftsequenceBits;// 12privatefinallongdatacenterIdShiftsequenceBitsworkerIdBits;// 17privatefinallongtimestampLeftShiftsequenceBitsworkerIdBitsdatacenterIdBits;// 22發(fā)現(xiàn)規(guī)律了嗎每一段的左移量等于它右邊所有段的位數(shù)之和。序列號不移位最右邊 機器ID左移 12 位右邊有 12 位序列號 數(shù)據(jù)中心左移 17 位右邊有 12 5 17 位 時間戳左移 22 位右邊有 12 5 5 22 位這樣設計的好處是每段在 64 位 long 中各占各的位置互不干擾最后用按位或|拼裝即可。就像五條鐵軌每列火車走自己的道永遠不會撞車。掩碼的妙用用位運算代替 if 判斷最大值計算privatefinallongmaxWorkerId-1L^(-1LworkerIdBits);// 31privatefinallongmaxDatacenterId-1L^(-1LdatacenterIdBits);// 31privatefinallongsequenceMask-1L^(-1LsequenceBits);// 4095第一次看這段代碼的人大概率會懵-1L ^ (-1L 5)是什么鬼別急拆成二進制看就清楚了-1L 的二進制 11111111 11111111 ... 1111111164 個 1 -1L 5 11111111 11111111 ... 11100000低 5 位變 0 異或^ 00000000 00000000 ... 00011111只有低 5 位是 1 31所以-1L ^ (-1L n)的效果就是生成一個低 n 位全為 1 的掩碼。5 位掩碼 0b11111 31workerId / datacenterId 的最大值12 位掩碼 0b111111111111 4095序列號的最大值序列號溢出檢測這是整段代碼里最精妙的一行sequence(sequence1)sequenceMask;當sequence 4095時(4095 1) 4095 4096 4095 0b1000000000000 0b111111111111 0加 1 后與掩碼做按位與超過 4095 自動歸零。不需要if (sequence 4095) sequence 0一條位運算搞定。這就是位運算的魅力把 “判斷 賦值” 兩步操作壓縮成了一步這在高頻調用的場景下性能差異是實打實的高。核心算法 nextId()逐行拆解終于到了分析最核心的邏輯方法了。核心源碼我把完整源碼貼出來并逐行加上注釋publicsynchronizedlongnextId(){// ① 獲取當前時間戳毫秒longtimestamptimeGen();// ② 時鐘回退檢測當前時間 上次生成 ID 的時間 → 拋異常if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}// ③ 同一毫秒內的序列處理if(lastTimestamptimestamp){// 同一毫秒 → 序列號 1掩碼保證不超過 4095sequence(sequence1)sequenceMask;// 序列溢出回到 0→ 自旋等到下一毫秒if(sequence0){timestamptilNextMillis(lastTimestamp);}}// ④ 新的毫秒 → 序列重置為 0else{sequence0L;}// ⑤ 記錄本次時間戳lastTimestamptimestamp;// ⑥ 位運算拼裝 64 位 IDreturn((timestamp-twepoch)timestampLeftShift)// 時間戳差值左移 22 位|(datacenterIddatacenterIdShift)// 數(shù)據(jù)中心 ID 左移 17 位|(workerIdworkerIdShift)// 機器 ID 左移 12 位|sequence;// 序列號不移位}六個步驟nextId()方法的六大步驟流程圖舉個計算例子假設timestamp - twepoch 1000, datacenterId 20, workerId 10, sequence 5時間戳部分1000 22 4,194,304,000 數(shù)據(jù)中心 20 17 2,621,440 機器 ID 10 12 40,960 序列號 5 5 ──────────────────────────────────────── 按位或拼裝 4,196,966,405每段井水不犯河水按位或 拼裝。因為每段的二進制位互不重疊所以|運算等價于加法但語義更清晰——我是在組裝不是在相加。自旋等待tilNextMillis()protectedlongtilNextMillis(longlastTimestamp){longtimestamptimeGen();while(timestamplastTimestamp){timestamptimeGen();// CPU 空轉浪費時間片}returntimestamp;}序列號用完了怎么辦死循環(huán)等等到下一毫秒再來。這個while循環(huán)叫busy-wait忙等待——CPU 在空轉什么都不干就反復問到下一毫秒了沒。在正常情況下一毫秒很快就過去了循環(huán)個幾十到幾百次就拿到新時間戳。但在高并發(fā)場景下如果每毫秒都在溢出這個忙等待會吃掉 CPU 時間片是個性能隱患。如何解決呢 可以參考美團 Leaf 在生產(chǎn)環(huán)境驗證過的方案。你有其它更好的方案嗎歡迎在評論區(qū)討論。Spring 集成四層配置鏈光有算法不夠還得接入 Spring。這個項目的做法是標準的三層架構。完整調用鏈路和架構圖第一層yml 配置# application.ymlpubframe:id:workId:10# 當前機器的工作 IDcenterId:20# 當前數(shù)據(jù)中心 ID第二層配置屬性類ConfigurationProperties(prefixpubframe.id)publicclassIdGenProperties{privatelongworkId0;// 工作機器ID (0~31)privatelongcenterId0;// 數(shù)據(jù)中心ID (0~31)// getter/setter/toString...}ConfigurationProperties把 yml 里的值自動綁到 Java 對象上。注意默認值都是 0——如果 yml 沒配兩臺機器都會拿到workId0, centerId0。第三層自動注冊 BeanSlf4jConfigurationEnableConfigurationProperties(IdGenProperties.class)publicclassAutoConfiguration{BeanConditionalOnMissingBean(IdGenProperties.class)publicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties){SnowflakeIdGeneratorgeneratornewSnowflakeIdGenerator(properties.getWorkId(),// workId 10properties.getCenterId()// centerId 20);log.info(bean [{}] properties [{}],generator,properties);returngenerator;}}Bean把SnowflakeIdGenerator注冊為 Spring 容器里的 BeanConditionalOnMissingBean保證如果你沒自定義就用默認的?？雌饋砗苊缹Π膳渲谩⒔壎?、注冊三層各司其職開箱即用。看到這里你可能覺得這個實現(xiàn)挺規(guī)范的。別急坑在后面我們一個一個的分析并解決。三個坑一個比一個狠?? 坑 1時鐘回撥直接拋異常3 毫秒就 500if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}時鐘一回撥直接throw RuntimeException。你知道這意味著什么嗎生產(chǎn)環(huán)境的 NTP 服務每隔一段時間會校準時間回撥幾毫秒是家常便飯。只要回撥發(fā)生任何調用nextId()的業(yè)務代碼就會收到一個RuntimeException如果沒有 catch就是 500 錯誤。正確的做法是什么分級處理if(timestamplastTimestamp){longoffsetlastTimestamp-timestamp;if(offset5){// 5ms 以內的微小回撥等它追上來Thread.sleep(offset1);// 等兩倍時間留余量timestamptimeGen();if(timestamplastTimestamp){thrownewRuntimeException(Clock still moving backwards);}}elseif(offset100){// 100ms 以內的中等回撥用上次的時間戳繼續(xù)生成序列號遞增timestamplastTimestamp;}else{// 超過 100ms 的大回撥真的出問題了拋異常thrownewRuntimeException(Clock moved backwards too much: offsetms);}}總結小回撥等一等中回撥借用上次時間戳硬撐大回撥才拋異常。這才是生產(chǎn)級的處理方式。?? 坑 2workerId 寫在 yml 里兩臺機器配了一樣的 IDpubframe:id:workId:10#運維拷配置的時候忘記改了centerId:20workId和centerId直接寫死在配置文件里。想象一下這個場景運維要部署兩臺機器拷了一份配置文件改改數(shù)據(jù)庫地址就上了。結果workId忘了改——兩臺機器都是workId10, centerId20。后果是什么兩臺機器在同一毫秒內用相同的序列號生成完全一樣的 ID。雪花算法的 “全局唯一” 保證是建立在 “每臺機器的 workerId 不同” 這個前提上。workerId 撞了唯一性就崩了。正確的做法是什么讓 workerId 自動分配而不是靠人記著改配置方案一從 ZooKeeper / Redis 自動獲取啟動時注冊臨時節(jié)點拿到全局唯一的 workerIdBeanpublicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties,ZookeeperClientzkClient){// 啟動時從 ZK 占一個臨時節(jié)點longworkerIdzkClient.createEphemeralSequential(/snowflake/worker-);longdatacenterIdproperties.getCenterId();// 機房級別還是配returnnewSnowflakeIdGenerator(workerId,datacenterId);}方案二基于 IP 地址末兩段計算int workerId (ip[2] 0x1F); // 取 IP 第三段低 5 位 int centerId (ip[3] 0x1F); // 取 IP 第四段低 5 位總之凡是靠人記著改的配置遲早會有人忘記修改。?? 坑 3synchronized 全局鎖高并發(fā)下排隊publicsynchronizedlongnextId(){注意這個synchronized——它鎖的是整個SnowflakeIdGenerator實例對象。也就是說不管有多少個線程同時調用nextId()都得排隊一個一個來。在單機低并發(fā)場景下這沒什么問題。但如果你的服務每秒要生成幾萬個 ID所有線程都在這一把鎖上排隊這里就成了整個系統(tǒng)的吞吐量瓶頸。有沒有更好的方案有——用 CASCompare-And-Swap無鎖實現(xiàn)思路用 AtomicLong 代替 synchronized。把 lastTimestamp 和 sequence 打包成一個 long 用 CAS 操作原子更新失敗就重試。publiclongnextId(){longcurrent;longnext;do{currentlastTimestamp.get();// ... 計算 next}while(!lastTimestamp.compareAndSet(current,next));returnnext;}但 CAS 方案實現(xiàn)復雜度高很多需要壓測驗證是否值得做。對于這個項目的并發(fā)量synchronized其實就夠用——但是你要知道它的天花板在哪里。雪花算法面試怎么答面試官問說說雪花算法你可以這樣答第一層結構Snowflake 把 64 位 long 分成五段——1 位符號位、41 位時間戳差值、5 位數(shù)據(jù)中心、5 位機器 ID、12 位序列號。時間戳保證趨勢遞增機器 ID 保證分布式不撞車序列號保證同毫秒內不重復。第二層核心操作每段左移量等于右邊所有段的位數(shù)之和最后按位或拼裝。序列號溢出用掩碼(seq1) mask檢測歸零后自旋等下一毫秒。第三層生產(chǎn)問題最大風險是時鐘回撥。生產(chǎn)環(huán)境 NTP 校時可能導致幾毫秒的回撥直接拋異常會導致 500錯誤。正確做法是分級處理——小回撥等待、中回撥借用時間戳、大回撥降級到號段模式。另外 workerId 不能寫在配置文件要靠注冊中心自動分配。生產(chǎn)環(huán)境 Checklist檢查項常見坑正確做法時鐘回撥直接拋異常 → 500分級處理等待 / 借用 / 降級workerId 分配yml 寫死 → 撞 IDZK/Redis 自動分配起始時間戳用 1970 年 → 2039 溢出設為項目上線日期線程安全無鎖 → ID 重復synchronized 或 CAS啟動校驗不檢查 → 大回撥流入線上持久化 lastTimestamp啟動時比對監(jiān)控告警無感知 → 出問題才知道回撥次數(shù)/幅度接入 Prometheus要不要自己寫我的建議是不要自己寫。美團 Leaf號段模式 Snowflake 雙模式生產(chǎn)驗證ShardingSphere 內置配合分庫分表直接用MyBatis-PlusIdType.ASSIGN_ID默認就是雪花算法Spring 生態(tài)spring-context-support里有現(xiàn)成實現(xiàn)自己寫適合學習和面試生產(chǎn)環(huán)境還是用成熟的開源方案——它們幫你處理了你沒想到的邊界情況。老炮點評這篇文章我們從一個真實項目的手寫雪花算法出發(fā)我們看到了位結構設計的精妙41 位時間戳 10 位機器標識 12 位序列號64 位 long 剛好用完每一比特都不浪費。位運算的性能之美掩碼檢測溢出、移位拼裝 ID用代替if用|代替一條指令搞定。時鐘回撥的殘酷現(xiàn)實算法假設時間是單調向前的但物理世界的時鐘會被 NTP 校準、被閏秒打亂、被運維手動改。3 毫秒的回撥就能讓線報 500錯誤。配置化 workerId 的隱患靠人記著改的配置遲早有人忘記改。synchronized 的天花板簡單有效但高并發(fā)下是瓶頸。最后送一句話分布式系統(tǒng)里沒有銀彈雪花算法也不例外。它用對時間的依賴換來了簡單和高效但時間本身是不可靠的——這就是工程世界的永恒矛盾。在·下一篇預告《workerId 配錯兩臺機器生成了一樣的 ID》這篇文章里我說了workerId 寫在 yml 里遲早有人忘記改——這不是假設是真實發(fā)生過的生產(chǎn)事故。下一篇我把這個坑的前因后果完整講一遍怎么發(fā)現(xiàn)的、怎么排查的、怎么修的。我是老炮18 年 Java 老兵仍在一線。關注「老炮踩坑錄」真實案例幫你少踩坑。 Java雪花算法Snowflake實戰(zhàn)：41位時間戳的三個坑（時鐘回撥、workerId、位運算）
老炮踩坑錄 · D08 · 技術深挖系列· 基于「企業(yè)融合平臺」真實源碼· 逐行拆解手寫 Snowflake ID 生成器· 關鍵詞3大坑 · 位運算 · 時鐘回撥 · 序列溢出 · workerId撞車 · CPU假死引子面試必問雪花算法這個項目里居然有人手寫了2026 年Java 21 LTS 成了生產(chǎn)標配Java 26 都發(fā)布了。分布式 ID 這個老話題依然是面試高頻考點——分庫分表后全局 ID 怎么生成十有八九會引出雪花算法然后面試官追一句“時鐘回撥怎么處理”很多人背過 Twitter Snowflake 的 64 位結構面試時能默寫1 41 5 5 12 64但真讓你打開源碼逐行看位運算是怎么拼裝的、時鐘回撥是怎么檢測的、序列溢出是怎么處理的——大部分人都停在 “看懂結構圖” 這一步?jīng)]真正讀過一行實現(xiàn)。巧了我翻的這個 2022 年的老項目里有人手寫了完整的雪花算法從位結構設計到 Spring 集成一個都不落(la)。今天這篇我就拿著項目里真實的SnowflakeIdGenerator.java逐行拆給你看64 位 long 是怎么一段一段拼出來的synchronized為什么必須加時鐘回撥 3 毫秒就能讓線上報 500錯誤先看全貌雪花算法長什么樣子打開SnowflakeIdGenerator.java類注釋直接畫了一張結構圖/** * Twitter_Snowflake * SnowFlake的結構如下(每部分用-分開): * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 * 1位標識由于long基本類型在Java中是帶符號的最高位是符號位正數(shù)是0負數(shù)是1 * 41位時間截(毫秒級)注意41位時間截不是存儲當前時間的時間截而是存儲時間截的差值 * 41位的時間截可以使用69年 * 10位的數(shù)據(jù)機器位可以部署在1024個節(jié)點 * 12位序列毫秒內的計數(shù)支持每個節(jié)點每毫秒產(chǎn)生4096個ID序號 * 加起來剛好64位為一個Long型。 */publicclassSnowflakeIdGenerator{// ...}注釋寫得規(guī)規(guī)矩矩一看就是從 Twitter 原版翻譯過來的。但光看注釋不夠我們得一段一段拆開看。64 位 long 的位結構設計每一比特都不浪費五段劃分圖示如下段位數(shù)作用容量符號位1保證 ID 為正Java long 帶符號固定 0時間戳41毫秒級時間差值約 69 年數(shù)據(jù)中心 ID5區(qū)分機房0~31機器 ID5區(qū)分同機房節(jié)點0~31序列號12同毫秒內遞增0~4095起始時間戳為什么是 2015 年privatefinallongtwepoch1420041600000L;// 2015-01-01 00:00:00 UTC注意41 位存的不是System.currentTimeMillis()而是當前時間 - twepoch的差值。為什么因為 41 位最多表示2^41 - 1 2,199,023,255,551毫秒換算成年2,199,023,255,551 / 1000 / 60 / 60 / 24 / 365 ≈ 69.7 年如果從 1970 年算起到 2039 年就溢出了。但從 2015 年算起能撐到2084 年。這就是為什么twepoch很重要——它決定了 ID 生成器的壽命。你完全可以把它設成項目上線的那天最大化利用這 41 位。位移量低位段位數(shù)之和 高位段移位量privatefinallongsequenceBits12L;privatefinallongworkerIdShiftsequenceBits;// 12privatefinallongdatacenterIdShiftsequenceBitsworkerIdBits;// 17privatefinallongtimestampLeftShiftsequenceBitsworkerIdBitsdatacenterIdBits;// 22發(fā)現(xiàn)規(guī)律了嗎每一段的左移量等于它右邊所有段的位數(shù)之和。序列號不移位最右邊 機器ID左移 12 位右邊有 12 位序列號 數(shù)據(jù)中心左移 17 位右邊有 12 5 17 位 時間戳左移 22 位右邊有 12 5 5 22 位這樣設計的好處是每段在 64 位 long 中各占各的位置互不干擾最后用按位或|拼裝即可。就像五條鐵軌每列火車走自己的道永遠不會撞車。掩碼的妙用用位運算代替 if 判斷最大值計算privatefinallongmaxWorkerId-1L^(-1LworkerIdBits);// 31privatefinallongmaxDatacenterId-1L^(-1LdatacenterIdBits);// 31privatefinallongsequenceMask-1L^(-1LsequenceBits);// 4095第一次看這段代碼的人大概率會懵-1L ^ (-1L 5)是什么鬼別急拆成二進制看就清楚了-1L 的二進制 11111111 11111111 ... 1111111164 個 1 -1L 5 11111111 11111111 ... 11100000低 5 位變 0 異或^ 00000000 00000000 ... 00011111只有低 5 位是 1 31所以-1L ^ (-1L n)的效果就是生成一個低 n 位全為 1 的掩碼。5 位掩碼 0b11111 31workerId / datacenterId 的最大值12 位掩碼 0b111111111111 4095序列號的最大值序列號溢出檢測這是整段代碼里最精妙的一行sequence(sequence1)sequenceMask;當sequence 4095時(4095 1) 4095 4096 4095 0b1000000000000 0b111111111111 0加 1 后與掩碼做按位與超過 4095 自動歸零。不需要if (sequence 4095) sequence 0一條位運算搞定。這就是位運算的魅力把 “判斷 賦值” 兩步操作壓縮成了一步這在高頻調用的場景下性能差異是實打實的高。核心算法 nextId()逐行拆解終于到了分析最核心的邏輯方法了。核心源碼我把完整源碼貼出來并逐行加上注釋publicsynchronizedlongnextId(){// ① 獲取當前時間戳毫秒longtimestamptimeGen();// ② 時鐘回退檢測當前時間 上次生成 ID 的時間 → 拋異常if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}// ③ 同一毫秒內的序列處理if(lastTimestamptimestamp){// 同一毫秒 → 序列號 1掩碼保證不超過 4095sequence(sequence1)sequenceMask;// 序列溢出回到 0→ 自旋等到下一毫秒if(sequence0){timestamptilNextMillis(lastTimestamp);}}// ④ 新的毫秒 → 序列重置為 0else{sequence0L;}// ⑤ 記錄本次時間戳lastTimestamptimestamp;// ⑥ 位運算拼裝 64 位 IDreturn((timestamp-twepoch)timestampLeftShift)// 時間戳差值左移 22 位|(datacenterIddatacenterIdShift)// 數(shù)據(jù)中心 ID 左移 17 位|(workerIdworkerIdShift)// 機器 ID 左移 12 位|sequence;// 序列號不移位}六個步驟nextId()方法的六大步驟流程圖舉個計算例子假設timestamp - twepoch 1000, datacenterId 20, workerId 10, sequence 5時間戳部分1000 22 4,194,304,000 數(shù)據(jù)中心 20 17 2,621,440 機器 ID 10 12 40,960 序列號 5 5 ──────────────────────────────────────── 按位或拼裝 4,196,966,405每段井水不犯河水按位或 拼裝。因為每段的二進制位互不重疊所以|運算等價于加法但語義更清晰——我是在組裝不是在相加。自旋等待tilNextMillis()protectedlongtilNextMillis(longlastTimestamp){longtimestamptimeGen();while(timestamplastTimestamp){timestamptimeGen();// CPU 空轉浪費時間片}returntimestamp;}序列號用完了怎么辦死循環(huán)等等到下一毫秒再來。這個while循環(huán)叫busy-wait忙等待——CPU 在空轉什么都不干就反復問到下一毫秒了沒。在正常情況下一毫秒很快就過去了循環(huán)個幾十到幾百次就拿到新時間戳。但在高并發(fā)場景下如果每毫秒都在溢出這個忙等待會吃掉 CPU 時間片是個性能隱患。如何解決呢 可以參考美團 Leaf 在生產(chǎn)環(huán)境驗證過的方案。你有其它更好的方案嗎歡迎在評論區(qū)討論。Spring 集成四層配置鏈光有算法不夠還得接入 Spring。這個項目的做法是標準的三層架構。完整調用鏈路和架構圖第一層yml 配置# application.ymlpubframe:id:workId:10# 當前機器的工作 IDcenterId:20# 當前數(shù)據(jù)中心 ID第二層配置屬性類ConfigurationProperties(prefixpubframe.id)publicclassIdGenProperties{privatelongworkId0;// 工作機器ID (0~31)privatelongcenterId0;// 數(shù)據(jù)中心ID (0~31)// getter/setter/toString...}ConfigurationProperties把 yml 里的值自動綁到 Java 對象上。注意默認值都是 0——如果 yml 沒配兩臺機器都會拿到workId0, centerId0。第三層自動注冊 BeanSlf4jConfigurationEnableConfigurationProperties(IdGenProperties.class)publicclassAutoConfiguration{BeanConditionalOnMissingBean(IdGenProperties.class)publicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties){SnowflakeIdGeneratorgeneratornewSnowflakeIdGenerator(properties.getWorkId(),// workId 10properties.getCenterId()// centerId 20);log.info(bean [{}] properties [{}],generator,properties);returngenerator;}}Bean把SnowflakeIdGenerator注冊為 Spring 容器里的 BeanConditionalOnMissingBean保證如果你沒自定義就用默認的?？雌饋砗苊缹Π膳渲谩⒔壎?、注冊三層各司其職開箱即用。看到這里你可能覺得這個實現(xiàn)挺規(guī)范的。別急坑在后面我們一個一個的分析并解決。三個坑一個比一個狠?? 坑 1時鐘回撥直接拋異常3 毫秒就 500if(timestamplastTimestamp){thrownewRuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds,lastTimestamp-timestamp));}時鐘一回撥直接throw RuntimeException。你知道這意味著什么嗎生產(chǎn)環(huán)境的 NTP 服務每隔一段時間會校準時間回撥幾毫秒是家常便飯。只要回撥發(fā)生任何調用nextId()的業(yè)務代碼就會收到一個RuntimeException如果沒有 catch就是 500 錯誤。正確的做法是什么分級處理if(timestamplastTimestamp){longoffsetlastTimestamp-timestamp;if(offset5){// 5ms 以內的微小回撥等它追上來Thread.sleep(offset1);// 等兩倍時間留余量timestamptimeGen();if(timestamplastTimestamp){thrownewRuntimeException(Clock still moving backwards);}}elseif(offset100){// 100ms 以內的中等回撥用上次的時間戳繼續(xù)生成序列號遞增timestamplastTimestamp;}else{// 超過 100ms 的大回撥真的出問題了拋異常thrownewRuntimeException(Clock moved backwards too much: offsetms);}}總結小回撥等一等中回撥借用上次時間戳硬撐大回撥才拋異常。這才是生產(chǎn)級的處理方式。?? 坑 2workerId 寫在 yml 里兩臺機器配了一樣的 IDpubframe:id:workId:10#運維拷配置的時候忘記改了centerId:20workId和centerId直接寫死在配置文件里。想象一下這個場景運維要部署兩臺機器拷了一份配置文件改改數(shù)據(jù)庫地址就上了。結果workId忘了改——兩臺機器都是workId10, centerId20。后果是什么兩臺機器在同一毫秒內用相同的序列號生成完全一樣的 ID。雪花算法的 “全局唯一” 保證是建立在 “每臺機器的 workerId 不同” 這個前提上。workerId 撞了唯一性就崩了。正確的做法是什么讓 workerId 自動分配而不是靠人記著改配置方案一從 ZooKeeper / Redis 自動獲取啟動時注冊臨時節(jié)點拿到全局唯一的 workerIdBeanpublicSnowflakeIdGeneratorsnowflakeIdWorker(IdGenPropertiesproperties,ZookeeperClientzkClient){// 啟動時從 ZK 占一個臨時節(jié)點longworkerIdzkClient.createEphemeralSequential(/snowflake/worker-);longdatacenterIdproperties.getCenterId();// 機房級別還是配returnnewSnowflakeIdGenerator(workerId,datacenterId);}方案二基于 IP 地址末兩段計算int workerId (ip[2] 0x1F); // 取 IP 第三段低 5 位 int centerId (ip[3] 0x1F); // 取 IP 第四段低 5 位總之凡是靠人記著改的配置遲早會有人忘記修改。?? 坑 3synchronized 全局鎖高并發(fā)下排隊publicsynchronizedlongnextId(){注意這個synchronized——它鎖的是整個SnowflakeIdGenerator實例對象。也就是說不管有多少個線程同時調用nextId()都得排隊一個一個來。在單機低并發(fā)場景下這沒什么問題。但如果你的服務每秒要生成幾萬個 ID所有線程都在這一把鎖上排隊這里就成了整個系統(tǒng)的吞吐量瓶頸。有沒有更好的方案有——用 CASCompare-And-Swap無鎖實現(xiàn)思路用 AtomicLong 代替 synchronized。把 lastTimestamp 和 sequence 打包成一個 long 用 CAS 操作原子更新失敗就重試。publiclongnextId(){longcurrent;longnext;do{currentlastTimestamp.get();// ... 計算 next}while(!lastTimestamp.compareAndSet(current,next));returnnext;}但 CAS 方案實現(xiàn)復雜度高很多需要壓測驗證是否值得做。對于這個項目的并發(fā)量synchronized其實就夠用——但是你要知道它的天花板在哪里。雪花算法面試怎么答面試官問說說雪花算法你可以這樣答第一層結構Snowflake 把 64 位 long 分成五段——1 位符號位、41 位時間戳差值、5 位數(shù)據(jù)中心、5 位機器 ID、12 位序列號。時間戳保證趨勢遞增機器 ID 保證分布式不撞車序列號保證同毫秒內不重復。第二層核心操作每段左移量等于右邊所有段的位數(shù)之和最后按位或拼裝。序列號溢出用掩碼(seq1) mask檢測歸零后自旋等下一毫秒。第三層生產(chǎn)問題最大風險是時鐘回撥。生產(chǎn)環(huán)境 NTP 校時可能導致幾毫秒的回撥直接拋異常會導致 500錯誤。正確做法是分級處理——小回撥等待、中回撥借用時間戳、大回撥降級到號段模式。另外 workerId 不能寫在配置文件要靠注冊中心自動分配。生產(chǎn)環(huán)境 Checklist檢查項常見坑正確做法時鐘回撥直接拋異常 → 500分級處理等待 / 借用 / 降級workerId 分配yml 寫死 → 撞 IDZK/Redis 自動分配起始時間戳用 1970 年 → 2039 溢出設為項目上線日期線程安全無鎖 → ID 重復synchronized 或 CAS啟動校驗不檢查 → 大回撥流入線上持久化 lastTimestamp啟動時比對監(jiān)控告警無感知 → 出問題才知道回撥次數(shù)/幅度接入 Prometheus要不要自己寫我的建議是不要自己寫。美團 Leaf號段模式 Snowflake 雙模式生產(chǎn)驗證ShardingSphere 內置配合分庫分表直接用MyBatis-PlusIdType.ASSIGN_ID默認就是雪花算法Spring 生態(tài)spring-context-support里有現(xiàn)成實現(xiàn)自己寫適合學習和面試生產(chǎn)環(huán)境還是用成熟的開源方案——它們幫你處理了你沒想到的邊界情況。老炮點評這篇文章我們從一個真實項目的手寫雪花算法出發(fā)我們看到了位結構設計的精妙41 位時間戳 10 位機器標識 12 位序列號64 位 long 剛好用完每一比特都不浪費。位運算的性能之美掩碼檢測溢出、移位拼裝 ID用代替if用|代替一條指令搞定。時鐘回撥的殘酷現(xiàn)實算法假設時間是單調向前的但物理世界的時鐘會被 NTP 校準、被閏秒打亂、被運維手動改。3 毫秒的回撥就能讓線報 500錯誤。配置化 workerId 的隱患靠人記著改的配置遲早有人忘記改。synchronized 的天花板簡單有效但高并發(fā)下是瓶頸。最后送一句話分布式系統(tǒng)里沒有銀彈雪花算法也不例外。它用對時間的依賴換來了簡單和高效但時間本身是不可靠的——這就是工程世界的永恒矛盾。在·下一篇預告《workerId 配錯兩臺機器生成了一樣的 ID》這篇文章里我說了workerId 寫在 yml 里遲早有人忘記改——這不是假設是真實發(fā)生過的生產(chǎn)事故。下一篇我把這個坑的前因后果完整講一遍怎么發(fā)現(xiàn)的、怎么排查的、怎么修的。我是老炮18 年 Java 老兵仍在一線。關注「老炮踩坑錄」真實案例幫你少踩坑。