Java系统时钟几个值得思考的问题

System.currentTimeMillis()是依赖于系统时钟的，也就是说，如果你把自己的系统时钟更改了，这个函数的返回会立即生效，变成更改后的值；

System.nanoTime()主要用于记录一个时间段的长度，或者说一个超时，在这个过程中，你更改系统时钟也不会影响。

两个方法的精度一个是毫秒，一个是纳秒，但都是不靠普的（有些系统的时间粒度是10ms），nanoTime()的调用也会消耗几微妙，所以不靠普；

但粒度不是我讨论的重点。

 

我们程序中的timer是很常用的功能，归根到底到下面的API：

 

LockSupport. public static void parkNanos(long nanos) 

 和

  

Thread.sleep(long millis)

 

  还有Object.wait

 

不幸的是，但它们都是基于系统时钟的。

下面是我的测试，这个测试的过程是：启动后等待10秒钟，然后打印等待的时间：

	public static void main(String[] args) throws InterruptedException {
		long s = System.nanoTime();
		int _10sec = 10 * 1000;
		LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(_10sec));
		long e = System.nanoTime();
		long used = e - s;
		System.out.println("Used:" + TimeUnit.NANOSECONDS.toMillis(used));
	}

 在运行上面程序之后，在系统命令行执行下面命令重置时间：

[atlas@atlas-pc ~]$ date && sudo date -s 16:10:40
2013年 04月 10日 星期三 16:10:57 CST
2013年 04月 10日 星期三 16:10:40 CST

 java程序输出：Used:27889

我把时钟向前拨了17s，一个park10s的程序27秒后才结束；

同样的，测试Thread:

	public static void main(String[] args) throws InterruptedException {
		long s = System.nanoTime();
		int _10sec = 10 * 1000;
		Thread.sleep(_10sec);
		long e = System.nanoTime();
		long used = e - s;
		System.out.println("Used:" + TimeUnit.NANOSECONDS.toMillis(used));
	}

 运行后，重置时钟：

[atlas@atlas-pc ~]$ date && sudo date -s 16:33:40
2013年 04月 10日 星期三 16:34:03 CST
2013年 04月 10日 星期三 16:33:40 CST

 

java程序输出：Used:33569

 

这篇文章介绍了系统时钟和Java里面的几个API。

 

结论：

当我们重置服务器的时间(有些是通过网络同步的)，

1，那些依赖系统时钟的程序（timer，scheduler,etc）会出现问题，

2，依赖时间判断的心跳会出问题，

 

UPDATE:

经过后期的测试，发现只有在linux下有上面的问题，MAC和windows都没有。

后面我做了一个sleep程序，调用系统的sleep 命令，然后Porcess.waitFor()，可以避免时间往前拨的问题。

可以用于一些非常关键的Java Timer的调度。

 

 

 

评论

1 楼 OpenMind 2014-05-07  

发现IBM JDK的System.nanoTime()没有实现 API描述的 “not related to any other notion of system or wall-clock time” 它是依赖系统时钟的，就是从System.currentTimeMillis()直接换算过去的。妈的。