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