java - 精准消费时间解决方案

Question

考虑以下代码片段

class time implement Runnable{
 long t=0L;
 public void run(){
  try{while(true){Thread.sleep(1000);t++;/*show the time*/}}catch(Throwable t){}
 }
}

////

long long t=0L;
void* time(void* a){//pthread thread start
sleep(1);t++;//show the time
}

我在一些教程中读到，在 Java 中 Thread.sleep(1000) 不正好是 1 秒，如果当时系统很忙，它可能会更多，然后操作系统切换到线程晚了。

问题:
这个案例到底是真的还是假的？
这种情况对于原生 (C/C++) 代码是否相同？
在应用程序中正确计算秒数的方法是什么？

Answer 1

其他人已经回答了时间的准确性。不幸的是，没有保证的方法来 sleep X 时间量，并在 X.00000 秒(或毫秒、纳秒等)时醒来。

要以秒为单位显示时间，您可以将等待的时间缩短为半秒。这样你就不会时不时地跳两秒，因为半秒不会延长到一秒以上(除非你运行的操作系统和系统绝对重载并且没有任何东西可以运行什么时候应该——在这种情况下，你应该解决这个问题[获得更快的处理器、更多的内存，或者任何需要的东西]，而不是摆弄你的应用程序的时间)。这适用于“相对较长的时间段”，例如一秒或 1/10 秒。对于更高的精度，它不会真正起作用，因为我们现在正在进入“调度抖动”区域。

如果你想要非常准确的计时，那么你可能需要使用实时操作系统，或者至少是一个“启用实时扩展”的操作系统，这将使操作系统对时间更加严格(在程序员“易用性”的成本，以及操作系统在处理进程时效率较低的可能，因为与更“懒惰”的计时方法相比，它“切换得比需要的更频繁”)。

另请注意，“可能需要更长的时间”，在空闲系统中主要是“计时器的舍入”(如果系统节拍每 10 毫秒或 1 毫秒发生一次，则计时器设置为 1000 毫秒 + 剩余的时间)当前计时器滴答，因此可能是 1009.999 毫秒，或 1000.75 毫秒，例如)。来自调度和一般操作系统开销的其他开销应该在微秒范围内，如果不是任何现代系统上的纳秒 - 毕竟，操作系统可以在微秒内完成大量工作 - 现代 x86 CPU 将执行 3 个周期每个时钟，时钟运行大约 0.3ns。那是每纳秒 10 条指令[当然，高速缓存未命中等会使情况急剧恶化]。如果操作系统有超过几千条指令从一个进程转到另一个进程(对于线程而言更少)，那么就会出现问题。几千条指令@每纳秒 10 条指令 = 大约数百纳秒。绝对小于一微秒。将其与上次定时器计时结束后启动定时器的 1 毫秒或 10 毫秒“抖动”进行比较。

自然地，如果 CPU 正忙于运行其他任务，这就不同了 - 那么其他进程“剩余运行”的时间也会影响唤醒进程所花费的时间。

当然，在一个负载很重的内存系统中，“刚刚醒来”的进程可能还没有“准备好运行”，例如，它可能被换出到磁盘。在这种情况下，需要数十甚至数百毫秒才能将其从磁盘加载回来。