雪花算法对System.currentTimeMillis()优化真的有用么?
前面已经讲过了雪花算法,里面使用了System.currentTimeMillis()
获取时间,有一种说法是认为System.currentTimeMillis()
慢,是因为每次调用都会去跟系统打一次交道,在高并发情况下,大量并发的系统调用容易会影响性能(对它的调用甚至比new
一个普通对象都要耗时,毕竟new
产生的对象只是在Java
内存中的堆中)。我们可以看到它调用的是native
方法:
所以有人提议,用后台线程定时去更新时钟,并且是单例的,避免每次都与系统打交道,也避免了频繁的线程切换,这样或许可以提高效率。
这个优化成立么?
先上优化代码:
只需要用SystemClock.now()
替换System.currentTimeMillis()
即可。
雪花算法SnowFlake
的代码也放在这里:
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系统上,也并没有快,反而变慢了一点。
多线程测试代码:
下面我们用不同线程数来测试 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()
其实是变慢的。
但是还有个问题,到底不同方法调用,时间重复的概率哪一个大呢?
下面是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
等,认真写好每一篇文章,不喜欢标题党,不喜欢花里胡哨,大多写系列文章,不能保证我写的都完全正确,但是我保证所写的均经过实践或者查找资料。遗漏或者错误之处,还望指正。
__EOF__

本文链接:https://www.cnblogs.com/Damaer/p/15626781.html
关于博主:评论和私信会在第一时间回复。或者直接私信我。
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
声援博主:如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力!
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库