Dlaczego Thread.sleep jest zły w użyciu
Przepraszamy za to powtarzające się pytanie, ale nie znalazłem jeszcze zadowalających odpowiedzi. Większość pytań miała swój konkretny przypadek użycia:
Java - alternatywa dla thread.sleep
Czy istnieje lepszy lub alternatywny sposób pominięcia / uniknięcia korzystania z Thread.sleep (1000) w Javie?
Moje pytanie dotyczy bardzo ogólnego przypadku użycia. Poczekaj na zakończenie warunku. Wykonaj jakąś operację. Sprawdź stan. Jeśli warunek nie jest prawdziwy, poczekaj chwilę i ponownie wykonaj tę samą operację.
Na przykład Rozważmy metodę, która tworzy tabelę DynamoDB, wywołując jej tabelę createAPI. Aktywacja tabeli DynamoDB zajmuje trochę czasu, dlatego metoda wywoła jej API DescribeTable, aby odpytywać o status w regularnych odstępach czasu, do pewnego czasu (powiedzmy 5 minut - dopuszczalne jest odchylenie z powodu planowania wątku). Zwraca true, jeśli tabela stanie się aktywna w ciągu 5 minut, w przeciwnym razie zgłasza wyjątek.
Oto pseudo kod:
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");
}
Rozumiem to, używającThread.sleep blokuje bieżący wątek, a tym samym zużywa zasoby. ale w dość średniej wielkości aplikacji, czy jeden wątek jest dużym problemem?
Czytałem gdzieś to wykorzystanieScheduledThreadPoolExecutor i wykonaj tam sondowanie stanu. Ale znowu, musielibyśmy zainicjować tę pulę z co najmniej 1 wątkiem, gdzie uruchomiłaby się metoda runnable, aby wykonać odpytywanie.
Wszelkie sugestie, dlaczego używaćThread.sleep mówi się, że jest to taki zły pomysł i jakie są alternatywne opcje osiągnięcia tego samego, co powyżej.