需求:获取一段程序运行的时间。
原理:获取程序开始和结束的时间并相减即可。
当代码完成优化后,就可以解决这类问题。
这种方式,模版方法设计模式。
什么是模版方法呢?
在定义功能时,功能的一部分是确定的,但是有一部分是不确定,而确定的部分在使用不确定的部分,
那么这时就将不确定的部分暴露出去。由该类的子类去完成。
*/
abstract class GetTime
{
public final void getTime()
{
long start = System.currentTimeMillis();
runcode();
long end = System.currentTimeMillis();
System.out.println("毫秒:"+(end-start));
}
public abstract void runcode();
}class SubTime extends GetTime
{
public void runcode()
{
for(int x=0; x<4000; x++)
{
System.out.print(x);
}
}
}
class TemplateDemo
{
public static void main(String[] args)
{
//GetTime gt = new GetTime();
SubTime gt = new SubTime();
gt.getTime();
}
}
附:
Java 编程语言有一个计时方法,从早期版本起它就是标准 API 的一部分。 这个方法是 java.lang.System.currentTimeMillis(),它返回从 UTC 1970 年 1 月 1 日午夜开始经过的毫秒数。这个方法非常有用,特别 是它在各个版本的 Java 平台上都有。因此,在 上个月 我的 初始方面演示代码中,我使用了它。不过,currentTimeMillis() 也有 一些缺点。
currentTimeMillis() 的一个问题是,它虽然是以毫秒计数返回 时间,但是不能保证返回的计数的粒度或精度。在一些系统上,时间是真正的毫 秒计数,大约每一毫秒改变一次。在另一些系统上,时间可能每隔 10 或 20 毫秒才变一 次,因此每一次的精度都可能变化。
另一个局限是在方法定义中的基本时间单位。当 Java 平台第一次开始使用时,一毫秒 仍然是相当短的时间间隔(特别是对于解释语言)。今天,随着 CPU 时钟速度比第一次发布 Java 平台时快了近一百倍,一毫秒已经成了相对长的一段时间。
除了 currentTimeMillis() 的这些问题, 还有另一个使用任何类型的计时器方法监视程序执行都会有的问题。这个问题 是计时器方法本身 —— 可能要深入操作系统才能访问计时器 —— 这增加了一些开销, 如果计时器方法开销过大(或者方法调用过于频繁),那么就会严重扭曲计时测量。 为了明智地使用我们的性能跟踪方面,需要至少大体知道计时器方法调用增加 了多少开销。