为什么Thread.sleep不好用
对于这个重复的问题抱歉，但我还没有找到任何满意的答案。 大部分问题都有自己的具体用例：
Java - 替代thread.sleep
有没有更好的或替代的方法来跳过/避免在Java中使用Thread.sleep（1000）？
我的问题是针对非常通用的用例。 等待条件完成。 做一些操作。 检查一个条件。 如果条件不成立，请等待一段时间再做相同的操作。
例如，考虑通过调用createAPI表创建DynamoDB表的方法。 DynamoDB表需要一些时间才能变为活动状态，以便该方法将调用其DescribeTable API以定期轮询状态，直到某段时间（比如5分钟 - 由于线程调度造成的偏差可接受）。 如果表在5分钟内变为活动状态，则返回true，否则返回异常。
这里是伪代码：
public void createDynamoDBTable(String name) {
//call create table API to initiate table creation
//wait for table to become active
long endTime = System.currentTimeMillis() + MAX_WAIT_TIME_FOR_TABLE_CREATE;
while(System.currentTimeMillis() < endTime) {
boolean status = //call DescribeTable API to get status;
if(status) {
//status is now true, return
return
} else {
try {
Thread.sleep(10*1000);
} catch(InterruptedException e) {
}
}
}
throw new RuntimeException("Table still not created");
}
我明白通过使用Thread.sleep块当前线程，从而消耗资源。 但是在一个相当中等大小的应用程序中，一个线程是一个大问题？
我读了一些使用ScheduledThreadPoolExecutor地方，并在那里进行这种状态轮询。 但是，我们必须用至少一个线程来初始化这个池，在这个线程中可以运行轮询的runnable方法。
任何关于为什么使用Thread.sleep建议都被认为是一个糟糕的主意，以及如何实现上述同样的选择。
http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx
在这种情况下使用Thread.sleep很好。 人们劝阻Thread.sleep的原因是因为它经常用于修复竞争条件的恶意尝试，在基于通知的同步是一个更好的选择的情况下使用。
在这种情况下，AFAIK您没有选项，只能轮询，因为API不会提供通知。 我也可以看到这是一个不经常的操作，因为大概你不会创建千张表。
因此，我觉得在这里使用Thread.sleep很好。 正如你所说的，当你要阻止当前线程时，产生一个单独的线程似乎会使事情复杂化，而没有优点。
是的，应该尽量避免使用Thread.sleep（x），但不应该完全忘记：
为什么应该避免
在哪里使用Thread.sleep（x）：