Suave’s Blog

Sun出品的XML Mark是我第一次接触performance test的内容，提到performance自然少不了记录时间，在XML Mark中Agent Thread在开始run的时候会用System.currentTimeMillis()记录当前时间，google一下，发现了下面这断文字：

Java 编程语言有一个计时方法，从早期版本起它就是标准 API 的一部分。 这个方法是 java.lang.System.currentTimeMillis()，它返回从 UTC 1970 年 1 月 1 日午夜开始经过的毫秒数。这个方法非常有用，特别 是它在各个版本的 Java 平台上都有。因此，在 上个月 我的 初始方面演示代码中，我使用了它。不过，currentTimeMillis() 也有 一些缺点。

currentTimeMillis() 的一个问题是，它虽然是以毫秒计数返回 时间，但是不能保证返回的计数的粒度或精度。在一些系统上，时间是真正的毫 秒计数，大约每一毫秒改变一次。在另一些系统上，时间可能每隔 10 或 20 毫秒才变一 次，因此每一次的精度都可能变化。

另一个局限是在方法定义中的基本时间单位。当 Java 平台第一次开始使用时，一毫秒 仍然是相当短的时间间隔（特别是对于解释语言）。今天，随着 CPU 时钟速度比第一次发布 Java 平台时快了近一百倍，一毫秒已经成了相对长的一段时间。

除了 currentTimeMillis() 的这些问题， 还有另一个使用任何类型的计时器方法监视程序执行都会有的问题。这个问题 是计时器方法本身 —— 可能要深入操作系统才能访问计时器 —— 这增加了一些开销， 如果计时器方法开销过大（或者方法调用过于频繁），那么就会严重扭曲计时测量。 为了明智地使用我们的性能跟踪方面，我需要至少大体知道计时器方法调用增加 了多少开销。

上面的说明来自IBM Develop的一篇文章，原文链接 ，English Version