Послідовність hashCode () в рядку Java

Значення хеш- коду Java-рядка обчислюється як ( String.hashCode () ):

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

Чи існують обставини (скажімо, версія JVM, постачальник тощо), за яких наступний вираз буде оцінюватися як хибний?

boolean expression = "This is a Java string".hashCode() == 586653468

Оновлення №1: Якщо ви стверджуєте, що відповідь "так, існують такі обставини" - тоді, будь ласка, наведіть конкретний приклад, коли "Це рядок Java" .hashCode ()! = 586653468. Намагайтеся бути максимально конкретними / конкретними якомога.

Оновлення №2: Усі ми знаємо, що покладатися на деталі реалізації hashCode () взагалі погано. Однак я говорю конкретно про String.hashCode () - тому, будь ласка, тримайте відповідь, зосереджену на String.hashCode (). Object.hashCode () абсолютно не має значення в контексті цього питання.

Я бачу цю документацію ще в Java 1.2.

Хоча це правда, що в цілому ви не повинні покладатися на те, щоб хеш-код залишався таким самим, тепер це документально підтверджено java.lang.String, тому що зміна може вважатись розривом існуючих контрактів.

Скрізь , де це можливо, ви не повинні покладатися на хеш - кодів залишаються тими ж в різних версіях і т.д. - але в моїй свідомості java.lang.Stringце особливий випадок , просто тому , що алгоритм був заданий ... до тих пір , поки ви готові відмовитися від сумісності з випусками до алгоритм був визначений, звичайно.

Я знайшов щось про JDK 1.0 та 1.1 та> = 1.2:

У JDK 1.0.x та 1.1.x функція хеш-коду для довгих рядків працювала шляхом вибірки кожного n-го символу. Це досить добре гарантовано, що у вас буде багато струнів хешування на одне значення, тим самим уповільнюючи пошук Hashtable У JDK 1.2 функція була вдосконалена для множення результату досі на 31, а потім додавання наступного символу послідовно. Це трохи повільніше, але набагато краще уникнути зіткнень. Джерело: http://mindprod.com/jgloss/hashcode.html

Щось інше, тому що вам, здається, потрібне число: Як щодо використання CRC32 або MD5 замість хеш-коду, і вам добре піти - ніяких дискусій і жодних турбот ...

Не слід покладатися на те, що хеш-код дорівнює певному значенню. Просто те, що воно поверне стійкі результати в межах одного виконання. Документи API кажуть наступне:

Загальним контрактом hashCode є:

• Кожного разу, коли він викликається на одному і тому ж об'єкті не раз під час виконання програми Java, метод hashCode повинен послідовно повертати одне ціле ціле число, за умови, що жодна інформація, що використовується в рівних порівняннях на об'єкті, не змінюється. Це ціле число не повинно залишатися послідовним від одного виконання програми до іншого виконання тієї самої програми.

EDIT Оскільки javadoc для String.hashCode () визначає, як обчислюється хеш-код String, будь-яке порушення цього може порушити специфікацію публічного API.

Як було сказано вище, загалом не слід покладатися на хеш-код класу, який залишається тим самим. Зауважте, що навіть наступні запуски одного і того ж додатка на одній VM можуть створювати різні значення хешу. AFAIK хеш-функція Sun JVM обчислює один і той же хеш на кожному запуску, але це не гарантується.

Зауважте, що це не теоретично. Хеш-функція для java.lang.String була змінена в JDK1.2 (старий хеш мав проблеми з ієрархічними рядками, такими як URL-адреси або імена файлів, оскільки він, як правило, створював той самий хеш для рядків, який відрізнявся лише в кінці).

java.lang.String - особливий випадок, оскільки алгоритм його hashCode () документально (зараз) задокументований, тому ви, напевно, можете покластися на це. Я б все-таки вважав це поганою практикою. Якщо вам потрібен алгоритм хеш із спеціальними, задокументованими властивостями, просто напишіть один :-).

Ще одне (!) Питання, про яке слід турбувати, - це можлива зміна впровадження між ранньою та пізньою версіями Java. Я не вірю, що відомості про впровадження встановлені в камені, і тому потенційно оновлення до майбутньої версії Java може спричинити проблеми.

Суть полягає в тому, що я б не покладався на реалізацію hashCode().

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

Просто відповісти на ваше запитання і не продовжувати ніяких дискусій. Реалізація JDK Apache Harmony, схоже, використовує інший алгоритм, принаймні, це виглядає зовсім інакше:

ВС JDK

public int hashCode() {
    int h = hash;
    if (h == 0) {
        int off = offset;
        char val[] = value;
        int len = count;

        for (int i = 0; i < len; i++) {
            h = 31*h + val[off++];
        }
        hash = h;
    }
    return h;
}

Гармонія Apache

public int hashCode() {
    if (hashCode == 0) {
        int hash = 0, multiplier = 1;
        for (int i = offset + count - 1; i >= offset; i--) {
            hash += value[i] * multiplier;
            int shifted = multiplier << 5;
            multiplier = shifted - multiplier;
        }
        hashCode = hash;
    }
    return hashCode;
}

Сміливо переконайтеся самі ...

Якщо ви турбуєтесь про зміни та, можливо, несумісні VM, просто скопіюйте існуючу реалізацію хеш-коду у свій власний клас утиліти та використовуйте її для створення своїх хеш-кодів.

Хеш-код буде розрахований на основі значень ASCII символів у рядку.

Це реалізація в String Class наступним чином

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        hash = h = isLatin1() ? StringLatin1.hashCode(value)
                              : StringUTF16.hashCode(value);
    }
    return h;
}

Зіткнення у хеш-коді неминучі. Наприклад, рядки "Ea" і "FB" дають той же хеш-код, що і 2236