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