Тайминг (лайк чтоб поднять наверх) 05:10 Закон Амдала 10:00 Виды параллелизма в Java 12:24 Проблемы параллельных программ 15:35 Основные методы Thread 18:45 Как диагностировать проблему? (Thread dump) 20:59 Создание потока ( имплементация Runnable || расширение Thread) 22:28 Жизненный цикл потока 30:17 Прерывание потока 40:30 Возможности встроенной синхронизации 52:30 Ожидание и уведомления { wait() ; notify() ; notifyAll() } 01:09:16 Про Атомарность 01:11:49 Про Видимость 01:13:35 happens before
Алексей Владыкин, спасибо Вам большое! Не встречал еще более компетентного преподавателя по джаве. Поставленная речь и глубокие знания, никаких слов паразитов и обсасывания, только четко и по делу
У человека преподавательский талант - умение объяснять логично, без лишних слов, простым, понятным, но достаточно научным языком. Действительно отлично. Капля критики - не объяснил, хотя использовал volatile(я имею ввиду в контексте кэша потоков) и join.
В принципе, лекция очень растянута по времени, однако, в поддержку лектора замечу, что материал был в должной мере исчерпывающим и затрагивающим, предвосхищающим, вопросы и аспекты, с которыми я не был знаком на момент начала лекции. Спасибо, за лекцию! UPD:// Смотрел в 1.75
54:40 Мне кажется, не совсем корректно говорить, что мы "засыпаем" в методе synchronized при вызове wait. После того, как на объекте в блоке synchronired вызвали метод wait, поток покидает блок или метод synchronired и перемещается в "комнату ожиданий" и как только его ожидание прервали notify или notifyAll (или по тайму), он включается в борьбу за монитор на общих основаниях с остальными потоками.
То что вещатель разбирается в тем понятно, но объяснить толком даже не пытается, для тех, кто только учит многопоточку, после просмотра данного видео больше вопросов появится чем ответов
@@slavamobile3733 volatile гарантирует, что все потоки всегда будут использовать общее, исходное значение, и они будут видеть изменения этого исходного значения другими потоками сразу же.
Отличная лекция, огромное спасибо Алексей! Но есть один вопрос, на 40:15 Вы говорите, что спящий демон еще не завершился, но виртуальная машина его все равно "прибила". Скажите, пожалуйста, а вычисляющий демон разве не был также "прибит" виртуальной машиной ?
Лекция местами не проработана, например, нужно вначале объяснить Java model memory и happens before. И тогда правильно сказать, что race conditions - это работа с разделяемой переменной вне happens before.
вопрос не корретно поставлен. Volatile - это инструкция для JVM, чтобы перед чтением процессор обновил состояние переменной из оперативной памяти. чтение памяти занимает порядка 5 тактов CPU и в идеальном случае второй поток успевает выполнить 5 операций с этой переменной synchronized - это жесткая блокировка одного или нескольких полей класса. пока кто-то работает в синк методе, все остальные потоки тупо ждут. а атомик классы - они ставят блокировку в оперативной памяти. как только поток хочет изменить данные, то он ставит барьер в память и все остальные потоки встают на блокировку, пока барьер не будет снят.
На volatile переменной невозможно сделать read-modify-write операцию, так как критической секции(синхронизации) нет. С помощью volatile вы можете лишь из одного потока "отдать" данные а в другом забрать. Для реализации синхронизации нужно как минимум две volatile переменные для минимального лока Деккера, что по факту спинлок, а там и до мьютекса не далеко (synchronized)
С какого перепуга график вниз пойдёт? Вы его не задержите тем, что не сможете открыть след. потоки, просто проц скажет, выполняю по списку! сразу 2 потока не поддерживаю. График будет идти строго по 1це
Всем привет, у меня появился вопрос: в java есть многопоточность а в php нету, но в php я для задачи запускал много процессов для параллельного выполнения задачи импорта данных из файла excel для пример, в результате я на своем слабом компьютере запускал 50 процессов, которые в 50 раз быстрее и выполняли задачу(согласно затраченному времени например 12 часов при 1 процессе, а при 50 процессах 15 минут), каждый процесс ел оперативную память. Но теперь я никак не могу понять преимущества многопоточности, как я понял один поток на 1 ядро, ну например 4 ядра 4 потока и вот задача будет в 4 раза быстрее выполняться против в 50 раз быстрее php. Может что-то я не правильно понимаю, как я понял, в java есть тоже многопроцессорность, но якобы очень большие ресурсы на запуск jvm. Как-то странно у меня в голове не укаладывается php быстрее java получается в этом плане?))) Или в java можно тоже запускать 50 потоков на 4х ядерном компе, они просто будут попеременно выполнятся на ядрах.
А почему по формуле на одноядерном проце он график вниз нарисовал? Если N=1, то там тупо константная единица получается, нет? Ну, что и логично, ведь ток виртуальная многопоточность будет.
Поясните, с законом Амдала я не понял. Например берем 1 процессор и меняем долю вычислений, которые можно распараллелить, и при любом P, S будет равно 1, почему Алексей говорит, что в случае с N=1 график может уйти вниз. Может 1-P должно быть по модулю?
интересно но тяжело, дается освоение многопоточности, хотел спросить а вот по последнему примеру на синхронизацию - где по блоку синхронизации, если вместо валатайл, указать в private Singleton (аргументы ) for и zip - тоже будет некорректное событие при составление блока синхронизации? - заранее спасибо. )
Господин Владыкин, вы меня слышите? Как у вас только наглости хватило не включить многопоточность в степик-курс? Вы нас, можно сказать, интеллектуально обокрали!
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Тайминг (лайк чтоб поднять наверх)
05:10 Закон Амдала
10:00 Виды параллелизма в Java
12:24 Проблемы параллельных программ
15:35 Основные методы Thread
18:45 Как диагностировать проблему? (Thread dump)
20:59 Создание потока ( имплементация Runnable || расширение Thread)
22:28 Жизненный цикл потока
30:17 Прерывание потока
40:30 Возможности встроенной синхронизации
52:30 Ожидание и уведомления { wait() ; notify() ; notifyAll() }
01:09:16 Про Атомарность
01:11:49 Про Видимость
01:13:35 happens before
спасибо
лучший!
Алексей Владыкин, спасибо Вам большое! Не встречал еще более компетентного преподавателя по джаве. Поставленная речь и глубокие знания, никаких слов паразитов и обсасывания, только четко и по делу
Спасибо, Алексей. Мне очень нравятся Ваши лекции
У человека преподавательский талант - умение объяснять логично, без лишних слов, простым, понятным, но достаточно научным языком. Действительно отлично.
Капля критики - не объяснил, хотя использовал volatile(я имею ввиду в контексте кэша потоков) и join.
Спасибо Алексей! Лучшие лекции по Java! Респект!
смотреть в 2021 году, не знаю, насколько это актуально, но в целом, все что мне надо было я тут смог подробно разьяснить)
Посмотрел на одном дыхании. Очень интересно. Спасибо, Алексей и команде. ❤
Очень чёткая лекция и отличный лектор. Спасибо!
2 дня стоял на месте в изучении данной темы, после вашей лекции произошел сдвиг)
В принципе, лекция очень растянута по времени, однако, в поддержку лектора замечу, что материал был в должной мере исчерпывающим и затрагивающим, предвосхищающим, вопросы и аспекты, с которыми я не был знаком на момент начала лекции.
Спасибо, за лекцию!
UPD:// Смотрел в 1.75
Спасибо! Супер лекция, все очень доходчиво!
спасибо, понравилась лекция
Спасибо, отличная лекция
Спасибо за лекцию!!!
Кто тоже с JavaRush?
54:40 Мне кажется, не совсем корректно говорить, что мы "засыпаем" в методе synchronized при вызове wait. После того, как на объекте в блоке synchronired вызвали метод wait, поток покидает блок или метод synchronired и перемещается в "комнату ожиданий" и как только его ожидание прервали notify или notifyAll (или по тайму), он включается в борьбу за монитор на общих основаниях с остальными потоками.
То что вещатель разбирается в тем понятно, но объяснить толком даже не пытается, для тех, кто только учит многопоточку, после просмотра данного видео больше вопросов появится чем ответов
Оооооо! Фиолетовый чел! Здарова! Рад, рад =)
Про volatile не полностью раскрыта тема. Volatile гарантирует что данные будут читаться из основной памяти, а не из кэша потока.
Нет, volatile этого не гарантирует
@@slavamobile3733 volatile гарантирует, что все потоки всегда будут использовать общее, исходное значение, и они будут видеть изменения этого исходного значения другими потоками сразу же.
Нет. Volatile гарантирует "volatile read" happens before "volatile write", что в следствии гарантирует sequential consistentsy
28:40 - а разве метод println не потокозащищенный?
спасибо, чувак!!!
разжевал и всё в клювик плюнул, как мама птица птенцу.
Отличная лекция, огромное спасибо Алексей! Но есть один вопрос, на 40:15 Вы говорите, что спящий демон еще не завершился, но виртуальная машина его все равно "прибила". Скажите, пожалуйста, а вычисляющий демон разве не был также "прибит" виртуальной машиной ?
1:06:58 - не понимаю, о какой конкретно второй нити здесь идёт речь? Мы же выше всего одну нить запустили - DepositThread(account).start()
Главная нить, которую мы запустили через main.
Она запускает параллельный процесс пополнения и пытается снять.
Всего 2 нити.
Лекция местами не проработана, например, нужно вначале объяснить Java model memory и happens before. И тогда правильно сказать, что race conditions - это работа с разделяемой переменной вне happens before.
не понял зачем нам тогда использовать volatile если можно через synchronized также все проводить и это будет давать нам ту самую атомарность
вопрос не корретно поставлен.
Volatile - это инструкция для JVM, чтобы перед чтением процессор обновил состояние переменной из оперативной памяти. чтение памяти занимает порядка 5 тактов CPU и в идеальном случае второй поток успевает выполнить 5 операций с этой переменной
synchronized - это жесткая блокировка одного или нескольких полей класса. пока кто-то работает в синк методе, все остальные потоки тупо ждут.
а атомик классы - они ставят блокировку в оперативной памяти. как только поток хочет изменить данные, то он ставит барьер в память и все остальные потоки встают на блокировку, пока барьер не будет снят.
На volatile переменной невозможно сделать read-modify-write операцию, так как критической секции(синхронизации) нет. С помощью volatile вы можете лишь из одного потока "отдать" данные а в другом забрать. Для реализации синхронизации нужно как минимум две volatile переменные для минимального лока Деккера, что по факту спинлок, а там и до мьютекса не далеко (synchronized)
@@_bigbro, не путайте блокировку кэш линий при атомик операциях с барьерами памяти(mfence)
Лайк, если перешел сюда из javarush :)
Ссылка на вторую часть: ruclips.net/video/umTVNoG3760/видео.html
гугл)
Хорошо что указатель мыши видно
6:06 что значит вычислительные ядра? Физическое кол-во ядер или логическое? Я просто в этом не шарю
Почему все синхронизируются по типу в сингелтоне?
Вроде понятно все.
Но теперь понимаю, что много чего не изучено.
и сколько лет мне придется все учтиь =*(
С какого перепуга график вниз пойдёт?
Вы его не задержите тем, что не сможете открыть след. потоки, просто проц скажет, выполняю по списку! сразу 2 потока не поддерживаю.
График будет идти строго по 1це
ruclips.net/video/kma6T8OAQ-Q/видео.htmlm53s
@@HyperSirrr почему все кто рассказывает про многопоточку болеют))
пожалуй не буду изучать этот раздел, он заразный))
С такого перепуга - накладные расходы на переключение контекста
Всем привет, у меня появился вопрос: в java есть многопоточность а в php нету, но в php я для задачи запускал много процессов для параллельного выполнения задачи импорта данных из файла excel для пример, в результате я на своем слабом компьютере запускал 50 процессов, которые в 50 раз быстрее и выполняли задачу(согласно затраченному времени например 12 часов при 1 процессе, а при 50 процессах 15 минут), каждый процесс ел оперативную память. Но теперь я никак не могу понять преимущества многопоточности, как я понял один поток на 1 ядро, ну например 4 ядра 4 потока и вот задача будет в 4 раза быстрее выполняться против в 50 раз быстрее php. Может что-то я не правильно понимаю, как я понял, в java есть тоже многопроцессорность, но якобы очень большие ресурсы на запуск jvm. Как-то странно у меня в голове не укаладывается php быстрее java получается в этом плане?))) Или в java можно тоже запускать 50 потоков на 4х ядерном компе, они просто будут попеременно выполнятся на ядрах.
А почему по формуле на одноядерном проце он график вниз нарисовал? Если N=1, то там тупо константная единица получается, нет? Ну, что и логично, ведь ток виртуальная многопоточность будет.
Накладные расходы на переключение контекста
Поясните, с законом Амдала я не понял. Например берем 1 процессор и меняем долю вычислений, которые можно распараллелить, и при любом P, S будет равно 1, почему Алексей говорит, что в случае с N=1 график может уйти вниз. Может 1-P должно быть по модулю?
Р-не может быть более 1. Это ведь доля от целого. Если вы распаралелили 40% от всего кода, то ваше р=0.4 .Соответственно никакой модуль не требуется.
Алексей, зачем вы стул ломаете? (в самом конце) :)
интересно но тяжело, дается освоение многопоточности, хотел спросить а вот по последнему примеру на синхронизацию - где по блоку синхронизации, если вместо валатайл, указать в private Singleton (аргументы ) for и zip - тоже будет некорректное событие при составление блока синхронизации? - заранее спасибо. )
на скорости 2x смог посмотреть
а что такое checkAmountNotNegative? у меня такого нет и даже без него работает
наверное метод, проверяющий, а не ушел ли баланс в минус.
как поставить два лайка?
45:22 Монитор или мьютекс? Монитор - это паттерн.
Стив джобс))
Господин Владыкин, вы меня слышите? Как у вас только наглости хватило не включить многопоточность в степик-курс? Вы нас, можно сказать, интеллектуально обокрали!
Не реви. Смотри здесь.
Дак тут и нет ничего про многопоточность то...
почему?
скорость на 1,5 и можно смотреть..
Спасибо! Почти все здорово. Вот этот материал (ruclips.net/video/G8XGUqZs5KI/видео.html ) помог бы улучшить восприимчивость Ваших лекций.
на самом деле слабая лекция , не понимаю почему все хвалят , всё довольно путано , много важного осталось не озвученным
Такая интересная тема , но тут как-то скучно !