Прекрасное объяснение и примеры! Я бы добавила хоть пару слов о том, зачем вообще нужны вложенные мьютексы (когда обойтись единственным блоком синхронизации будет плохим решением). Это не сложно, но для тех, кто только начал разбираться в многопоточности, будет дополнительным подспорьем. А вообще отличное видео!
дедлоки чаще прочего видят те кто с бд работает. ты в транзакции, ты читаешь что тебе нужно в каком-то порядке, те же банковские счета пусть будут,- появляется нагрузка - ПАМ-ПАМ - дедлок. Исключение от MSSQL так и стоит перед глазами: you were chosen as a deadlock victim
Ничего не происходит. Просто чтоб зайти в этот блок, потоку нужно захватить монитор. Монитор может держать только один поток. Таким образом, код в блоке synchronized может выполняться только одним потоком, который в данный момент владеет монитором.
Такой вопрос, а если в handle для какого-нибудь третьего потока передать resources.get(1),resources.get(2) разве у нас опять все не сломается в дедлок?
В Java выполнение sleep() не отпускает монитор. По этому картина следующая: первый поток запускается, захватывает монитор, останавливается на sleep. Второй поток запускается, захватывает свой первый монитор, а второй захватить не может, так как его удерживает первый поток. Первый поток возобновляет работу после sleep, но свой второй монитор так же не может захватить, так как его удерживает второй поток.
Нужно сделать себе опыт. Не знаю как в бэкэндовой java, но в android разработке это возможно, потому что любой может сделать приложение, выложить его на маркет и демонстрировать в качестве опыта работы. Нужно сделать пару нормальных приложений с исходниками на гитхабе, и можно пробовать устраиваться. У меня есть несколько знакомых, которые таким образом зашли в профессию. Знаю, так как сам их консультировал)
Если по фэншую все делать, то должен) Но для примера кода лучше наоборот все в одну кучу сгрести. Тем, кто будет смотреть исходный код по ссылке, проще в один файл посмотреть и все сразу увидеть, чем бегать по разным.
Приятно смотреть, когда простыми словами объясняют такую тему, как многопоточность! Спасибо!
Прекрасное объяснение и примеры! Я бы добавила хоть пару слов о том, зачем вообще нужны вложенные мьютексы (когда обойтись единственным блоком синхронизации будет плохим решением). Это не сложно, но для тех, кто только начал разбираться в многопоточности, будет дополнительным подспорьем. А вообще отличное видео!
Круто! Спасибо большое за объяснения!
дедлоки чаще прочего видят те кто с бд работает. ты в транзакции, ты читаешь что тебе нужно в каком-то порядке, те же банковские счета пусть будут,- появляется нагрузка - ПАМ-ПАМ - дедлок.
Исключение от MSSQL так и стоит перед глазами: you were chosen as a deadlock victim
Спасибо,!!! Как раз на курсах такая домашняя задача, все кумекал....
Как успехи, прошел год. Работаете уже?
@@alexandr6055 вітаю, ні захищаю Україну в збройних силах
Спасибо,сейчас как раз изучаю многопоточность в java
Как успехи, прошел год. Работаете уже?
а я сейчас ее изучаю=)
Спасибо, очень понятно объясняешь
Спасибо за видео! Сразу лайк.
Супер ,спасибо за видео 👍
Сергей, за видео спасибо! Тоже не написал бы на собесе сам. На 1:06 мАнитор - опечатка )
как раз у шилдта сегодня про это читал
как всегда интересно и доступно
Хорошая и нужная тема :)
Спасибо!
Я в windows сталкивался с зависание , но там на С писалось и логика была далека от идеала:)
Спасибо. А вот эти дедушки могут быть причины багов в работах приложений, веб-сервисов?
Привет.А можешь подсказать что происходит внутри sinhronized{ } ?
Ничего не происходит. Просто чтоб зайти в этот блок, потоку нужно захватить монитор. Монитор может держать только один поток. Таким образом, код в блоке synchronized может выполняться только одним потоком, который в данный момент владеет монитором.
Такой вопрос, а если в handle для какого-нибудь третьего потока передать resources.get(1),resources.get(2) разве у нас опять все не сломается в дедлок?
Не сломается. Поток дождется, пока ресурсы освободятся, захватит нужные локи и сделает свое дело.
Так deadLock не получается, после sleepa поток отпустит монитор, и все потоки доработают как положено
В Java выполнение sleep() не отпускает монитор. По этому картина следующая:
первый поток запускается, захватывает монитор, останавливается на sleep. Второй поток запускается, захватывает свой первый монитор, а второй захватить не может, так как его удерживает первый поток. Первый поток возобновляет работу после sleep, но свой второй монитор так же не может захватить, так как его удерживает второй поток.
Вот вам простой пример из жизни:
Джуна не берут никуда без опыта.
Опыт Джун нигде не может взять, потому что его никто не берёт.
Не благодарите😂
Нужно сделать себе опыт. Не знаю как в бэкэндовой java, но в android разработке это возможно, потому что любой может сделать приложение, выложить его на маркет и демонстрировать в качестве опыта работы. Нужно сделать пару нормальных приложений с исходниками на гитхабе, и можно пробовать устраиваться. У меня есть несколько знакомых, которые таким образом зашли в профессию. Знаю, так как сам их консультировал)
А разве не должен весь этот код быть разложен по разным файлам
Если по фэншую все делать, то должен) Но для примера кода лучше наоборот все в одну кучу сгрести. Тем, кто будет смотреть исходный код по ссылке, проще в один файл посмотреть и все сразу увидеть, чем бегать по разным.
Понял, спасибо за быстрый ответ