利用System.currentTimeMillis生成全局唯一ID时,需结合毫秒内序列号和机器标识,避免高并发下同一毫秒内重复。推荐结构为13位偏移时间戳加3-5位序号与2-4位机器ID,长度可控且索引友好。不推荐直接拼接UUID或裸用时间戳,前者导致过长不友好,后者在微服务中易重复。
先说一个许多人都踩过的坑:用System.currentTimeMillis()直接生成全局唯一ID,这在系统并发量一上来的时候就现原形了——毫秒级的精度,同一毫秒里多线程一搅,ID重复是必然的。不过话说回来,这个时间戳本身其实很有价值,问题不在于“能不能用”,而在于“怎么用好它”。
Java里的System.currentTimeMillis()返回的是从1970年开始的毫秒数,13位数字序列,时间天然有序、肉眼可读,非常方便。但它有几个硬伤:
长期稳定更新的攒劲资源: >>>点此立即查看<<<
所以,解决问题的关键就是给时间戳补上“毫秒内的序号”和“机器/进程标识”。换句话说,把时间戳从一个可能重复的基础值,变成一个结构化的锚点。
以下这种结构是目前最实用的方案之一:在唯一性、长度(通常不超过20位)和日常日志排查、数据库索引友好这几方面都平衡得不错。
System.currentTimeMillis() - START_EPOCH做一个偏移,比如从2024-01-01起步,这样可以把数字压缩到13位以内,避免位数太长AtomicInteger每毫秒自增计数,上限设成999(3位)或99999(5位),如果溢出了就等到下一毫秒继续"01"。2–4位足够区分同机房里常见的部署规模了举个例子,生成出来的ID就像这样:182456789012304201(13位时间+3位序号+2位机器号)。
有些做法看起来简单直接,实则在生产环境里容易出问题:
System.currentTimeMillis() + UUID.randomUUID().toString(),结果里既有横线又有字母,长度超过36位,检索困难、索引膨胀、前端展示也不友好Long.toString(System.currentTimeMillis()),毫秒级重复的问题在微服务调用链里非常突出,订单、支付这些敏感场景更是大忌如果确实想引入UUID的随机性做辅助,可以只取它的leastSignificantBits,转成Base32或者紧凑的数字串(大概12–14位),作为“扰动因子”嵌到ID的后半段,而不是直接拿整个UUID往上拼。
不依赖外部组件,适合内聚度高、但不需要严格跨集群的场景:
public class BusinessSeqGenerator {
private static final long START_EPOCH = 1704067200000L; // 2024-01-01
private static final AtomicInteger seqInMs = new AtomicInteger(0);
private static final int MAX_SEQ = 999;
private static final String MACHINE_ID = "01";
public static String generate() {
long currentMs = System.currentTimeMillis() - START_EPOCH;
int seq = seqInMs.incrementAndGet() % (MAX_SEQ + 1);
if (seq == 0) {
try { Thread.sleep(1); } catch (InterruptedException e) { }
return generate();
}
return String.format("%013d%03d%s", currentMs, seq, MACHINE_ID);
}
}
如果要跨JVM跑起来,只需要把MACHINE_ID换成真实的实例标识,比如Spring Cloud的spring.application.instance-id或者Consul注册ID,这套方案就能升级成一个近似全局唯一的ID生成器,而且代码改动量极小。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述