Comments 9
Спасибо за интересную подборку. В очередной раз убеждаюсь - век живи, век учись. Про 4 пункта из 8 не знал, хотя с потоками в своё время ну очень плотно работал. Ну и статья про старое API, а не про новый синтаксис - как глоток свежего воздуха.
Понимаю, что это лишь перевод, и претензии к автору оригинала, но обсудить можно.
Не такие уж это и "неизвестные" механизмы. Причина, по которой они редко встречаются в коде, думаю, многим понятна – это очень узкоспециализированные механизмы, некоторые и вовсе бесполезные в прикладной разработке.
StampedLock, Concurrent Accumulators, Phaser – вещи сугубо для сильноконкурентных приложений, потому как для обычных бизнес-приложений есть более понятные механизмы и выгоды от StampedLock вы не увидите. И вот, если вы пишите такие сильноконкуретные вещи, то скорее всего вы уже итак глубоко знакомы java.util.concurrent.
TimeFormat "B" показывающий "in the morning" такое себе, чаще всего (и правильнее) форматирование даты/времени происходит на клиенте, а для machine-to-machine используется бинарный формат.
HexFormat, что появился в 17 java. Ну наконец-то, ждали его с 95 года, и как же мы без него жили-то? sarcasm. :)
Для DelayQueue я даже не могу придумать реальную бизнес-задачу.
О BinarySearch для отсортированных массивов думаю знает любой джун.
BitSet тоже всем известная вещь. И важно отметить, что он непотокобезопасен. В отличие от того же boolean[].
И важно отметить, что он непотокобезопасен. В отличие от того же boolean[].
Справедливости ради, сам по себе голый boolean[] является потокобезопасным только при чтении из него.
DelayQueue использую в заглушке для тестовых прогонов, чтобы имитировать задержку возвращения ответа)
Для бизнеса, например, можно ставить напоминания. Понятно, что можно и другими способами сделать)
Обычно это предпочтительнее чем
AtomicLong, когда несколько потоков обновляют общее значение.
Здесь стоило бы вкратце указать за счёт чего именно LongAccumulator выигрывает у простого атомика при одновременном доступе из многих потоков, а также упомянуть LongAdder, тем более что в большинстве случаев его достаточно.
В доке https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/LongAccumulator.html написано:
This class is usually preferable to AtomicLong when multiple threads update a common value that is used for purposes such as collecting statistics, not for fine-grained synchronization control. Under low update contention, the two classes have similar characteristics. But under high contention, expected throughput of this class is significantly higher, at the expense of higher space consumption.
Кратко: эти два класса имеют схожие характеристики. Но при высокой конкуренции ожидаемая пропускная способность этого класса значительно выше.
В своём вопросе я имел ввиду краткое описание механизма, обеспечивающего лучшую производительность (здесь - выравнивание по кэш-линии). И LongAccumulator во многих случаях избыточен, вместо него можно взять LongAdder, реализующий то же выравнивание. Понятно, что эти вопросы скорее к Петру Миньковскому, автору оригинала )
Я не особо копенгаген в java, поэтому не воспринимайте слишком сурово вопрос от мимокрокодила. Я что-то не особо понимаю, в чём смысл поиска позиции вставки в структурах, не допускающих расширения. Логичнее смотрелось бы на динамическом массиве и на одно/дву-связном списке, не? Или в java эти методы можно вызвать и с для динамического массива и связного списка?
Полезные и неизвестные возможности Java