AtomicReferenceFieldUpdater сомнение

Question

Я создавал concurrnetHashtable, который подходит для меня и мало отличается от concurrentHashMap, и я использую AtomicReferenceFieldUpdater для выполнения операции CASNext (обычно поддерживается CAS, но этим мы также можем выполнить CASNext), поэтому я иду по правильному пути?Хотя обычно я получаю хорошую производительность в этом concurrentHashTable, чем блокировку хеш-таблицы, но иногда ничего не получается.
Так что я пришел к следующему выводу:
если число доступных процессоров больше, чем количество блоков, доступных в хеш-таблицетогда существует более высокая вероятность получения конкуренции за блокировку, поэтому в этом случае concurrentHashTable будет работать лучше, чем подход с блокировкой, и, конечно, если чтения много (журналы говорят, что операция чтения выполняется на 85-90%), тогда это хорошо для использования.подскажите мне, я иду по правильному пути и правильно ли все понимаю?
если у вас есть время, посмотрите код на этой странице code В этой хэш-таблице я делаю вставки, если элемент еще не существует ... так скажите мне, является ли это правильным подходом без блокировки?

Answer 1

Не прямой ответ, но если вы хотите улучшить CHM, взгляните на тот, который написал Dr. Cliff Click: здесь

Кроме того, трудно помочь, не зная, что вы пытаетесь решить ...

Answer 2

в параллельной хэш-карте есть три основные операции, о которых нужно беспокоиться: добавление элемента, удаление элемента и повторная хеш-функция

при удалении и добавлении достаточно просто с использованием только CaS

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