Ребята, спасибо вам большое за вашу деятельность. На ваших лекциях очень многое понимаю для себя. Очень рад, что продолжили... Не останавливайтесь, рассказывайте больше... Супер...
Отличный курс лекций! Когда делал лабораторные в университете, сильно измучался касательно поиска информации. Ее вроде много, но вот не складывается ощущение полноты понимания. Эх, нашел бы я вас раньше! Спасибо вам!
Не упомянули важный факт про ReentrantLock. Он отпускает потоки в той хронологической последовательности, в которой потоки вызывали lock. В отличие от synchronized секций, которые пропускают потоки в случайном порядке.
:) Извините. Я имел ввиду, что volatile отвечает за выполнение отношения "happens-before" для операций чтения-записи: если один поток записал в volatile-переменную, а второй обнаружил это, всё, что предшествует записи, выполняется раньше всего, что идёт после чтения. Как я понимаю - локальные для потока кэши JVM были до версии 1.5, то есть фраза про отмену кэширования при помощи volatile неверна. Возможно не прав и вообще - мод "зануда" включился :) Отличные лекции, спасибо.
Про третий монитор - я, возможно, не очень точно выразился. Это не отдельный поток, который мониторит дедлоки. Это просто третий ресурс, который ты захватываешь перед тем, как захватить два других (если из этих двух ты не можешь четко определить порядок их захвата). Это, конечно, уменьшает уровень параллелизации программы, но если правильно это реализовать, то это не будет сильно ощутимо в общем случае.
Спасибо большое за лекцию! Но хочу уточнить, почему так важно синхронизировать доступ к двум акаунтам одновременно? Если синхронизировтаь только методы withdraw и deposit, тогда дедлоков не будет и согласованность балансов не будет нарушена. Может я просто не вижу очевидных проблем, подскажите пожалуйста.
Доброго времени суток! Не совсем понимаю такой момент. WAIT_SEC должно быть одинаковым, судя по коду ? Если да, то тут получается что перевод сделать не получится, т.к. сперва один поток захватывает первый счет, затем второй захватывает второй счет и оба ждут WAIT_SEC пока освободятся ресурсы и не дожидаются.
Отслеживание дедлоков - это не совсем тривиальная задача. Да и не всегда необходимо ее решать в приложении (в серверах бд, серверах приложений - вот там это нужно). В большинстве приложений, гораздо проще с помощью организационных мер устранить возможность возникновения дедлоков: либо захватывать ресурсы в определенном порядке, либо использовать tryLock, либо использовать еще один контрольный ресурс.
Спс, за лекцию. Не понял момент про ид и мониторинг. мне кажется надо создавать демона для отслеживания деадлоков, а также, как на счет создании очереди для доступа к классу. Поправь меня, если я не прав. Хорошо, если бы еще поделился ссылками на самые лучшие реализации отслеживания деадлоков.
Вопрос по Lock. Я переписал с tryLock и у меня возникла ситуация liveLock. Конечно потоки не зависли и deadlock нет, но почти всегда один поток лочит один ресурс, другой поток лочит второй ресурс, и они оба отваливаются по tryLock таймауту на второй блокировке. Как такую ситуацию лучше разруливать? Я думаю, что лучший способ - это ввести правило захвата ресурсов. Но в видео как раз разбирается ситуация, как будто такого правила нельзя применить
Я просто залочился на третьем мониторе. Либо можно создать в классе Operations объект Lock lock = new ReentrantLock() и в методе трансфер сначала локаешь, потом перекидываешь ресурсы и анлокаешь. Да, другому потоку приходится ждать в этом месте, пока лок не спадет, но зато нет проблемы с дедлоком и с ливлоком
чтобы успеть за скоростным преподнесением мыслей ведущего, нужно шарить в теме не хуже, его самого! А то и лучше, чтобы находу все понимать. Он то готовился
Решает ли задачу создание нового объекта (transferLock) и синхронизация тела метода по нему? По логике, тело transfer может выполняться лишь одним потоком за раз и никак не блокирует другие потенциальные методы в классе Operations. private static Object transferLock = new Object(); static void transfer (Account acc1, Account acc2, int amount) throws NoMoneyException { synchronized (transferLock) { if (acc1.getBalance() < amount) throw new NoMoneyException("Not enough money..."); acc1.withdraw(amount); acc2.deposit(amount); System.out.println("Transfer is done.. " + acc1.toString() + " " + acc2.toString()); } }
по поводу volatile и кеширования: разве это не было в JMM < Java 1.5. Сейчас разве volatile не делает упорядочивания "happens-before", а вся JMM оговаривает только то, что гарантировано будет "видно" между потоками?
Если есть такая возможность, то лучше использовать более высокоуровневый идентификатор, чем хеш код, с которым да, есть проблемы на разных jvm. Возможно, ресурсы хранятся в базу, тогда там скорее всего будет уникальный id у каждого ресурса. Если же все-таки нужно получить уникальный id, который будет уникальным всегда, тогда используй UUID.randomUUID()
Прикольная вещь, но я думаю какая-то замороченная. Мб в каких-то сложных и нужна, когда надо, простите, изъ*бнуться так, чтобы и многопоточность была и производительность не терялась. А вообще, это довольно странная идея, когда мы ставим блок synchronized, зависящий от параметра метода. Получается, что у нас как бы сами потоки решают, по каким объектам им лочиться. То есть пытаются управлять механизмом, который призван управлять ими самими. В моем представлении, нужно метод трансфер просто помечать synchronized, чтобы не было проблем, хотя мб будет потеря производительности. Ну или сделать AtomicInteger, вместо int.
Начиная с Sun JDK 6u7, вместо jConsole в JDK идет visualVM, который расположен в $JAVA_HOME/bin/jvisualvm. Если же используется более старая версия java, тогда есть возможность скачать visualVM. Инструмент удобен, имеет GUI интерфейс и возможность установки дополнительных плагинов, что улучшает средство мониторинга
привет Юра, отличное видео! по поводу привилегий ресурсов: есть ли универсальный вариант, который работает на нескольких JVM-ах, в отличии от "System.getIdentityHashCode(х)", который дает уникальный хаш-код только на одной JVM спасибо \Максим
Добрый день! Спасибо за материал, но у меня есть небольшое замечание: На 5:16 показан код для метода transfer(), в нем используется Exception(InsufficientFundsException), которого нет в стандартной поставке JDK_1_8..., документацию по этому исключению нашел docs.oracle.com/cd/E26180_01/Platform.94/apidoc/atg/commerce/claimable/InsufficientFundsException.html, но для данного примера все-таки это исключение не применимо, ну или опущен момент когда библиотеку с этим исключением добавили в проект. Я думаю что тут лучше создать свой класс исключение: public class InsufficientFundsException extends RuntimeException { private String message; public InsufficientFundsException(String message) { this.message = message; } public InsufficientFundsException(Throwable cause, String message) { super(cause); this.message = message; } public String getMessage() { return message; } }
16-тая минута, лектор говорит о инструменте ловли дедлоков, есть готовая картинка. Но мне, новичку, не совсем ясно как запустить тот инструмент диагностики о котором идёт реч. Куда вбивать команды jps, jstack? В CMD, писать ? Как куда нажимать что б на компьютере получить такое чёрное окошко с информацией про дедлоки.
Нет. Пропишу патчь, буду тестить, спасибо что откликнулись. Я по программе обучаюсь, там всё так быстро... Времени не хватает, чтоб все вопросы прояснить.
Естественно unlock-ить нужно и acc2 во внутреннем блоке finally после второго if, когда был получен lock на второй аккаунт. Не весь текст функции влез на слайд, поэтому я это не написал. :)
Именно, вместо последовательного выполнения, задача решается быстрее за счет нескольких потоков, которые более плотно загружают процессор. Попробуйте замерить и сравнить сами с помощью visualvm.
Григорий Зозулин Не могли бы Вы, пожалуйста, объяснить Ваш сарказм. Хотелось бы услышать Ваши аргументы по поводу многопоточности и скорости работы программ.
"...очень хорошая тулзня для диагностирования того, что у вас вообще происходит в жизни..." :-D Молодец, хорошо рассказываешь, интересно. Только бы речь подтянуть, а то половину слов глотаешь и очень торопишься. Очень трудно для восприятия.
Сбор средств для помощи ЗСУ 🇺🇦 Слава Україні! 🇺🇦
www.yuriytkach.com/volunteer
Юрий большое спасибо. Пусть судьба вознаградит вас достойно за ваши труды
Спасибо, как всегда подробно, ясно и доступно пояснили тему!
Ребята, спасибо вам большое за вашу деятельность. На ваших лекциях очень многое понимаю для себя. Очень рад, что продолжили... Не останавливайтесь, рассказывайте больше... Супер...
Отличный курс лекций! Когда делал лабораторные в университете, сильно измучался касательно поиска информации. Ее вроде много, но вот не складывается ощущение полноты понимания. Эх, нашел бы я вас раньше! Спасибо вам!
Спасибо, отлично объясняете. Отдельное спасибо за jps и jsocket и jconsole, не знал о них, хотя уже полгода джаву изучаю
Спасибо за лекции по Java, изложение доступно и интересно...
Какие интересные лекции, какой хороший монтаж... но какая же быстрая у тебя речь)))
А если ставить 0,75 - получаешь голос робота(
с возвращением! все уроки посмотрел, думал новых не будет уже)
Спс, за развернутые ответы. Комментарий хорошего практика это всегда круто.
Не упомянули важный факт про ReentrantLock. Он отпускает потоки в той хронологической последовательности, в которой потоки вызывали lock. В отличие от synchronized секций, которые пропускают потоки в случайном порядке.
только если флаг выставлен вроде как
Топ лектор.
Хорошее видео по-больше бы таких
Юрий, спасибо Вам за ваше видео!
:) Извините. Я имел ввиду, что volatile отвечает за выполнение отношения "happens-before" для операций чтения-записи: если один поток записал в volatile-переменную, а второй обнаружил это, всё, что предшествует записи, выполняется раньше всего, что идёт после чтения. Как я понимаю - локальные для потока кэши JVM были до версии 1.5, то есть фраза про отмену кэширования при помощи volatile неверна. Возможно не прав и вообще - мод "зануда" включился :) Отличные лекции, спасибо.
А почему нельзя засинхронизировать только код внутри методов deposit и withdro?
Про третий монитор - я, возможно, не очень точно выразился. Это не отдельный поток, который мониторит дедлоки. Это просто третий ресурс, который ты захватываешь перед тем, как захватить два других (если из этих двух ты не можешь четко определить порядок их захвата). Это, конечно, уменьшает уровень параллелизации программы, но если правильно это реализовать, то это не будет сильно ощутимо в общем случае.
Своим студентам для понимания что такое Deadlock даю задачу об обедающих философах.
Спасибо за новое видео
он вернулся)
Спасибо большое за лекцию! Но хочу уточнить, почему так важно синхронизировать доступ к двум акаунтам одновременно? Если синхронизировтаь только методы withdraw и deposit, тогда дедлоков не будет и согласованность балансов не будет нарушена. Может я просто не вижу очевидных проблем, подскажите пожалуйста.
тот же вопрос
Доброго времени суток! Не совсем понимаю такой момент. WAIT_SEC должно быть одинаковым, судя по коду ? Если да, то тут получается что перевод сделать не получится, т.к. сперва один поток захватывает первый счет, затем второй захватывает второй счет и оба ждут WAIT_SEC пока освободятся ресурсы и не дожидаются.
Да, действительно такая ситуация может возникнуть. Попробуйте сделать WAIT_SEC не константой, а рандомным значением, которое каждый раз разное.
тогда все равно один поток не сможет захватить lock?
yeah, рад возвращению )
Уаааа с возвращением! ))) скорей бы спринг =)))
Отслеживание дедлоков - это не совсем тривиальная задача. Да и не всегда необходимо ее решать в приложении (в серверах бд, серверах приложений - вот там это нужно). В большинстве приложений, гораздо проще с помощью организационных мер устранить возможность возникновения дедлоков: либо захватывать ресурсы в определенном порядке, либо использовать tryLock, либо использовать еще один контрольный ресурс.
Спс, за лекцию.
Не понял момент про ид и мониторинг.
мне кажется надо создавать демона для отслеживания деадлоков, а также, как на счет создании очереди для доступа к классу. Поправь меня, если я не прав.
Хорошо, если бы еще поделился ссылками на самые лучшие реализации отслеживания деадлоков.
Вопрос по Lock. Я переписал с tryLock и у меня возникла ситуация liveLock. Конечно потоки не зависли и deadlock нет, но почти всегда один поток лочит один ресурс, другой поток лочит второй ресурс, и они оба отваливаются по tryLock таймауту на второй блокировке. Как такую ситуацию лучше разруливать? Я думаю, что лучший способ - это ввести правило захвата ресурсов. Но в видео как раз разбирается ситуация, как будто такого правила нельзя применить
Вы решили эту задачу? у меня также виснет(
пока не решил. Похоже, что если нельзя применить правила захвата ресурса, нет гарантий того, что потоки взаимно не заблокируются. Буду думать дальше )
Я просто залочился на третьем мониторе. Либо можно создать в классе Operations объект Lock lock = new ReentrantLock() и в методе трансфер сначала локаешь, потом перекидываешь ресурсы и анлокаешь. Да, другому потоку приходится ждать в этом месте, пока лок не спадет, но зато нет проблемы с дедлоком и с ливлоком
Скажите пожалуйста, решили ли вы проблему ?
Попробуйте сделать таймаут на tryLock рандомным.
чтобы успеть за скоростным преподнесением мыслей ведущего, нужно шарить в теме не хуже, его самого! А то и лучше, чтобы находу все понимать. Он то готовился
Решает ли задачу создание нового объекта (transferLock) и синхронизация тела метода по нему? По логике, тело transfer может выполняться лишь одним потоком за раз и никак не блокирует другие потенциальные методы в классе Operations.
private static Object transferLock = new Object();
static void transfer (Account acc1, Account acc2, int amount) throws NoMoneyException {
synchronized (transferLock) {
if (acc1.getBalance() < amount) throw new NoMoneyException("Not enough money...");
acc1.withdraw(amount);
acc2.deposit(amount);
System.out.println("Transfer is done.. " + acc1.toString() + " " + acc2.toString());
}
}
jmeter, в частности, является, конечно и монитором, но это средство для нагрузочного тестирования))
по поводу volatile и кеширования: разве это не было в JMM < Java 1.5. Сейчас разве volatile не делает упорядочивания "happens-before", а вся JMM оговаривает только то, что гарантировано будет "видно" между потоками?
Если есть такая возможность, то лучше использовать более высокоуровневый идентификатор, чем хеш код, с которым да, есть проблемы на разных jvm. Возможно, ресурсы хранятся в базу, тогда там скорее всего будет уникальный id у каждого ресурса.
Если же все-таки нужно получить уникальный id, который будет уникальным всегда, тогда используй UUID.randomUUID()
Супер
Прикольная вещь, но я думаю какая-то замороченная. Мб в каких-то сложных и нужна, когда надо, простите, изъ*бнуться так, чтобы и многопоточность была и производительность не терялась. А вообще, это довольно странная идея, когда мы ставим блок synchronized, зависящий от параметра метода. Получается, что у нас как бы сами потоки решают, по каким объектам им лочиться. То есть пытаются управлять механизмом, который призван управлять ими самими. В моем представлении, нужно метод трансфер просто помечать synchronized, чтобы не было проблем, хотя мб будет потеря производительности. Ну или сделать AtomicInteger, вместо int.
Начиная с Sun JDK 6u7, вместо jConsole в JDK идет visualVM, который расположен в $JAVA_HOME/bin/jvisualvm. Если же используется более старая версия java, тогда есть возможность скачать visualVM. Инструмент удобен, имеет GUI интерфейс и возможность установки дополнительных плагинов, что улучшает средство мониторинга
Спасибо. Хорошо подметил! jvisualvm - действительно хороший и мощный инструмент.
привет Юра, отличное видео!
по поводу привилегий ресурсов: есть ли универсальный вариант, который работает на нескольких JVM-ах, в отличии от "System.getIdentityHashCode(х)", который дает уникальный хаш-код только на одной JVM
спасибо
\Максим
Добрый день!
Спасибо за материал, но у меня есть небольшое замечание:
На 5:16 показан код для метода transfer(), в нем используется Exception(InsufficientFundsException), которого нет в стандартной поставке JDK_1_8..., документацию по этому исключению нашел docs.oracle.com/cd/E26180_01/Platform.94/apidoc/atg/commerce/claimable/InsufficientFundsException.html, но для данного примера все-таки это исключение не применимо, ну или опущен момент когда библиотеку с этим исключением добавили в проект. Я думаю что тут лучше создать свой класс исключение:
public class InsufficientFundsException extends RuntimeException {
private String message;
public InsufficientFundsException(String message) {
this.message = message;
}
public InsufficientFundsException(Throwable cause, String message) {
super(cause);
this.message = message;
}
public String getMessage() {
return message;
}
}
Из технологий, будет еще несколько видео по Spring Core - более разжевано и с практикой, включая AOP и немного SpringJdbcTemplate.
16-тая минута, лектор говорит о инструменте ловли дедлоков, есть готовая картинка. Но мне, новичку, не совсем ясно как запустить тот инструмент диагностики о котором идёт реч. Куда вбивать команды jps, jstack? В CMD, писать ? Как куда нажимать что б на компьютере получить такое чёрное окошко с информацией про дедлоки.
Нет. Пропишу патчь, буду тестить, спасибо что откликнулись. Я по программе обучаюсь, там всё так быстро... Времени не хватает, чтоб все вопросы прояснить.
хотелось бы лекцию по hashcode и equals... базовые понятия, но есть много нюансов...
Пожалуйста, перефразируйте вопрос. Я так и не понял, что конкретно Вы хотели спросить.
Естественно unlock-ить нужно и acc2 во внутреннем блоке finally после второго if, когда был получен lock на второй аккаунт. Не весь текст функции влез на слайд, поэтому я это не написал. :)
подскажите . У Вас на видео слово concurrency - означает МОНИТОР. монитор объекта?? спасибо
Concurrency - это не монитор. Может я имел что-то другое. Скажите, о каком моменте в видео Вы говорите?
я не корректно написал. название видео содержит в себе это слово
А. Ну это просто название цикла видео :)
спасибо , понял
нужен онлайн учитель по Джава с нуля.
32:08 почему только acc1 unlock-ится?
Ссылка будет вместе с четвертым видео по Concurrency, которое будет на этой неделе.
YES....
JConsole тоже есть вчера проверял
Чот выключил после слова "срэд".
либо понял либо смирился
Многопоточное программирование - "чтобы программа работала быстрее"?) Я не ослышался?
Именно, вместо последовательного выполнения, задача решается быстрее за счет нескольких потоков, которые более плотно загружают процессор. Попробуйте замерить и сравнить сами с помощью visualvm.
>_< ну ок - пойду замерять ;)
Григорий Зозулин Не могли бы Вы, пожалуйста, объяснить Ваш сарказм. Хотелось бы услышать Ваши аргументы по поводу многопоточности и скорости работы программ.
Nu konechno zhe mnogopotochnost nichego nikuda ne uskoriaet. Mnogopotochnost iznachalno suwestvuet dlia obrabotki blokiruushih operacij - naprimer pechat na printere, setevie funkcii, banalniy vvod s klaviaturi bez mnogopotochnosti nevozmozhni. Pro "bolee plotno zagruzhaut" processor - eto voobwe astral :) Kod vipolniaemij na odnom processore v odin potok vsegda bistree neskolkih potokov, kak minimum potomu chto na obrabotku time-slicinga takge rashoduetsia provessornoe vremia.
Pered tem kak uchit - nado samomu razobratsia i legche otnositsia k kritike :)
помогите у меня в java не переходит ни в какие вкладки
100 Лайков, 0 Дислайков!
"...очень хорошая тулзня для диагностирования того, что у вас вообще происходит в жизни..." :-D
Молодец, хорошо рассказываешь, интересно. Только бы речь подтянуть, а то половину слов глотаешь и очень торопишься. Очень трудно для восприятия.
long threads = ManagementFactory.getThreadMXBean().findDeadlockedThreads();
Занадто швидко, тому мінус однозначно
Повторив код, ніяких дедлоків не зловив. Отже для чого ця лекція? Про що і навіщо?