前面已经讲过了雪花算法，里面使用了System.currentTimeMillis()获取时间，有一种说法是认为System.currentTimeMillis()慢，是因为每次调用都会去跟系统打一次交道，在高并发情况下，大量并发的系统调用容易会影响性能（对它的调用甚至比new一个普通对象都要耗时，毕竟new产生的对象只是在Java内存中的堆中）。我们可以看到它调用的是native 方法：

// 返回当前时间，以毫秒为单位。注意，虽然返回值的时间单位是毫秒，但值的粒度取决于底层操作系统，可能更大。例如，许多操作系统以数十毫秒为单位度量时间。 public static native long currentTimeMillis();

所以有人提议，用后台线程定时去更新时钟，并且是单例的，避免每次都与系统打交道，也避免了频繁的线程切换，这样或许可以提高效率。
这个优化成立么？ 【雪花算法对System.currentTimeMillis()优化真的有用么（）】先上优化代码：

package snowflake; import java.util.concurrent.Executors; import java.util.concurrent.ScheduledExecutorService; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicLong; public class SystemClock {private final int period; private final AtomicLong now; private static final SystemClock INSTANCE = new SystemClock(1); private SystemClock(int period) { this.period = period; now = new AtomicLong(System.currentTimeMillis()); scheduleClockUpdating(); }private void scheduleClockUpdating() { ScheduledExecutorService scheduleService = Executors.newSingleThreadScheduledExecutor((r) -> { Thread thread = new Thread(r); thread.setDaemon(true); return thread; }); scheduleService.scheduleAtFixedRate(() -> { now.set(System.currentTimeMillis()); }, 0, period, TimeUnit.MILLISECONDS); }private long get() { return now.get(); }public static long now() { return INSTANCE.get(); }}

只需要用SystemClock.now()替换System.currentTimeMillis()即可。
雪花算法SnowFlake的代码也放在这里：

package snowflake; public class SnowFlake {// 数据中心(机房) id private long datacenterId; // 机器ID private long workerId; // 同一时间的序列 private long sequence; public SnowFlake(long workerId, long datacenterId) { this(workerId, datacenterId, 0); }public SnowFlake(long workerId, long datacenterId, long sequence) { // 合法判断 if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId)); } if (datacenterId > maxDatacenterId || datacenterId < 0) { throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId)); } System.out.printf("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d", timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId); this.workerId = workerId; this.datacenterId = datacenterId; this.sequence = sequence; }// 开始时间戳（2021-10-16 22:03:32） private long twepoch = 1634393012000L; // 机房号，的ID所占的位数 5个bit 最大:11111(2进制)--> 31(10进制) private long datacenterIdBits = 5L; // 机器ID所占的位数 5个bit 最大:11111(2进制)--> 31(10进制) private long workerIdBits = 5L; // 5 bit最多只能有31个数字，就是说机器id最多只能是32以内 private long maxWorkerId = -1L ^ (-1L << workerIdBits); // 5 bit最多只能有31个数字，机房id最多只能是32以内 private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits); // 同一时间的序列所占的位数 12个bit 111111111111 = 4095最多就是同一毫秒生成4096个 private long sequenceBits = 12L; // workerId的偏移量 private long workerIdShift = sequenceBits; // datacenterId的偏移量 private long datacenterIdShift = sequenceBits + workerIdBits; // timestampLeft的偏移量 private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits; // 序列号掩码 4095 (0b111111111111=0xfff=4095) // 用于序号的与运算，保证序号最大值在0-4095之间 private long sequenceMask = -1L ^ (-1L << sequenceBits); // 最近一次时间戳 private long lastTimestamp = -1L; // 获取机器ID public long getWorkerId() { return workerId; }// 获取机房ID public long getDatacenterId() { return datacenterId; }// 获取最新一次获取的时间戳 public long getLastTimestamp() { return lastTimestamp; }// 获取下一个随机的ID public synchronized long nextId() { // 获取当前时间戳，单位毫秒 long timestamp = timeGen(); if (timestamp < lastTimestamp) { System.err.printf("clock is moving backwards.Rejecting requests until %d.", lastTimestamp); throw new RuntimeException(String.format("Clock moved backwards.Refusing to generate id for %d milliseconds", lastTimestamp - timestamp)); }// 去重 if (lastTimestamp == timestamp) {sequence = (sequence + 1) & sequenceMask; // sequence序列大于4095 if (sequence == 0) { // 调用到下一个时间戳的方法 timestamp = tilNextMillis(lastTimestamp); } } else { // 如果是当前时间的第一次获取，那么就置为0 sequence = 0; }// 记录上一次的时间戳 lastTimestamp = timestamp; // 偏移计算 return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence; }private long tilNextMillis(long lastTimestamp) { // 获取最新时间戳 long timestamp = timeGen(); // 如果发现最新的时间戳小于或者等于序列号已经超4095的那个时间戳 while (timestamp <= lastTimestamp) { // 不符合则继续 timestamp = timeGen(); } return timestamp; }private long timeGen() { return SystemClock.now(); // return System.currentTimeMillis(); }public static void main(String[] args) { SnowFlake worker = new SnowFlake(1, 1); long timer = System.currentTimeMillis(); for (int i = 0; i < 10000000; i++) { worker.nextId(); } System.out.println(System.currentTimeMillis()); System.out.println(System.currentTimeMillis() - timer); } }

Windows：i5-4590 16G内存 4核 512固态
Mac: Mac pro 2020 512G固态 16G内存
Linux：deepin系统，虚拟机，160G磁盘，内存8G
单线程环境测试一下 System.currentTimeMillis()：

平台/数据量	10000	1000000	10000000	100000000
mac	5	247	2444	24416
windows	3	249	2448	24426
linux(deepin)	135	598	4076	26388

单线程环境测试一下 SystemClock.now()：

平台/数据量	10000	1000000	10000000	100000000
mac	52	299	2501	24674
windows	56	3942	38934	389983
linux(deepin)	336	1226	4454	27639

上面的单线程测试并没有体现出后台时钟线程处理的优势，反而在windows下，数据量大的时候，变得异常的慢,linux系统上，也并没有快，反而变慢了一点。
多线程测试代码：

public static void main(String[] args) throws InterruptedException { int threadNum = 16; CountDownLatch countDownLatch = new CountDownLatch(threadNum); int num = 100000000 / threadNum; long timer = System.currentTimeMillis(); thread(num, countDownLatch); countDownLatch.await(); System.out.println(System.currentTimeMillis() - timer); }public static void thread(int num, CountDownLatch countDownLatch) { List threadList = new ArrayList<>(); for (int i = 0; i < countDownLatch.getCount(); i++) { Thread cur = new Thread(new Runnable() { @Override public void run() { SnowFlake worker = new SnowFlake(1, 1); for (int i = 0; i < num; i++) { worker.nextId(); } countDownLatch.countDown(); } }); threadList.add(cur); } for (Thread t : threadList) { t.start(); } }

下面我们用不同线程数来测试 100000000(一亿) 数据量 System.currentTimeMillis()：

平台/线程	2	4	8	16
mac	14373	6132	3410	3247
windows	12408	6862	6791	7114
linux	20753	19055	18919	19602

用不同线程数来测试 100000000(一亿) 数据量 SystemClock.now()：

平台/线程	2	4	8	16
mac	12319	6275	3691	3746
windows	194763	110442	153960	174974
linux	26516	25313	25497	25544

在多线程的情况下，我们可以看到mac上没有什么太大变化，随着线程数增加，速度还变快了，直到超过 8 的时候，但是windows上明显变慢了，测试的时候我都开始刷起了小视频，才跑出来结果。而且这个数据和处理器的核心也是相关的，当windows的线程数超过了 4 之后，就变慢了，原因是我的机器只有四核，超过了就会发生很多上下文切换的情况。
linux上由于虚拟机，核数增加的时候，并无太多作用，但是时间对比于直接调用 System.currentTimeMillis()其实是变慢的。
但是还有个问题，到底不同方法调用，时间重复的概率哪一个大呢？

static AtomicLong atomicLong = new AtomicLong(0); private long timeGen() { atomicLong.incrementAndGet(); // return SystemClock.now(); return System.currentTimeMillis(); }

下面是1千万id，八个线程，测出来调用timeGen()的次数，也就是可以看出时间冲突的次数：

平台/方法	SystemClock.now()	System.currentTimeMillis()
mac	23067209	12896314
windows	705460039	35164476
linux	1165552352	81422626

可以看出确实SystemClock.now()自己维护时间，获取的时间相同的可能性更大，会触发更多次数的重复调用，冲突次数变多，这个是不利因素！还有一个残酷的事实，那就是自己定义的后台时间刷新，获取的时间不是那么的准确。在linux中的这个差距就更大了，时间冲突次数太多了。
结果 实际测试下来，并没有发现SystemClock.now()能够优化很大的效率，反而会由于竞争，获取时间冲突的可能性更大。JDK开发人员真的不傻，他们应该也经过了很长时间的测试，比我们自己的测试靠谱得多，因此，个人观点，最终证明这个优化并不是那么的可靠。
不要轻易相信某一个结论，如果有疑问，请一定做做实验，或者找足够权威的说法。
【作者简介】：
秦怀，公众号【秦怀杂货店】作者，技术之路不在一时，山高水长，纵使缓慢，驰而不息。个人写作方向：Java源码解析，JDBC，Mybatis，Spring，redis，分布式，剑指Offer，LeetCode等，认真写好每一篇文章，不喜欢标题党，不喜欢花里胡哨，大多写系列文章，不能保证我写的都完全正确，但是我保证所写的均经过实践或者查找资料。遗漏或者错误之处，还望指正。
剑指Offer全部题解PDF
2020年我写了什么？
开源编程笔记

推荐阅读

• 

  糖尿病并发症|糖尿病眼病不重视会致盲？4种高发眼病需警惕，预防不能少
• 

  虚拟机虚拟苹果系统，虚拟机装苹果操作系统
• 

  火龙果常温能放多久 火龙果常温可以放多久
• 

  微视直播怎么开通橱窗卖货的简单介绍
• 

  高考提前录取是什么意思 提前批次录取是什么意思
• 

  测测你的另一半 测测你另一半的长相
• 

  安卓微信好友备份软件下载，安卓微信备份工具
• 

  2019-10-20小说就是生活
• 

  液化气钢瓶爆炸是属于什么爆炸
• 

  回忆是美好的,现实是残酷的意思 残酷的意思
• 

  主播聊天话术900句 新人直播不冷场的技巧
• 

  女性结肠炎吃什么药
• 

  绞股蓝加牛蒡可以一起喝吗？有什么效果？
• 

  海尔冰箱故障图显示E1
• 

  找出n个自然数中（1,2,3，……，n）中取r个数的组合。eg（n=5，r=3 时组合数为10）
• 

  被误判黄码怎么办
• 

  FGO影之国圣杯战线第四天攻略 FGO圣杯战线9月20日1级通关流程
• 

  掏耳朵能引起咳嗽吗 为什么掏耳朵会咳嗽
• 

  纳智捷大7值得购买吗 纳智捷大7怎么样
• 

  葱爷说股20190107

• 布丽吉特，人生绝对的赢家
• 进必趋|进必趋 退必迟，问起对 视勿移
• 对称加密和非对称加密的区别
• 对抗抑郁最好的方法
• 画解算法（1.|画解算法：1. 两数之和）
• 装聋作哑，关系融洽
• Guava|Guava RateLimiter与限流算法
• 社保代缴公司服务费包含哪些
• 数组常用方法一
• 错过（一）