увеличение concurrenthashmap сегментации

Question

Я проходил параллельную хэш-карту, согласно моим знаниям на данный момент, они по умолчанию сегментированы на 16 частей. каждая часть имеет свою долю пар ключевых значений. Если поток хочет удерживать блокировку пары ключей, он заблокирует весь сегмент. (Пожалуйста, поправьте меня, если я ошибаюсь где-нибудь). Теперь в этом link упоминается как chm хорош, когда авторы меньше. я задавался вопросом, увеличиваем ли мы количество сегментов, я имею в виду, что это сопоставимо с парами значений с номером ключа, разве нельзя создать параллелизм для большого количества потоков писем, работающих на одном и том же CHM. Кроме того, насколько дорогостоящим будет потребление памяти, из-за блокировок, присутствующих в CHM.

Благодаря

Джаендра

Answer 1

Если я правильно понимаю ваш вопрос, он ответил просто прямо в JavaDoc:

Разрешенный параллелизм между операциями обновления руководствуется дополнительным конструктором concurrencyLevel аргумент (по умолчанию 16), который является , используется как подсказка для внутренней калибровки. Таблица внутренне разделена, чтобы попытаться разрешить указанное количество одновременных обновлений без раздумий. Поскольку размещение в хэш-таблицах по существу случайное, фактический параллелизм будет отличаться. В идеале вы должны выбрать значение, чтобы разместить столько потоков, сколько когда-либо было , одновременно изменяя таблицу. Используя значительно более высокое значение, чем , вам нужно потратить пространство и время, а значительно меньшее значение может привести к конфликту в потоке . Но переоценки и недооценки в пределах на порядок не оказывают заметного воздействия. A Значение одного является подходящим, когда известно, что только один поток будет изменить, а все остальные будут прочитаны. Кроме того, изменение размера этого или любого другого хэш-таблицы является относительно медленной операцией, поэтому, если возможно, , это хорошая идея, чтобы предоставить оценки ожидаемых размеров таблиц в конструкторах .