- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
public int hashCode() {
int h = hash;
if (h == 0 && value.length > 0) {
char val[] = value;
for (int i = 0; i < value.length; i++) {
h = 31 * h + val[i];
}
hash = h;
}
return h;
}
Да это же сишники писали!
Не исключено, что оптимизация, связанная с локальностью переменной, но это надо дизассемблировать и измерять.
Пример: строка 77
Мой реверс-инжиниринг мыслительного процесса говорит что там кто-то думал насчет `byte []`. И в будущем прикручивание лучшей хэш функции. Потому что *31 это относительно слабая хэш функция.
"Это какая-то особая уличная магия с оптимизацией?"
Если value это внутрее представление, то эта строка кода скорее всего будет выкинута оптимизатором. Потому что ничего не делает.
При вызове метода hashCode() у одного экземпляра java.lang.String из разных потоков будет гонка потоков (data race) по полю hash.
То же относится и к полю value.
Где там об этом написано? :)
> This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write
если бы части по 32 бита были не атомарными, возможных комбинаций было бы гораздо больше (например, 0-15 и 32-47 биты от первого, остальные от второго).
Но явной фразы не нашлось :(
Ну это же всего лишь пример ситуации, которая может возникнуть, а не полный список вариантов? :)
Ее разве не закопали?
есть гурманы, которых устраивает пользоваться однажды аттестованным по ИБ перечнем версий ПО
И пофиг, что это ПО давным-давно превратилось в дуршлаг ;)
но зато "модель нарушителя" ёпт
а уж как волокита по ИБ тормозит прикрытие 0-day уязвимостей
инициативный дурак хуже вредителя
Так что все придумано до нас ;)
Вообще, полезно выносить в локалы что-то, что вы собираетесь использовать в циклах, если это что-то, конечно, не должно быть вдруг не внезапно изменено другим тредом прям посреди цикла, а вы как раз только этого и ждете.