Почему должен ожидать () всегда быть названным в цикле
Поскольку вы упомянули react-router | react-router-dom в v4, вы можете сделать это одним из следующих способов:
A
- Заменить на [117 ]
<Link
className="btn btn-primary" // some bootstrap class
to={{
pathname: "/watch",
state: { posterId: poster.id } // I am assuming post has id
}}
/>
- в
WatchComponent
class WatchComponent extends React.Component {
componentDidMount() {
const { posterId } = this.props.location.state;
//make ajax request to the server and get poster details
//promise resolve, set response into state
// this.setState({ poster: res.json()})
}
render() {
const { poster } = this.state;
return (
// render poster details here.
)
}
}
Или Вы можете просто сделать это
<Link
className="btn btn-primary" // some bootstrap class
to={`/watch/${posterId}`} // provided that Route of WatchComponent is defined as (URL parameter) <Route path="watch/:posterId" component={WatchComponent} />
/>
затем в WatchComponent вы делаете
class WatchComponent extends React.Component {
componentDidMount() {
const { posterId } = this.props.macth.params;
//make ajax request to the server and get poster details
//promise resolve, set response into state
// this.setState({ poster: res.json()})
}
render() {
const { poster } = this.state;
return (
// render poster details here.
)
}
}
5 ответов
Три вещи Вы будете видеть, что люди делают:
-
Используя ожидание, не проверяя ничто (ПОВРЕЖДЕННОЕ)
-
Используя ожидание с условием, с помощью, если проверка, сначала (ПОВРЕЖДЕННАЯ).
-
Используя ожидание в цикле, где тест абонентского шлейфа проверяет условие (НЕ ПОВРЕЖДЕННЫЙ).
Не понимание этих деталей о том, как ожидают и уведомляют, работа приводит людей выбирать неправильный подход:
-
Каждый - то, что поток не помнит уведомления, которые произошли, прежде чем он нашел время для ожидания. Уведомление и notifyAll методы только потоки эффекта, которые уже ожидают, если поток не ожидает в то время, когда этому не повезло.
-
Другой - то, что поток выпускает блокировку, как только это начинает ожидать. Как только это получает уведомление, это повторно получает блокировку и продвигается, где это кончило. Выпуск блокировки означает, что поток не знает ничто о текущем состоянии, как только это просыпается назад, любое количество других потоков, возможно, внесло изменения с тех пор. Проверка, осуществленная перед потоком, начала ожидать, ничего не говорит Вам о том, что состояние в настоящее время.
, Таким образом, первый случай, без проверки, кладет Ваш код, уязвимый для условий состязания. Это, могло бы оказаться, работало бы случайно, если один поток имеет действительно преимущество над другим. Или у Вас могут быть потоки, ожидающие навсегда. Если Вы опрыскиваете в тайм-аутах тогда, Вы заканчиваете с медленным кодом, который иногда не делает то, что Вы хотите.
Добавление условия проверить кроме самого уведомления защищает Ваш код от этих условий состязания и дает Вашему коду способ знать то, что - состояние то, даже если поток не ожидал в нужное время.
второй случай, с если-проверками, вероятно, будет работать, если у Вас будет только 2 потока. Это помещает предел на количество вещей состояний, может войти и когда Вы сделали дефектные предположения, Вы не становитесь записанными так плохо. Это - ситуация для большого количества игрушечных упражнений примера кода. Результатом являются люди, ушедшие, думая, что они понимают, когда они действительно не делают.
Проподсказка: код Реального мира имеет больше чем два потока.
Используя цикл позволяет Вам перепроверить условие, как только Вы повторно получаете блокировку так, чтобы Вы продвинулись на основе текущего состояния, не на устаревшем состоянии.
Вам нужно не только выполнить цикл, но и проверить свое состояние в цикле. Java не гарантирует, что ваш поток будет разбужен только вызовом notify () / notifyAll () или правильным вызовом notify () / notifyAll () вообще. Из-за этого свойства версия без цикла может работать в вашей среде разработки и неожиданно давать сбой в производственной среде.
Например, вы чего-то ждете:
synchronized (theObjectYouAreWaitingOn) {
while (!carryOn) {
theObjectYouAreWaitingOn.wait();
}
}
Появляется злой поток и:
theObjectYouAreWaitingOn.notifyAll();
Если злой поток не может / не может связываться с carryOn , вы просто продолжаете ждать подходящего клиента.
Edit: Добавлены еще несколько примеров. Ожидание можно прервать. Он выдает InterruptedException, и вам может потребоваться заключить ожидание в try-catch. В зависимости от потребностей вашего бизнеса вы можете выйти или подавить исключение и продолжить ожидание.
Ответ на этот вопрос содержится в документации для Object.wait (long milis)
Поток также может проснуться без уведомления, прерывания или истечения времени ожидания, так называемое ложное пробуждение . Хотя на практике это случается редко, приложения должны защищаться от этого, проверяя условие, которое должно было вызвать пробуждение потока, и продолжая ждать, если условие не выполняется. Другими словами, ожидания всегда должны происходить в циклах, например в следующем:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout);
... // Perform action appropriate to condition
}
(Для получения дополнительной информации по этой теме, см. Раздел 3.2.3 в книге Дуга Ли «Параллельное программирование на Java (Второе издание) "(Эддисон-Уэсли, 2000), или пункт 50 в книге Джошуа Блоха "Эффективный язык программирования Java Руководство »(Addison-Wesley, 2001).
Может быть больше одного рабочего, ожидающего выполнения условия.
Если два или более рабочих просыпаются (notifyAll), они должны снова проверить условие. в противном случае все рабочие будут продолжать работу, даже если данные могут быть только по одному из них.
Поскольку ожидание и уведомление используются для реализации [переменных условий] ( http: // en .wikipedia.org / wiki / Monitor_ (синхронизация) #Blocking_condition_variables) , поэтому вам нужно проверить, истинен ли конкретный предикат, который вы ожидаете, прежде чем продолжить.