Учитывая, что HashMaps в jdk1.6 и выше вызывают проблемы с multi = threading, как мне исправить мой код

Ответ 1

Я являюсь оригинальным автором патча, который появился в 7u6, CR # 7118743: Альтернативное хеширование для строки с помощью хэш-карт.

Я сразу же подтвержу, что инициализация hashSeed является узким местом, но мы не ожидаем, что это будет проблемой, поскольку это происходит только один раз за экземпляр Hash Map. Чтобы этот код был узким местом, вам нужно будет создавать сотни или тысячи хеш-карт в секунду. Это, конечно, не типично. Действительно ли действительная причина для вашего приложения делать это? Как долго живут эти карты хеша?

Независимо от того, мы, вероятно, будем исследовать переход к ThreadLocalRandom, а не Random и, возможно, к некоторому варианту ленивой инициализации, предложенной cambecc.

РЕДАКТИРОВАТЬ 3

Исправление для узкого места было перенесено на обновление ртутного репо JDK7:

http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b03bbdef3a88

Исправление будет частью предстоящей версии 7u40 и уже доступно в выпусках IcedTea 2.4.

Ближайшие финальные сборки 7u40 доступны здесь:

https://jdk7.java.net/download.html

Обратная связь по-прежнему приветствуется. Отправьте его в http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev, чтобы убедиться, что он открывается разработчиками openJDK.

Ответ 2

Это похоже на "ошибку", с которой вы можете работать. Существует свойство, которое отключает новую функцию "альтернативного хеширования":

jdk.map.althashing.threshold = -1

Однако отключение альтернативного хэширования недостаточно, потому что оно не отключает генерацию случайного хеш-семени (хотя это действительно так). Поэтому, даже если вы отключите хеширование alt, у вас все еще есть конфликт потоков во время создания хэш-карты.

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

// Create an instance of "Random" having no thread synchronization.
Random alwaysOne = new Random() {
    @Override
    protected int next(int bits) {
        return 1;
    }
};

// Get a handle to the static final field sun.misc.Hashing.Holder.SEED_MAKER
Class<?> clazz = Class.forName("sun.misc.Hashing$Holder");
Field field = clazz.getDeclaredField("SEED_MAKER");
field.setAccessible(true);

// Convince Java the field is not final.
Field modifiers = Field.class.getDeclaredField("modifiers");
modifiers.setAccessible(true);
modifiers.setInt(field, field.getModifiers() & ~Modifier.FINAL);

// Set our custom instance of Random into the field.
field.set(null, alwaysOne);

Почему (возможно) это безопасно? Поскольку альфа-хеширование отключено, это приводит к игнорированию случайных хеш-семян. Поэтому не имеет значения, что наш экземпляр Random на самом деле не случайен. Как всегда с такими неприятными хаками, пожалуйста, используйте с осторожностью.

(Благодаря fooobar.com/questions/18683/... для кода, который устанавливает статические конечные поля).

--- Редактировать ---

FWIW, следующее изменение на HashMap приведет к устранению конфликта потоков при отключении хеширования:

-   transient final int hashSeed = sun.misc.Hashing.randomHashSeed(this);
+   transient final int hashSeed;

...

         useAltHashing = sun.misc.VM.isBooted() &&
                 (capacity >= Holder.ALTERNATIVE_HASHING_THRESHOLD);
+        hashSeed = useAltHashing ? sun.misc.Hashing.randomHashSeed(this) : 0;
         init();

Аналогичный подход можно использовать для ConcurrentHashMap и т.д.

Ответ 3

Есть много приложений, которые создают переходную HashMap на запись в больших приложениях данных. Например, это синтаксические анализаторы и сериализаторы. Включение любой синхронизации в классы несинхронизированных коллекций - это реальный вопрос. По-моему, это неприемлемо и необходимо исправлять как можно скорее. Изменение, которое, по-видимому, было введено в 7u6, CR # 7118743, должно быть отменено или исправлено без каких-либо операций синхронизации или атома.

Как-то это напоминает мне колоссальную ошибку в синхронизации StringBuffer и Vector и HashTable в JDK 1.1/1.2. Люди платили дорого за годы за эту ошибку. Не нужно повторять этот опыт.

Ответ 4

Предполагая, что ваш шаблон использования является разумным, вы захотите использовать свою собственную версию Hashmap.

Этот фрагмент кода позволяет значительно усложнить хэш-коллизии, не позволяя злоумышленникам создавать проблемы с производительностью (подробности) - при условии, что эта проблема уже рассматривается каким-то другим способом, я не думаю, что вам потребуется синхронизация вообще. Однако, если вы используете синхронизацию или нет, вам кажется, что вы захотите использовать свою собственную версию Hashmap, поэтому вы не будете так сильно влиять на то, что предоставляет JDK.

Таким образом, либо вы обычно пишете что-то подобное и указываете на это, либо переопределяете класс в JDK. Чтобы сделать последнее, вы можете переопределить путь класса bootstrap с помощью параметра -Xbootclasspath/p:. Тем не менее, это будет "противоречить лицензии двоичного кода Java 2 Runtime Environment" (источник).