System.currentTimeMillis()毫秒级精度不足导致高并发重复，需结合机器ID、序列号与时间戳位运算生成唯一ID，并做时钟回拨、溢出、越界等边界校验。
为什么 System.currentTimeMillis() 直接拼序列号会重复
时间精度不够，尤其是高并发下同一毫秒内多次调用，System.currentTimeMillis() 返回值完全一样。这时候只靠递增序列号还行，但一旦服务重启、多节点部署或线程调度抖动，序列号就可能重置或错乱。
实操建议：
- 别用
static int seq = 0简单自增——线程不安全，且重启归零 - 用
AtomicInteger或带锁的long原子变量维护序列号，初始值设为0，每次取完立刻incrementAndGet() - 序列号位数要预留余量，比如用 12 位（0–4095），超了就等下一毫秒，而不是暴力进位
- 关键逻辑必须包裹在同步块或 CAS 循环里，确保“读时间→读序列→生成→更新序列”是原子的
怎么让时间戳部分支持多机部署不冲突
单机靠 System.currentTimeMillis() 够用，但两台机器在同一毫秒生成 ID，序列号又各自从 0 开始，必然重复。必须引入机器标识，常见做法是把时间戳左移后，空出低位填上机器 ID 和序列号。
实操建议：
- 时间戳截取到毫秒即可，用
System.currentTimeMillis() - START_EPOCH（START_EPOCH是自定义的基准时间，避免高位全是 0） - 给每台机器分配唯一
workerId（如 0–31），占 5 位；序列号占 12 位；剩下 41 位留给时间差——这样总长 63 位，能塞进long - 不要硬编码
workerId，启动时通过配置、环境变量或 ZooKeeper 分配，避免人工误配 - 如果没中心协调服务，至少校验本地
workerId是否已被其他进程占用（比如检查某个临时文件或端口）
nextId() 方法里最常漏掉的边界检查
看起来只是“取时间、加序列、拼整数”，但实际运行中，时间可能回拨（NTP 同步、虚拟机休眠）、序列号可能溢出、workerId 可能越界——这些不拦截，ID 就直接错，而且错误不可逆。
实操建议：
- 每次获取时间后，和上次记录的
lastTimestamp比较：如果更小，抛RuntimeException("Clock moved backwards")，别沉默等待或强行用旧时间 - 序列号达到上限（如 4095）时，不能继续自增，得循环等待直到
currentTimestamp > lastTimestamp，否则生成的 ID 时间部分反而倒退 -
workerId和datacenterId初始化时就要断言范围，比如if (workerId 31)，立刻 fail-fast - 返回前对最终
longID 做一次& 0x7fffffffffffffffL清符号位——避免高位为 1 导致转字符串时变负数（尤其用在 MySQLBIGINT UNSIGNED场景下）
测试时为什么本地跑 1000 次不重复，压测就撞号
因为本地单线程 or 小并发掩盖了时间精度和竞争问题；压测一上来几十个线程同时抢同一毫秒的序列号槽位，再加 JVM 重排序、CPU 乱序执行，lastTimestamp 和 sequence 的读写就不同步了。
实操建议：
- 单元测试别只用
for (int i = 0; i ，改用 <code>CompletableFuture启 16 个线程各调 100 次，再汇总去重计数 - 在
nextId()开头打日志，输出currentTimestamp、lastTimestamp、sequence，压测时 grep 看有没有相同时间戳下序列号跳变或归零 - 用
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly查看关键字段是否被 JIT 优化成寄存器缓存（导致看不到最新值），必要时加volatile - 真正验证，得把服务部署到两台机器，用 JMeter 同时发请求，比对全量 ID 的 MD5 或直接
SELECT COUNT(*) = COUNT(DISTINCT id)
时间戳和序列号看着简单，但“同一毫秒”“跨线程”“跨机器”“时钟跳变”这四个条件只要凑齐两个，bug 就藏不住。别信“逻辑通顺就行”，得让数据自己说话。
