Какая деталь реализации делает этот код настолько неудачным?

Ответ 1

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

Но действительно, неудача с NullPointerException происходит довольно часто. Я создал следующий код отладки, чтобы проиллюстрировать работу HashMap s:

static <K,V> void debugPut(HashMap<K,V> m, K k, V v) {
    if(m.isEmpty()) debug(m);
    m.put(k, v);
    debug(m);
}
private static <K, V> void debug(HashMap<K, V> m) {
    for(Field f: FIELDS) try {
        System.out.println(f.getName()+": "+f.get(m));
    } catch(ReflectiveOperationException ex) {
        throw new AssertionError(ex);
    }
    System.out.println();
}
static final Field[] FIELDS;
static {
    String[] name={ "table", "size", "threshold" };
    Field[] f=new Field[name.length];
    for (int ix = 0; ix < name.length; ix++) try {
        f[ix]=HashMap.class.getDeclaredField(name[ix]);
    }
    catch (NoSuchFieldException ex) {
        throw new ExceptionInInitializerError(ex);
    }
    AccessibleObject.setAccessible(f, true);
    FIELDS=f;
}

Используя это с помощью простого последовательного for(int i=0; i<5; i++) debugPut(m, i, i);, напечатанного:

table: null
size: 0
threshold: 1

table: [Ljava.util.HashMap$Node;@70dea4e
size: 1
threshold: 1

table: [Ljava.util.HashMap$Node;@5c647e05
size: 2
threshold: 3

table: [Ljava.util.HashMap$Node;@5c647e05
size: 3
threshold: 3

table: [Ljava.util.HashMap$Node;@33909752
size: 4
threshold: 6

table: [Ljava.util.HashMap$Node;@33909752
size: 5
threshold: 6

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

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

Но пошаговая отладка выявила еще больше шансов на нарушение:

Внутри метода putVal мы видим в конце:

++modCount;
if (++size > threshold)
    resize();
afterNodeInsertion(evict);
return null;

Другими словами, после успешной установки нового ключа таблица будет изменена, если новый размер превышает threshold. Таким образом, при первом put, resize() вызывается в начале, потому что таблица null, и поскольку указанная начальная емкость 0, т.е. слишком низкая, чтобы сохранить одно сопоставление, новая емкость будет 1 а новый threshold будет 1 * loadFactor == 1 * 0.75f == 0.75f, округлен до 0. Итак, в конце первого put, новый threshold превышен, а другая операция resize() запущена. Таким образом, с первой емкостью 0 первая put уже создает и заполняет два массива, что дает гораздо более высокие шансы сломаться, если несколько потоков выполняют это действие одновременно, все сталкиваются с начальным состоянием.

И есть еще один момент. Если посмотреть в операцию resize(), мы видим строки:

 @SuppressWarnings({"rawtypes","unchecked"})
 Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
 table = newTab;
 if (oldTab != null) {
     … (transfer old contents to new array)

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

Тем не менее, следует также отметить, что предположение о том, что все работает интерпретируется здесь, не основано. Поскольку HashMap также используется JRE внутри, даже до запуска вашего приложения, есть возможность встретить уже скомпилированный код при использовании HashMap.