Буквально лучший плейлист уроков на ютубе в ru сегменте. Думаю даже в целом в ютуб никто многопоточности в java столько внимания не уделил. Красавчик !
Классно было бы также видеть как сильно многопоточность влияет на производительность. Я немного поисследовал и самый первый пример (где 2 синхронизированных метода обращались к одной переменной), а именно где * private static int INCREMENT_AMOUNT_1 = 50000000; // моё именование переменных * private static int INCREMENT_AMOUNT_2 = 60000000; * * Выполним программу, когда методы помечены synchronized, но они обращаются к разным переменных и где синхронизация бесполезна * * Когда методы синхронизированы - то время выполнения 3 секунды, когда не синхнонизированы - от 265 милисекунд * * Если значений в 10 раз в каждом больше, то синхронизированные выполняются за 33 сек, а не синхронизированные за 260 милисекунд Но возможно такими проверками видео были бы сильно перегружены, но понимания "правильно постановки synchronized" выросло бы. Но и так с удовольствием смотрю последовательно данный плейлист, пока всё замечательно и судя по потому как преподносится материал - дальше будет также понятно
Выдержка из книги "Философия Java" Б. Эккеля о synchronized. Когда следует применять синхронизацию? Используйте правило синхронизации Брайана (Брайан Гетц - соавтор книги «Java Concurrency in Practice»): «Если вы записываете данные в переменную, которая может быть затем прочитана другим потоком, или читаете данные из переменной, которая могла быть записана другим потоком, вы должны использовать синхронизацию. Кроме того, и читающий, и записывающий потоки должны синхронизироваться по одной блокировке».
Спасибо за отличную лекцию. Правильно ли я понимаю, что в случае использования в качестве монитора Runner.class потоки попеременно блокируют доступ ко всей логике описанной в классе и потому выполняются последовательно? Когда мы вводим два Object, мы вводим уже разграничение. То есть работа c firstCouner возможна если монитор Object1 cвободен и работа с secondCounter возможна если монитор Object2 свободен. Таким образом мы сделали 4 потока, которые используют 2 монитора и могут идти параллельно по 2 синхронизируясь уже между собой.
И Вам за комментарий!) Да все верно, только используя монитор объекта Runner.claas мы блокируем доступ не ко всей логике класса, а к статическим синхронизированным методам. Поток, захвативший монитор объекта Runner.class, и поток, захвативший монитор обьекта new Runner(), могут работать параллельно
Большое спасибо за видео. Подскажите пожалуйста на сколько правильно использовать IntConsumer? Не очень красиво и немного запутывающе выглядит требование. Заранее прошу прощения, сам не сильно разбираюсь, но субъективно кажется, что должен быть более элегантный способ специфицировать протокол принимаемой функции. Заранее, большое спасибо!
Здравствуйте, большое спасибо за комментарий!) Не нужно просить прощения, я всегда только рад обсудить) Более элегантный способ 100% всегда существует) Здесь можно создать класс CounterTask, который будет реализовать интерфейс Runnable. В этом классе инкапсулировать всю логику по работе с нашими значениями. И затем с помощью экземпляров класса CounterTask создавать экземпляры класса Thread
Очень доступно все, спасибо. Но есть вопрос, почему именно ты создаешь объект класса Object (private static final Object LOCK_TO_INCREMENT_AMOUNT_FIRST_COUNTER = new Object();) Можно ли создавать объекты текущего класса (private static final Runner LOCK_TO_INCREMENT_AMOUNT_FIRST_COUNTER = new Runner();)? По идее да, если у каждого объекта свой монитор, и работать будет так же. Или как лучше или правильнее? (Это вопрос про статические методы)
я так и не понял. Как мониторы освобождают от проблеммы одновременной записи двух потоков? Да они теперь каким то чудом не пишут одновременно в одну переменную, но они ведь по прежнему могут писать/читать одновременно в *сам* монитор: один поток смотрит состояние монитора - он свободен. вдруг второй его захватывает, теперь первый (помня что монитор свободен, он ведь только что проверял) сам захватывает монитор, 🤯
Единственное, что могу сказать это то, что гарантируется, что в любой момент времени монитор может удерживаться только одним потоком. Сказать, каким образом обеспечивается атомарность операции захвата монитора, я не могу)
Буквально лучший плейлист уроков на ютубе в ru сегменте. Думаю даже в целом в ютуб никто многопоточности в java столько внимания не уделил. Красавчик !
Огромное спасибо! Очень приятно!)
Поддерживаю!
Спасибо тебе огромное! Ты один из лучших блогеров по Java на русскоязычном ютьюбе
Вам спасибо! Безумно приятно!)
Гениальные объяснения гениальных вещей.. Спасибо!
И Вам спасибо за такие комментарии и активность на канале!)
Очень круто объясняешь!
Большое спасибо! Очень рад!)
Чувак, крутые уроки)🤌 Уже несколько дней тебя смотрю и переписываю код) Красавчик😎
Спасибо большое!)
Классно было бы также видеть как сильно многопоточность влияет на производительность.
Я немного поисследовал и самый первый пример (где 2 синхронизированных метода обращались к одной переменной), а именно где
* private static int INCREMENT_AMOUNT_1 = 50000000; // моё именование переменных
* private static int INCREMENT_AMOUNT_2 = 60000000;
*
* Выполним программу, когда методы помечены synchronized, но они обращаются к разным переменных и где синхронизация бесполезна
*
* Когда методы синхронизированы - то время выполнения 3 секунды, когда не синхнонизированы - от 265 милисекунд
*
* Если значений в 10 раз в каждом больше, то синхронизированные выполняются за 33 сек, а не синхронизированные за 260 милисекунд
Но возможно такими проверками видео были бы сильно перегружены, но понимания "правильно постановки synchronized" выросло бы.
Но и так с удовольствием смотрю последовательно данный плейлист, пока всё замечательно и судя по потому как преподносится материал - дальше будет также понятно
Большое спасибо за комментарий!) Стоит сделать отдельный ролик с такими замерами, я согласен, но не могу обещать, что это будет в скором времени)
Выдержка из книги "Философия Java" Б. Эккеля о synchronized.
Когда следует применять синхронизацию? Используйте правило синхронизации Брайана (Брайан Гетц - соавтор книги «Java Concurrency in Practice»):
«Если вы записываете данные в переменную, которая может быть затем прочитана другим потоком, или читаете данные из переменной, которая могла быть записана другим потоком, вы должны использовать синхронизацию. Кроме того, и читающий, и записывающий потоки должны синхронизироваться по одной блокировке».
спасибо за уроки!) Пользуйся cmd+d или ctrl+d что бы строки кода копировать, если надо поменять только название переменной
Вам спасибо за комментарий и совет!)
🤝@@vladzuev10
CTRL + D - копировать строки
Спасибо за отличную лекцию.
Правильно ли я понимаю, что в случае использования в качестве монитора Runner.class потоки попеременно блокируют доступ ко всей логике описанной в классе и потому выполняются последовательно?
Когда мы вводим два Object, мы вводим уже разграничение. То есть работа c firstCouner возможна если монитор Object1 cвободен и работа с secondCounter возможна если монитор Object2 свободен. Таким образом мы сделали 4 потока, которые используют 2 монитора и могут идти параллельно по 2 синхронизируясь уже между собой.
И Вам за комментарий!) Да все верно, только используя монитор объекта Runner.claas мы блокируем доступ не ко всей логике класса, а к статическим синхронизированным методам. Поток, захвативший монитор объекта Runner.class, и поток, захвативший монитор обьекта new Runner(), могут работать параллельно
Большое спасибо за видео. Подскажите пожалуйста на сколько правильно использовать IntConsumer? Не очень красиво и немного запутывающе выглядит требование. Заранее прошу прощения, сам не сильно разбираюсь, но субъективно кажется, что должен быть более элегантный способ специфицировать протокол принимаемой функции. Заранее, большое спасибо!
Здравствуйте, большое спасибо за комментарий!) Не нужно просить прощения, я всегда только рад обсудить) Более элегантный способ 100% всегда существует) Здесь можно создать класс CounterTask, который будет реализовать интерфейс Runnable. В этом классе инкапсулировать всю логику по работе с нашими значениями. И затем с помощью экземпляров класса CounterTask создавать экземпляры класса Thread
Очень доступно все, спасибо. Но есть вопрос, почему именно ты создаешь объект класса Object (private static final Object LOCK_TO_INCREMENT_AMOUNT_FIRST_COUNTER = new Object();) Можно ли создавать объекты текущего класса (private static final Runner LOCK_TO_INCREMENT_AMOUNT_FIRST_COUNTER = new Runner();)? По идее да, если у каждого объекта свой монитор, и работать будет так же. Или как лучше или правильнее? (Это вопрос про статические методы)
Большое спасибо за активность!) Да, все верно, можно создавать и экземпляры класса Runner в этом случае
я так и не понял. Как мониторы освобождают от проблеммы одновременной записи двух потоков? Да они теперь каким то чудом не пишут одновременно в одну переменную, но они ведь по прежнему могут писать/читать одновременно в *сам* монитор:
один поток смотрит состояние монитора - он свободен.
вдруг второй его захватывает,
теперь первый (помня что монитор свободен, он ведь только что проверял) сам захватывает монитор,
🤯
Единственное, что могу сказать это то, что гарантируется, что в любой момент времени монитор может удерживаться только одним потоком. Сказать, каким образом обеспечивается атомарность операции захвата монитора, я не могу)