简单读取一下系统时间，能有多大影响？

会员服务 ·

简单读取一下系统时间，能有多大影响？

2019 年 4 月 22 日 余晟以为

Image by Monoar Rahman Rony from Pixabay

在IT行业有一些大神极人物，他们多半有一些妖娆的行为，平常人看起来是毫无逻辑的。

我的一个朋友就曾亲历过这样的事情。一段程序无论怎么优化响应速度也上不去了，满足不了业务需求，大家抓耳挠腮、一筹莫展，只好“斗胆”求教大神。大神仔细端详了半天代码，也没说出个所以然来。

大家正在失望，哀叹“不过如此”的时候，大神幽幽念了一句：把取系统时间的那行给注释掉看看。

什么？大家都以为听错了——取系统时间会影响性能？这不应该是一个很轻量很轻量的操作吗？再说，无数的书上都是这样获取系统时间的，难道还会有问题吗？

无论如何，姑且死马当成活马医，试试看吧。

注释掉这段代码再测试，性能瓶颈果真消除了……

实话说，我虽然很早听过这段经历，但那个朋友复述时，只是强调大神有多么多么强，到底当时是什么情况，其中是什么原理（大神说过，但他给忘了），他也没有说出个所以然来。

不过我想，大神一定不是单纯从写代码的角度来发现问题的，而是深入知道背后的实现原理。这方面的问题，我也确实知道一点。

起码，对Java语言来说，System.nanoTime()和System.currentTimeMillis()确实是不一样的。而且两者的优劣不能一概而论，要依据操作系统的不同来做具体的分析和取舍。比如在Window上，System.currentTimeMillis()可能要比Linux上快200倍（2017年github上有人发了测试结果，引起了广泛的讨论）；而在有些情况下，System.currentTimeMillis()是一定不要做的选择。

github上那篇引起广泛讨论的文章（片段）

为什么会这样？要说清楚它，需要知道系统里的时钟类型。一种是monotonic clock（单调时间），表示系统启动以来经历的时间，这个值只会单调增加；还有一种是wall clock，即挂钟时间，表示人看得懂的、有社会意义的时间，正常情况下它也是单调增加的，但如果遇到手动调整或者自动校准等情况，其取值是可能波动的。

所以如果你希望获得的是有文化意义的时间，应当调用System.currentTimeMillis()来获取，如果只是单纯计时，调用System.nanoTime()反而更快。

实际上，Oracle官方网站上已经有这个bug：JDK-8185891，因为System.currentTimeMillis()在Linux上，基于历史原因，其实现是调用的gettimeoftheday。这个问题会影响JDK 8、9、10，如果是时间敏感型应用，影响可能会很严重，尤其在用到了HPET（Hight Precision Event Timer）的系统上更是如此。

官网截图

如果你对这类问题有兴趣，光看编程语言的书恐怕还不够。因为在计算机的世界里，代码之下还有太多复杂的因素，涉及到计算机体系结构的部分，如果不了解，可能会面对某些问题束手无策。

如今极客时间推出了计算机组成原理的课程。老规矩，在我这露个脸。

下面是课程的介绍，如果你之前就希望了解组成原理，或者觉得大纲编排符合自己的要求，或者觉得作者讲的问题让你感兴趣，不妨考虑下——原价99元，目前优惠只要68元。

这门课的作者是徐文浩，一个目前正在创业的工程师。7岁开始接触代码，近30年的码龄，毕业于上海交通大学计算机系，在 Trilogy Software 写过各种大型企业软件，也曾任 MediaV 技术总监，从零开始搭建支撑每天百亿流量的广告算法系统，提升了十倍以上的广告收入和 ROI；2016年底进军人工智能领域，创办 BotHub.AI，成为唯一进入 F8 大会开发者代表的中国公司。