在构建高并发后端系统时，全局唯一且大致有序的ID是很多业务表的主键基础。雪花算法把一个数拆成几个含义不同的段，用位运算拼出一个long型整数，从而让多台机器各自发号而不冲突。下面先通过一张示意图建立直观印象。
雪花算法的位结构
雪花算法生成的ID是一个64位有符号长整数。第1位符号位固定为0，保证值为正数。接下来的41位存放当前时间与自定义起始时间的毫秒差，理论上可用约69年。再后面的10位分成5位数据中心ID和5位机器ID，最多支持1024个节点。最后的12位是序列号，同一毫秒内从0开始累加，最多产生4096个ID。
这种划分让ID具备局部递增特性，对MySQL的B+树索引非常友好。由于时间位在高位，新生成的ID一定大于旧ID，避免了UUID完全无序导致的页分裂问题。理解每一段占用的位数，是后面写代码的前提。
Java基础字段定义
我们需要先声明常量与运行时变量。起始时间戳可以选公司成立日或项目上线日，减少时间位消耗。机器ID在部署时通过配置或环境变量传入，避免硬编码。
public class SnowflakeIdGenerator {
// 起始时间戳（2020-01-01）
private final long epoch = 1577836800000L;
// 各段位数
private final long timestampBits = 41L;
private final long datacenterBits = 5L;
private final long workerBits = 5L;
private final long sequenceBits = 12L;
// 最大取值掩码
private final long maxDatacenter = ~(-1L << datacenterBits);
private final long maxWorker = ~(-1L << workerBits);
private final long maxSequence = ~(-1L << sequenceBits);
// 段偏移量
private final long workerShift = sequenceBits;
private final long datacenterShift = sequenceBits + workerBits;
private final long timestampShift = sequenceBits + workerBits + datacenterBits;
private long datacenterId;
private long workerId;
private long sequence = 0L;
private long lastTimestamp = -1L;
public SnowflakeIdGenerator(long datacenterId, long workerId) {
if (datacenterId > maxDatacenter || datacenterId < 0) {
throw new IllegalArgumentException("数据中心ID超出范围");
}
if (workerId > maxWorker || workerId < 0) {
throw new IllegalArgumentException("机器ID超出范围");
}
this.datacenterId = datacenterId;
this.workerId = workerId;
}
}
上面代码用左移和取反构造了每段的最大掩码。例如~(-1L << 5)得到二进制低5位全1，用来限制传入的机器编号不越界。偏移量则决定每段最终在long中处于什么位置。
构造函数仅做参数校验，真正的发号逻辑放在下一个方法。这样的结构清晰，也方便单元测试时注入固定的机器编号。
核心发号方法实现
nextId()方法需要解决三个问题：获取当前毫秒、处理同一毫秒的序列自增、应对时钟回拨。下面给出基础且健壮的实现。
public synchronized long nextId() {
long current = System.currentTimeMillis();
if (current < lastTimestamp) {
// 时钟回拨，抛出异常或等待
throw new RuntimeException("时钟回拨，拒绝生成ID");
}
if (current == lastTimestamp) {
sequence = (sequence + 1) & maxSequence;
if (sequence == 0) {
// 当前毫秒序列用尽，等到下一毫秒
current = waitNextMillis(lastTimestamp);
}
} else {
sequence = 0L;
}
lastTimestamp = current;
return ((current - epoch) << timestampShift)
| (datacenterId << datacenterShift)
| (workerId << workerShift)
| sequence;
}
private long waitNextMillis(long last) {
long now = System.currentTimeMillis();
while (now <= last) {
now = System.currentTimeMillis();
}
return now;
}
方法用synchronized保证单实例内线程安全。如果同一毫秒内请求过多导致序列溢出，就自旋等待到下一毫秒，从而不重复。最终ID通过左移加按位或拼装，各段互不干扰。
时钟回拨在虚拟机迁移或NTP校时时可能发生。简单实现直接抛异常，生产环境可记录日志并短暂休眠，或借助历史最大时间戳继续发号，但需评估安全性。
优化与落地建议
若系统QPS极高，synchronized可能成为瓶颈。可改用AtomicLong配合CAS，或给每个线程分配独立workerId。另外，机器ID建议从配置中心或启动脚本注入，不要写死在代码里。
相比于依赖数据库或Redis的方案，雪花算法无外部依赖、延迟极低，但必须保证各节点时间基本同步。配合监控告警，及时发现时钟异常，就能在大部分分布式场景中稳定提供全局ID。