забыл никесли хочется разобраться то рекомендуемая книга Java Concurrency in Action, да непростая, но закроет почти все вопросы.
P/S. Заметил тенденцию - большинство программистов за 30 любят,уважают и почитывают именно книги, хотя не брезгуют и статьями и видео. Когда говорю молодому прочти книгу - вертят нос, и идут на хабр.. Печально это все
клевая книга. но чтоб ее понять надо прочесть не раз думаю и попробовать, честно столкнувшись с тем что там говорится. ну хотя б чуть-чуть. да, мне за 30 ))

mr_virtusМожет, пожалуйста, кто подскажет, какие классы из Concurrent Collections используете в работе, почему именно их?
В чём выигрыш при использовании java.util.concurrent.* пакета по сравнению с другими "средствами" работы с многопоточностью(типа synchronized).
ощущение что тебя на собеседовании об этом спросили ))

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

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

Вы серьёзно? Почитайте хотя бы java.util.concurrent.ConcurrentHashMap#get и попытайтесь его понять. А потом попробуйты выразить чего через эти ваши вейты и нотифаи.
Или хотя бы первый абзац javadoc'а для этого класса почитайте.
напиши свою реализацию этого инструмента. это просто очередная библиотечка и всё. в то время как всякие синхронайзы вейты нотифаи - это фундаментальные решения платформы.

я слышал противоположное мнение что локфри проще чем алгоритмы написаные на локах (вейтнотифаяхсинхронайзах).

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

Для чего тебе эта очередь нужна? Вопрос так сказать для понимания задачи в целом.

он использует нативные вызовы.. вот и всё.. ты их тоже можешь использовать :)

Leonid KudryavtsevПросто коллекция. С очередью придумать сложно, ну пусть будет HashMap в котором для системе чата храним список юзеров которые в чате зарегистрировались.

Т.е. при поступлении сообщения от юзера (паралельно обрабатываются в разных обработчиках), например проверяем наличия записи в HashMap (требуется конкуррент доступ) и в зависимости от наличия/отсутвия такого юзера или работаем дальше или говорим пользователю ошибку - вы не зарегистировались в чате.

Достоинства использования коллекций из java.concurrent перед

synchronized {
обычный HashMap
}

производительность и меньшее кол-во реальных/"машинных" блокировок/коллизий

1) В случае synchronized или "мессадж бейсд" - у нас доступ к коллекции всегда осуществляется __единственным__ работающим потоком/CPU, остальные ждут. Или ждут на synchronized, или, при "мессадж бейсд", пока разгребатель мессаджей (актор) не освободится

Плюс, при "мессадж бейсд", потеря перформанса/latency на самих мессаджах должна просто зашкаливать. В общем, совершенно не нужный и лишний overhead при наличие стандартного пакета/классов обеспечивающих нужный функционал.

2) В случае конкурентных реализаций HashMap, если на верхнем уровне HashMap партиционирован, то в оптимальном случае, доступ к коллекции/данным осуществляется сразу несколькими потоками/CPU, истинно параллельно. Поэтому они и concurrent collection.

Алгоритмы "обычных" коллекций и concurrent коллекций - совершенно разные.

p.s. точных детали реализации concurrent коллекций из данного пакета в java - не помню (про HashMap). Плюс стандартные java'вские реализации часто неэффективны. Но всегда можно заюзать сторонние коллекции с нужными алгоритмами/характеристиками.

IMHO & AFAIK
чот вы не то говорите )) причем тут синхронайз и мессаджбейсд? никаких синхронайзов вообще. у нас есть продусеры есть консумеры. если продусеров много а консумеров мало добавляем консумеров. и дальше сколь угодно далеко пока то что исполняет роль брокера не помрет. а когда помрет мы и его добавим.
зачем работать с мутабельными объектами вообще? конечно шаред мутабл обжект так или иначе вы будете и обязаны и должны каким-то образом использовать такими вот "конкурентными" инструментами. а если у нас их вообще нет? то и инструменты не нужны.

насчет разноса когда на микроблоки и общение через посредника - да, это будет оверхед. но это временно.. ну сколько у вас там потоков параллельно ваша жвм вытянет? сильно больше чем количество ядер? нет. а представьте у вас чатик, где не 100 юзеров или 1000 или 10 000, а 10 миллионов? что вы там со своими коллекциями несчастными будете делать? да ничего.

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

Leonid KudryavtsevandreykaTконсумеров мало добавляем консумеров

И как РАЗНЫЕ консумеры будут из ОДНОЙ коллекции результат возврашать?
Какой тип коллекции будете использовать, если консумеров много?

Код пожалуйста. Есть обработчик Web-запросов, нужна ОБЩИЙ HashMap со списком текущих пользователей.

Web-запрос просто проверяет наличие user'а в HashMap и возврашает Ok или Error (нет такого пользователя)

Какой использовать тип коллекции?
Как это будет выглядить в Вашем случае "ивент басед"?

Можно, конечно, самому делать шардинг (разные консумеры с шарднутыми очередями + протокол синхронизации + протокол единого интератора + черти что еще), но зачем? Когда есть полно стандартных реализаций concurent HashMap.

Мало того, сама очередь сообщений между продюсерами и консумерами, скорее всего, будет сделана на java.concurent.LinkedQueue. Т.е. получается масло-масленное. Дабы не использовать java.concurrent будем городить "евент басд" велосипед, который все равно через java.concurent.LinkedQueue работает.
если у вас стоит скажем лоадбалансёр и некоторое количество инстансов, обрабатывающих хттп запросы в какой хашмапе вы это всё собрались хранить? :) будете хранить в хашмапе первого инстанса - второй об этом будет ни сном ни духом. и наоборот. а если у вас этих инстансов с десяток крутится?
ответ прост - никакой хашмап я не буду использовать ибо это невозможно. я заюзаю редиса. и буду использовать редис в качестве мапы для хранения КВ данных и все инстансы будут бежать туда чтоб посмотреть кто из юзеров залогинен а кто нет.
будет мало производительности одного редиса - добавлю еще один. и так до бесконечности.