Здравствуйте. И извиняйте за многабукф, но по-другому не получилось.

Дано:
1) несколько потоков (в примере ниже их пять);
2) коллекция HashMap<Integer, Long>. Ключ коллекции - монотонно возрастающая послед-сть натуральных чисел. Значение - пофиг какое, хотя бы Thread.currentThread().getId() для каждого из заполняющих потоков.

Задача : затолкать в Map 500 тыс строк, обеспечив параллельное выполнение этой задачи пятью потоками (т.е. дать каждому задание на ввод 100 тыс кортежей; далее это число обозначено LIM4THREAD).

Сваял нечто, пытающееся затолкать эти строки одним из нескольких способов:
1) через AtomicInteger
2) через синхронизированный static-метод
3) нечестным способом, полагающим, что id потока всегда < MAX_INTEGER и вычисляющий для каждого потока и значения переменной-счетчика значение ключа по крестьянской формуле: (int)tid*LIM4THREAD+i
4) ("факультатив") просто плюнул на требование вставки 500 тыс уникальных кортежей и решил отдать эту коллекцию на растерзание пяти потокам, которые выполняли бы вставку так:
- и это значит, что в коллекции в итоге должно находиться ровно 100 тыс строк (все потоки генерят ключи из одного и того же диапазона, никаких atomicInteger'ов и sync-методов не используем).

Результаты озадачили.
1. Через AtomicInteger:
1.1. Выдает изредка (1 раз в 5-10 запусков) исключение ArrayIndexOutOfBoundsException на строке, добавляющей в коллекцию кортеж, т.е. вот на этом: m.put( newAtomId(), tid );
1.2. Несмотря на то, что число итераций, выполняемых каждым потоком, действительно равно 100 тысячам, общее число строк в коллекции МЕНЬШЕ на 15...20 тысяч(!)
1.3. ВСЕ вызовы m.put(...) возвращали null, что означает: вставляемый ключ был уникален, т.е. дублей не было. И это как-то совсем не вяжется с предыдущим пунктом :(
1.4. Если не давать потоку передых внутри цикла (см ниже: try { Thread.sleep(100); } catch(Exception x) { x.printStackTrace(); }), то изредка возможны какие-то совершенно мёртвые затыки. Код просто НЕ выполняется до конца, всё зависает. И это - самое загадочное :-/

2. Через синхронизированный static-метод

2.1. Не выявлено (см выше, пункт 1.1)
2.2. Итоговое число строк также меньше требуемого, но уже не на 15-20 тысяч, а "гораздо лучше": всего на 2-3 сотни.
2.3. Так же, как в пункте 1.
2.4. Не выявлено (см выше, пункт 1.4)

3. Через "наивную формулу": ключ = (int)tid*LIM4THREAD+i
3.1. Не выявлено (см выше, пункт 1.1)
3.2. Итоговое число определить невозможно: всё зависает вусмерть, см. 3.4
3.3. Число дублей также определить невозможно по причине заклинивания.
3.4. Мёртвый зависон не просто возможен, а гарантирован на каждом запуске. Иногда - уже на первом потоке, начавшем заполнение, иногда - на последующих.

4. "Факультатив": попытка добавить всеми потоками одни и те же кортежи с ключами от 0 до 99999.
Здесь подпункты 4.1 ... 4.4 точно такие же, как и в предыдущем п. 3 .

Вправьте мозг, плз:
1) как добиться, чтобы в коллекцию таки записалось ровно 500 тыс элементов ?
2) откуда может вылезать ArrayIndexOutOfBoundsException, ведь оно даже в доке для этого метода - HashMap.put() - не оговаривается
3) откуда мёртвые затыки в способах 3 и 4 (да еще на разных стадиях выполнения) ?

Код (перечисленные выше варианты указаны так: [ 1 ], [ 2 ] и т.д.):

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

С отсутствием части ключей - ясно, псип.
А мёртвые затыки - они тоже от этого ? Это дедлоки какие-то или что ?

cdtyjvЭто тестовая задача, автор хочет разобраться, как наполнять коллекцию из нескольких потоковда, именно так.

cdtyjvПосмотрите в дебагере, или сделайте дамп тредов через jps/jstack.Постараюсь, в ближайшем обозримом. Но если там (в дампах) ничего не получится понять, приду снова сюда :-)
Впрочем, главное я понял: надо перечитывать доку ( эту и еще несколько критичных) каждый день. С утра и на ночь.
Ведь видел же этот раздел - Concurrent Map Implementations - а всё равно не запомнил, пока не попробовал пальцАми.