System.currentTimeMillis应用：如何生成全局唯一ID

先说一个许多人都踩过的坑：用System.currentTimeMillis()直接生成全局唯一ID，这在系统并发量一上来的时候就现原形了——毫秒级的精度，同一毫秒里多线程一搅，ID重复是必然的。不过话说回来，这个时间戳本身其实很有价值，问题不在于“能不能用”，而在于“怎么用好它”。

为什么时间戳必须搭配其他因子

Ja va里的System.currentTimeMillis()返回的是从1970年开始的毫秒数，13位数字序列，时间天然有序、肉眼可读，非常方便。但它有几个硬伤：

• 单JVM内部，多个线程同时调用，拿到的值一模一样
• 跨JVM、跨多个服务实例跑起来，完全没办法区分来源
• 毫秒级精度在今天的服务规模下已经不够用了——QPS只要过万，碰撞概率直线上升

所以，解决问题的关键就是给时间戳补上“毫秒内的序号”和“机器/进程标识”。换句话说，把时间戳从一个可能重复的基础值，变成一个结构化的锚点。

推荐组合结构：13位时间戳 + 3–5位序列号 + 2–4位机器ID

以下这种结构是目前最实用的方案之一：在唯一性、长度（通常不超过20位）和日常日志排查、数据库索引友好这几方面都平衡得不错。

• 时间戳部分：用System.currentTimeMillis() - START_EPOCH做一个偏移，比如从2024-01-01起步，这样可以把数字压缩到13位以内，避免位数太长
• 序列号部分：用AtomicInteger每毫秒自增计数，上限设成999（3位）或99999（5位），如果溢出了就等到下一毫秒继续
• 机器标识部分：可以取本机IP的后两位进行哈希、截取Docker容器ID的一部分，或者直接配一个固定字符串，比如"01"。2–4位足够区分同机房里常见的部署规模了

举个例子，生成出来的ID就像这样：182456789012304201（13位时间+3位序号+2位机器号）。

不建议的两种常见错误用法

有些做法看起来简单直接，实则在生产环境里容易出问题：

• 直接拼接UUID：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生成器，而且代码改动量极小。