用clock()函数计时的坑

程序中经常用time()函数来返回当前系统时间的秒数，来计时或计算时间差。如果需要用到更高精度的时间，就会自然想到用clock()函数。想当然的认为它返回从程序开始tick数，用clock()/CLOCKS_PER_SEC就能得到以秒计数的时间了。然而结果不是这样，看下面的程序log。一行开头是系统时间，后面是clock()算出来的，明显比系统时间要慢不少。

2019-03-06 17:47:55.865 16213-18332/ E/jniUtil-jni: cur_time 3.399163
2019-03-06 17:47:56.273 16213-18332/ E/jniUtil-jni: cur_time 3.671865
2019-03-06 17:47:56.722 16213-18332/ E/jniUtil-jni: cur_time 4.006435
2019-03-06 17:47:57.113 16213-18332/ E/jniUtil-jni: cur_time 4.277441
2019-03-06 17:47:57.527 16213-18332/ E/jniUtil-jni: cur_time 4.540576
2019-03-06 17:47:57.928 16213-18332/ E/jniUtil-jni: cur_time 4.775973
2019-03-06 17:47:58.269 16213-18332/ E/jniUtil-jni: cur_time 4.925488
2019-03-06 17:47:58.394 16213-18332/ E/jniUtil-jni: cur_time 4.989181
2019-03-06 17:47:58.488 16213-18332/ E/jniUtil-jni: cur_time 5.023780
2019-03-06 17:47:58.911 16213-18332/ E/jniUtil-jni: cur_time 5.222049
2019-03-06 17:47:59.480 16213-18332/ E/jniUtil-jni: cur_time 5.476535
2019-03-06 17:47:59.980 16213-18332/ E/jniUtil-jni: cur_time 5.724581
2019-03-06 17:48:00.551 16213-18332/ E/jniUtil-jni: cur_time 5.995964
2019-03-06 17:48:00.965 16213-18332/ E/jniUtil-jni: cur_time 6.183607

原因是clock()计算的是从程序运行开始被程序进程使用的CPU时间tick，而不是真正现实世界流逝的时间。很显然这个时间肯定要比现实时间要慢的多，除非CPU只有你这么一个进程在跑，占用了全部CPU。所以如果你要benchmark一段代码，看看运行这段代码花费了多少时间，用clock()很合适。那么要比较精确地计算现实流逝地时间，怎么办呢？用clock_gettime()。

extern int clock_gettime(clockid_t, struct timespec*);

struct timespec {
 __kernel_time_t tv_sec;
 long tv_nsec;
};

第一个参数clockid_t类型常见的有四种：

CLOCK_REALTIME：系统实时时间。
CLOCK_MONOTONIC：从系统启动时开始计时，不受系统时间被用户改变的影响。
CLOCK_PROCESS_CPUTIME_ID：本进程到当前代码系统CPU花费的时间，包含该进程下的所有线程。
CLOCK_THREAD_CPUTIME_ID：本线程到当前代码系统CPU花费的时间。

可以看到，如果用CLOCK_PROCESS_CPUTIME_ID，就和直接用clock()是一样的。而要计算现实时间，就不能用后两种类型，必须用CLOCK_REALTIME或者CLOCK_MONOTONIC。要计算时间差，秒对秒一减，纳秒对纳秒一减，统一到同一个单位相加即可。

除了上面四种clockid_t类型，还有几种。

CLOCK_REALTIME_COARSE，CLOCK_MONOTONIC_COARSE：带COARSE后缀的，精度没有不带后缀的高，但是速度快。

CLOCK_MONOTONIC_RAW：和CLOCK_MONOTONIC类似，但是它是访问的硬件时间，不受NTP时间服务器的调整和adjtime()的影响。

CLOCK_BOOTTIME：和CLOCK_MONOTONIC一样，但是包含系统挂起的时间。