Многопоточность без боли: моя шпаргалка для собесов в Java

[Elinkis]

Жду вторую часть! Спасибо!

[14yeye]

большое спасибо за статью! очень удобная и понятная агрегация!

[cpud47]

Технически любая запись в волатильное поле происходит до каждого последующего чтения этого же поля

Нет, вообще не гарантируется. Гарантируется SeqCst, что позволяет в среднем притвориться, что эффектов кеша для данной переменной не существует. А вот каких либо гарантий на то, через какое время остальные потоки увидят данное изменение — таких гарантий нигде в jvm получить нельзя.

[MishaBucha]

Вы правы, что нельзя гарантировать через какое время поток увидит обновление.
Но JMM гарантирует, что когда он его увидит — оно будет правильным, и все предыдущие эффекты будут видны.

Это и есть happens-before между volatile write - volatile read)

[cpud47]

JVM для любой записи гарантирует, что когда её увидят — она будет правильной. Более того, в рамках любой ячейки есть seqcst.

Вопрос именно в том, как порядки модификаций/чтений для разных ячеек связаны между собой. Именно здесь становиться важно volatile, атомики и прочее.

[VirtualVoid]

Стоит не забывать ещё такой полезный инструмент как Java Concurrent Animated.
Может быть чрезвычайно полезен при изучении многопоточки.

[Kotofay]

https://sourceforge.net/projects/javaconcurrenta/files/javaConcurrentAnimated.jar/download

[ruslan_astratov]

Спасибо!

[yukinesen]

Статические методы синхронизируются так же, как и методы экземпляра.

возможно не совсем понял формулировку, но ведь статический метод по Class, а методы экземпляра по this?

[MishaBucha]

Тут я имел ввиду именно по синтаксису, а так да, все правильно, статические по Class, а экземпляры по this)

[grisha9]

Атомарные операции гарантируют, что операция будет выполнена полностью и никакой другой поток не сможет изменить значение переменной до завершения операции. Это обеспечивается блокировкой переменной

Ну ну... Вы бы хоть про CAS (compare and swap) операции для начала что нибудь почитали, прежде чем писать откровенную чушь или исходники глянули. Нет там никаких блокировок. Какие сеньоры сейчас, такие и статьи.

[MishaBucha]

Спасибо за комментарий, да, немного ошибся, спасибо за поправку, внес правку в статью)

[emshi]

Спасибо!

[long_live_victor]

Я бы рекомендовал построить часть статьи следующим образом: вы сначала рассказываете про Java Memory Model в целом (про кэш ядер, общую память и т.д.) и объясняете проблематику доступа к данным другого потока. А потом из этой проблематики презентуете решения, а именно отношение happens-before и гарантии, который предоставляет виртуальная машина (locks, synchronized, volatile). И дальше более сложные механизмы: от CAS до Phaser.
Тогда, как мне кажется, выйдет гораздо более логично и последовательно.

[MishaBucha]

Здесь больше шпаргалка для собесов, которую можно взять и почитать перед собесом, нет прям глубины и подкоподщины. Статья делалась именно для цели подготовки)

[helmm]

Не понимаю смысл спрашивать всё это и подобное на собесах - нет же никакого смысла разработчику постоянно держать в голове по сути справочную информацию. То есть фрагменты какие-то все помнят, воспроизвести всё в деталях по памяти и не ошибиться... это же как повезёт, всегда проще при необходимости обратиться к справочнику.

[MishaBucha]

Я согласен на 100 процентов, в этом плане собесы всегда так проводились, запоминаешь кучу инфы, перечитываешь конспекты, потому больше половины ты не используешь)

Как это грустно бы не было, прохождение собесов сейчас это навык, который нужно качать)