【问题标题】:Make something wait without using Thread.sleep()?在不使用 Thread.sleep() 的情况下让某些东西等待?
【发布时间】:2013-07-01 09:06:51
【问题描述】:

我正在尝试用一些字符串对游戏进行介绍,我希望一个字符串等待另一个弹出,我不想直接使用 Thread.sleep() 让它等待,因为我是不确定这是否是最佳选择。除了让线程睡眠之外,还有其他方法可以让某些东西等待,还是我只需要让线程睡眠?

【问题讨论】:

  • 这个问题很多。答案:使用摇摆计时器。
  • 当我在谷歌上搜索它时,我没有在计时器上找到任何东西。谢谢。
  • 当然,你需要通过加载核心模块通知加载屏幕,加载屏幕尝试说加载并等待任何通知,内容加载后,将屏幕移除some help here
  • 这属于程序员而不是 SO 所以至少移动它而不是试图关闭它。

标签: java swing


【解决方案1】:

如果这是一款游戏,则不应使用睡眠或计时器。

通常游戏都有自己的内部时钟机制。这意味着您将尝试尽可能快地渲染帧。您的 OnRender 方法将在游戏的当前时间被调用。您可以使用它来确定是否有足够的时间进入下一个屏幕。

这意味着您将在第 1 帧中获得一个时间点 A。您将在第 2 帧中获得 Delta 或另一个时间点 B。您可以通过使用 delta 或计算三角洲自己。对于计时情况,这是一种非常有效的机制,并且在游戏是单线程时工作得很好。任何程序的想法都是永远不会阻塞任何事情。

事情通常阻塞的原因是由于 I/O,例如从磁盘、网络读取或将数据放在 GPU 上。在您的情况下,您可以无阻碍地做任何事情。

这是https://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step的一个不错的页面

【讨论】:

  • 这用于jmonkey引擎。酷。
【解决方案2】:

有一个标准机制:Object.wait()Object.notify()(及其重载/变体)。您只需等待某个事件在一个线程中发生,然后某个其他线程负责通知您(或每个人,如果是 notifyAll)该事件的发生。

您还可以利用java.util.concurrent 中引入的新Condition 机制。

【讨论】:

  • 线程是否无限期休眠?有没有可能像死锁一样无法唤醒?
  • 仅当您在等待一个永远不会出现的通知时。任何体面的代码都必须保证通知最终会发生。但是,您始终可以使用 timeout wait 来确保在某个时间点恢复执行。
  • 那么,当有数百个线程时,这给了最终的cpu资源(当然只有需要的被这个唤醒)?
  • 我不确定我是否得到了这个问题,但 Java 中的等待/通知机制不是忙于等待,如果您担心的话。
  • 我的意思是,线程不会自动切换。就在线程命令通知时,它会切换。所以只做必要的切换对吗?
【解决方案3】:

如果您在游戏中制作它,为什么不尝试在 libgdx 中使用 Actions 之类的东西呢?您只需将不同的演员链接在一起。每当诸如可见性或位置之类的属性达到您想要的值时,您就会触发下一个操作。在游戏的每个更新循环期间都会检查属性条件。

或者,如果它是一个摇摆应用,请使用计时器来检查这些属性。

【讨论】:

    【解决方案4】:
    long t1=0,t2=0;
    long nanoWaitTime=10000; //to wait at least 10000 nano-seconds
    t1=System.nanoTime();
    //start waiting
    long count=0;
    boolean releaseCpuResources=true;
    while(Math.abs(t2-t1)<nanoWaitTime)
    {
       t2=System.nanoTime(); //needs maybe 1000 cycles of cpu to get this value.
                             //so this is like busy-wait
                             //and minimum step may be 1 micro-seconds or more
       if(releaseCpuResources)
       {
       count++;
       if(count>1000)Thread.sleep(1);//after too many iterations, cpu gets overwhelmed
                                     //so Thread.sleep makes it better for large waiting
                                     //times
                                     //but precision is lost. Like uncertainity principle
                                     //but in a quantized fashion
       }
    }
    // here continue to work after waiting
    

    分辨率或精度可能不是您想要的所有 CPU。

    【讨论】:

    • 忙等待效率低下,但比 thread.sleep 更准确。
    • 我们可以从汇编中加入类似“nop”的东西吗?这也算忙等待吗?
    • 不要认为 java 有等价物。只要等待时间不太长,您的方法就是一个好方法。现在,如果您要等待 5 秒钟,只需观察您的 CPU 爬升。您将使用整个内核。
    • 它非常吃CPU,非常适合杀死性能:\
    • 你是对的。我们可以在 20 次 while 迭代后延迟这个等待吗?所以这会发生,另一个线程会喘口气。可以说这已经太多了,“让我们用 Thread.sleep(1) 睡觉”,因为它更适合长时间等待。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-02-27
    • 2019-12-28
    • 2018-05-04
    • 2022-01-22
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多