В каких ситуациях пустой синхронизируемый блок мог достигнуть корректной семантики поточной обработки?
SingleDateAndTimePicker - это компонент пользовательского интерфейса, его не нужно сохранять в своей БД.
Это образец из хранилища SingleDateAndTimePicker
new SingleDateAndTimePickerDialog.Builder(context)
//.bottomSheet()
//.curved()
//.minutesStep(15)
//.displayHours(false)
//.displayMinutes(false)
//.todayText("aujourd'hui")
.displayListener(new SingleDateAndTimePickerDialog.DisplayListener() {
@Override
public void onDisplayed(SingleDateAndTimePicker picker) {
//retrieve the SingleDateAndTimePicker
}
})
.title("Simple")
.listener(new SingleDateAndTimePickerDialog.Listener() {
@Override
public void onDateSelected(Date date) {
}
}).display();
. Вы можете использовать прослушиватель для извлечения объекта Date и сохранения его в своей БД вместо SingleDateAndTimePicker .
Для управления атрибутами Date с Room см. официальную документацию
.
4 ответа
Пустой синхронизируемый блок будет ожидать, пока никто больше не будет использовать тот синхронизатор. Это может быть тем, что Вы хотите, но потому что Вы не защитили последующий код в синхронизируемом блоке, ничто не мешает кому-то еще изменить то, что когда-либо это были Вы, ожидали того, в то время как Вы выполняете последующий код. Это почти никогда не, что Вы хотите.
Это раньше имело место, что спецификация подразумевала, что определенные операции барьера памяти произошли. Однако спецификация теперь изменилась, и исходная спецификация никогда не реализовывалась правильно. Это может использоваться для ожидания другого потока для выпуска блокировки, но координирование, что другой поток уже получил блокировку, было бы хитро.
Синхронизация делает немного больше, чем просто ожидание, в то время как неэлегантное кодирование этого могло достигнуть требуемого эффекта.
Из http://www.javaperformancetuning.com/news/qotm030.shtml
- Поток получает блокировку на мониторе для объекта это (предположение, что монитор разблокирован, иначе поток ожидает, пока монитор не разблокирован).
- Память потока сбрасывает все свои переменные, т.е. она имеет все свои переменные, эффективно считанные из "основной" памяти (JVMs может использовать грязные наборы для оптимизации этого так, чтобы только "грязные" переменные были сброшены, но концептуально это - то же. Посмотрите раздел 17.9 из спецификации языка Java).
- Блок кода выполняется (в этом случае, устанавливающем возвращаемое значение на текущее значение i3, который, возможно, был просто сброшен от "основной" памяти).
- (Любые изменения в переменных обычно теперь выписывались бы к "основной" памяти, но для geti3 () у нас нет изменений.)
- Поток выпускает блокировку на мониторе для объекта это.
Для подробно изучают модель памяти Java, взглянули на это видео от серии 'Advanced topics in programming languages' Google: http://www.youtube.com/watch?v=1FX4zco0ziY
Это дает действительно хороший обзор того, что может компилятор (часто в теории, но иногда на практике) делают к Вашему коду. Существенный материал для любого серьезного программиста Java!