atomic и сделаны через volatile. Можно исходный код погуглить.

То, что "классы разные нужны, классы многие важны" - никто и не спорит

возьмут волатайл по вашему совету
у меня где-то был такой совет?

ну уникальные ID-шники это такое...

Например в CC&B ID-шники генерировались как случайные числа. Долго изумлялся, потом прочитал, что это чуть ли не стандарт в написании высоконагруженных приложений для СУБД ))). А сиквенсы - вообще отстой и торзмоз )))

[censored]

Смысл моего поста был, что через volatile МОЖНО написать ЛЮБОЕ многопоточное приложение. Т.к. даже блокировки (synchronize, lock) тоже через них делаются. Т.е. избыточны, в моем понимании данного слова.

Но избыточны и можно НЕ РАВНО [censored] "удобно", "отлично подходит", "предлагал".

Ну и да... ждем обещанной задачи от знатоков многопоточки

Одно время читал livejournal человека который учился и серьезно разбирался в многопоточке. Там все сильно плохо ))) сказать что "каждая строка выстрадана и вылизана до предела" это сильно большое приувеличение. На стандартные библиотеки от Java __очень__ много критики и достаточно много альтернативных реализаций.

Те же самые Atomic'и появились не так уж и давно (по меркам Java). До этого их просто не было. Фактически единственный "многопоток" который был в Java более-менее изначально ConcurrentLinkedQueue. Да и тот ругали, что используемый там алгоритм приводить к memory leak'у. Но когда я пытался повторить test case, у меня повторить не получилось, возможно на тот момент уже подправили или я чего-то недопонял (возможно проблема затрагивает только minor сборщик мусора).

AFAIK

Например Sun/Oracle авторы Java библиотек на коллизии при доступе к данным в одной строке кеша - клали и, как я подозреваю, продолжают класть с высокой колокольни. Возможно в Open JDK что-то изменилось. Но не факт. Не знаю.

Набор конкарент коллекций так же достаточно убогий. Или просто blocking обертка поверх стандартных коллекций или раз-два и все. Например отсутвуют нормальные многопотоковые bounded коллекции.

Хотя для любого более-менее нормального сервиса/сервира, проверка на переполнение очереди сообщение как-то ну крайне желательна. Т.е. ConcurrentLinkedQueue для очереди сообщений - ну сильно не оптимальный выбор, а другого в стандартных библиотеках вроде то и нет.

В результате нарываешься на костыли и велосипеды, где классы используются совершенно НЕ по их назначению. Например берут ConcurrentLinkedQueue и поверх навешивают 100500 счетчиков на AtomicInteger, что бы банальный size коллекции считать и проверять (видел такое в реальных проектах). А то что получается в итоге, еще и эффективным многопотоком обзывают ))) хотя это не многопоток, а помойка из отбросов ))).

ну как минимум:
1. никто не мешает сделать поток-диспетчер, который всегда выполняется и отслеживает блокировок/атомарных операций
поскольку к этим структурам доступ есть только у него, продлемы с многопотоком нет
2. в пользовательских потоках: посылаем в него сообщение, встаем в цикл, ждем ответа

Для передачи сообщений для каждого пользовательского/управляемого-потока, заводим банально по переменной. Если она пустая - пред. сообщение потоком-диспетчером обработалось, пишем сообщение в данную переменную. Если не пустая - стоим/ждем

переменная используется в качестве вырожденного Single Producer - Single Consumer Queue на одно сообщение. В потоке-диспетчере пробегаем в цикле все очереди.

IMHO

был не прав.
Атомики и ConcurrentLinkedQueue одновременно появились. Мне почему-то казалось, что это более позднее дополнение.

У меня такое чувство, что это чуть ли не единственный человек, который занимался этими пакетами. Он точно читает лекции и ведет курсы, где учит многопоточке. В том числе, lock free алгоритмам начиная с Circle Ring Buffer.

Почему он пропихнул именно и исключительно ConcurrentLinkedQueue в стандартные библиотеки, то ведомо только ему ))) возможно просто в тот момент ему именно данный lock free алгоритм был интересен. В общем, планомерной работы по конкаррент ( lock free, wait free ) коллекциям - не заметно. Одни случайные классы/алгоритмы (как уже выяснилось по данной дискуссии "полезные" ))) ) добавили, другие, не менее, а возможно и более полезные и классические алгоритмы - нет.

ConcurrentLinkedQueue есть, а более простой и производительный Circle Ring Buffer нет.

AFAIK

"Нормальные библиотеки" ( TM ) сразу же включают в себя целую кучу алгоритмов:

SingleProducerSingleConsumer
MultiProducerSingleConsumer
SingleProducerMultiConsumer
MultiProducerMultiConsumer....

Bounded / unbounded и так далее.....

А Doug Lea из всей кучи выдернул одинокий ConcurrentLinkedQueue и включил его в стандартные либы. И по факту везде в проектах ConcurrentLinkedQueue и к месту и не к месту. Дабы других lock free и не дали.

Вот этот блог мне очень понравился. Очень интересные посты. Он учился у Doug Lea и писал/оптимизировал свой lock free коллекцию. В общем, как человек степ бай степ успешно учился многопоточки и оптимизации. Поскольку степ бай степ - то даже мне местами было понятно )))

http://psy-lob-saw.blogspot.com

Я так понимаю, он сейчас один из авторов org.jctools

https://github.com/JCTools/JCTools

Применительно собственно к теме топика (новые версии Java). Интересный факт, что изменение garbage collection на новый lock free алгоритмы запортило )))

http://psy-lob-saw.blogspot.com/2018/01/what-difference-jvm-makes.html

Oracle8u144:
pollsMade | 361.161 ± 4.126 ops/us

Oracle9.0.1:
pollsMade | 26.182 ± 2.273 ops/us

изучаешь изучаешь lock free алгоритмы, а тут приходит новый garbage collector и сам всюду блокировки раставляет )))