Java 编程语言有一个计时方法,从早期版本起它就是标准 API 的一部分。 这个方法是 java.lang.System.currentTimeMillis(),它返回从 UTC 1970 年 1 月 1 日午夜开始经过的毫秒数。这个方法非常有用,特别 是它在各个版本的 Java 平台上都有。因此,在 上个月
currentTimeMillis() 的一个问题是,它虽然是以毫秒计数返回时间,但是不能保证返回的计数的粒度或精度。在一些系统上,时间是真正的毫 秒计数,大约每一毫秒改变一次。在另一些系统上,时间可能每隔 10 或 20 毫秒才变一 次,因此每一次的精度都可能变化。
另一个局限是在方法定义中的基本时间单位。当 Java 平台第一次开始使用时,一毫秒仍然是相当短的时间间隔(特别是对于解释语言)。今天,随着 CPU 时钟速度比第一次发布 Java 平台时快了近一百倍,一毫秒已经成了相对长的一段时间。
除了 currentTimeMillis() 的这些问题, 还有另一个使用任何类型的计时器方法监视程序执行都会有的问题。这个问题是计时器方法本身 —— 可能要深入操作系统才能访问计时器 —— 这增加了一些开销,如果计时器方法开销过大(或者方法调用过于频繁),那么就会严重扭曲计时测量。为了明智地使用我们的性能跟踪方面,我需要至少大体知道计时器方法调用增加 了多少开销。