先让程序睡上 30 秒
从字面意思看,想必你已经猜出来 sleep 命令的作用啦。简单地说,sleep 就是让程序稍稍休息一下,然后,再继续工作(休息是为了更好地工作……)。
我们让 Shell 程序小憩 30 秒:
#睡眠30秒 [roc@roclinux ~]$ sleep 30s #让date命令来监督, 看看是不是真的睡了30秒 [roc@roclinux ~]$ date;sleep 30s; date Thu Feb 25 08:25:17 CST 2016 Thu Feb 25 08:25:47 CST 2016
睡眠时间个性化
sleep 命令虽然简单,但我们可以对它进行个性化定制,让它变得更好玩一些。
一般来说,sleep 命令后面跟的数值是用来表示时间的,是时间就要有单位,如果我们不指定单位的话,它默认的单位是什么呢?
[roc@roclinux ~]$ date; sleep 1; date Thu Feb 25 09:55:47 CST 2016 Thu Feb 25 09:55:48 CST 2016
从这个示例来看,默认的单位就是秒啦,和指定单位 s 有同等的效果。
有秒的话,还应该有分钟和小时才对,那这些单位在 sleep 中如何表示呢?
- s:表示秒
- m:表示分钟
- h:表示小时
- d:表示天
比如,如果想让 Shell 程序睡眠 1 分钟,应该如何操作呢?
[roc@roclinux ~]$ date; sleep 1m; date Thu Feb 25 10:00:43 CST 2016 Thu Feb 25 10:01:43 CST 2016
那如果想让 shell 程序睡眠 1 小时的话,直接把单位换成 h 就可以了。如果我们想让 shell 程序睡眠 1 分 40 秒,又该怎么操作呢?1 分=60 秒,1 分 40 秒=100 秒,可以直接让计算机睡眠 100 秒。
[roc@roclinux ~]$ date; sleep 100; date Thu Feb 25 10:12:28 CST 2016 Thu Feb 25 10:14:08 CST 2016
其实呢,sleep 比你想象得还要体贴,你可以直接这样输入:
#注意: 分钟和秒之间一定要有空格哦 [roc@roclinux ~]$ date; sleep 1m 40s; date Thu Feb 25 10:17:04 CST 2016 Thu Feb 25 10:18:44 CST 2016
这种方法简单、直接,节省了我们不少的思考时间。
在 sleep 中最大的单位是 d(天),如果想表示更长的时间,比如周、月、年的话,那么你只能把它们转换成天来表示了。
# 这样, Shell程序乖乖地沉睡 "一周2小时5分4秒" [roc@roclinux ~]$ date; sleep 7d 2h 5m 4s; date Thu Feb 25 10:17:04 CST 2016 Thu Feb 25 10:18:44 CST 2016
毫秒级睡眠时间可不可以
sleep 命令的默认时间单位是秒,但对于高速运行的程序来说,“秒”还是显得太长了。那 sleep 能不能实现毫秒级的睡眠呢?答案是可以的,例如,我们让 Shell 程序睡眠 3 毫秒:
[roc@roclinux ~]$ time sleep 0.003 real 0m0.004s user 0m0.000s sys 0m0.001s
time 可以通过浮点数的方式实现毫秒级的睡眠,但这里有一点需要注意,即睡眠时间的精度。sleep 命令只能保证 10ms 级别的精度控制,对于小于 10ms 的睡眠时间是存在误差的。实际应用中,如果你对时间精度要求特别高的话,sleep 或许不是一个正确的选择,还是请考虑其他方法吧。
sleep 的过程中 CPU 是否被占用
默认情况下,sleep 的进程是不占用 CPU 时间的,我们可以通过实验来说明这个问题:
[roc@roclinux ~]$ /time sleep 1 0.00user 0.00system 0:01.00elapsed 0%CPU (0avgtext+0avgdata 2560maxresident)k 0inputs+0outputs (0major+200minor)pagefaults 0swaps
看到了吗?0.00user、0.00system、0%CPU 这三个输出项都表明 sleep 是不会耗费 CPU 的计算资源的。
注意:上面使用了/time
命令,它指代的是 /usr/bin/time,而不是 Shell 内置的 time 命令。/usr/bin/time 命令可以显示更多的信息,而 Shell 内置的命令做不到这一点。
原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/21833.html