java.util.concurrent. Часть первая: Зачем и почему?

[@SiGMan]

lock-free контейнеры из java.util.concurrent вкупе с work-stealing планировщиком — очень мощное средство data-parallel программирования, спасибо Doug Lea. Одна из самых «красивых» стандартных библиотек, на мой взгляд.

[@ntz]

Чего не хватает в java.util.concurrent, дак это класса ConcurrentLinkedHashMap (хотя есть сторонние реализации), который бы позволил эффективно и просто реализовывать кэш со стратегиями типа LRU и прочими.

[@Sauron]

Я не пробовал, но может можно «задекорировать» ConcurrentHashMap в commons ListOrderedMap?

[@1ex]

Как то так получилось многослов. В свое оправдание замечу что многие известные мне так называемые синьоры при вопросе «Зачем нужна многопоточность» падают в осадок

[@1ex]

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

Личное мнение (возможно очень субьективное): чем больше человек понимает суть вещей с которыми работает — тем более он для меня синьор и тем более он для меня авторитет, потому что он потратил время и силы чтобы разобраться и способен обосновать принятое решение.

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

[@javenue]

Абсолютно нормальный вопрос. Часто задаю его на собеседовании (чтобы избежать флуда сразу скажу, перед собеседованием я заранее извиняюсь за вопросы, которые кандидату могут показаться слишком простыми). Тем не менее часто люди, которые претендуют на позицию senior, отвечают, например: «для генерации отчетов». А когда, например, разговор доходит до I/O операций, вообще не понимают, как это связано с многопоточностью.

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

[@Zorkus]

Синьоров по Java надо спрашивать, что такое, как работает и зачем нужны count-down latch, cyclic barrier, blocking queues, и в двух словах как они релизованы. А еще по lock-free алгоритмам в простейших задачах. Типа — напишите класс и метод, который возвращает последовательно все степени двойки, чтобы было thread-safe, NON-synchronized, lock-free.

[@stepio]

Как насчет статьи на тему? Если кинете в личку ссылку, обещаю как минимум один плюс :)

[@Zorkus]

На тему чего именно? Про все понемногу, или по отдельности, по порядку, глубоко-проникающе? :)

[@stepio]

Ну на тему lock-free алгоритмов в простейших задачах. Глубина проникновения на Ваш выбор :)

[@Zorkus]

ОК — можно)

[@1nd1go]

Ну зачем в личку? можно и в паблик ;)

[@Zorkus]

Статейку по теме, сэр?) Согласен, об этом тоже было бы неплохо почитать…

[@Zorkus]

Да-да, я об этом раньше ниже уже отпостил, в посте про то, что бы я хотел видеть в следующих статьях серии))

[@Yakhnev]

Кто такой «убежденный программист»? Было бы здорово, если бы при переводе никто не пользовался техникой правки автоматического перевода

[@1ex]

Каждый убежденный негодяй ложится спать точно по распорядку (с) Холмс

[@Zorkus]

А еще он делает это всегда правой, да :-D

[@Zorkus]

Посыл хороший, но это введение. Ждем следующих статей!

Можно несколько пожеланий? Было было неплохо, если бы вы затронули:

— count-down latches, cyclic barriers, blocking queues
— Различные виде threadpool-ов, и соответствующих executors
— Java Memory Model в целом (http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html), double-checked locking и volatile переменные, с описанием процесса захвата/отпускания мониторов, before-after actions, фиксация / инвалидация кешей потока и так далее :)
— Atomics и как они работают внутри
— Персистентные структуры данных в многотопоточных окружениях
— транзакционная память

что-то меня понесло :) Ну вот что-то такое я бы хотел увидеть в этой серии. С отдельными статьями наверное мог бы помочь.

[@1ex]

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

[@javenue]

Разрушение небольшого мифа по поводу wait и notify — www.javenue.info/post/91
Может начинающим интересно будет.

[@Oblitus]

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

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

[@denlion]

Мне кажется, что слова «Их несколько» смотрятся очень нелогично там. Есть предложение поменять на «Причин несколько». Спасибо за статью, просто резануло глаз.

[@1ex]

В самом деле так, исправил. Спасибо!

[@mark_stein]

«Ну вот, на самом интересном месте ...»

Вторая часть — для прагматиков — будет?