Согласованность hashCode () в строке Java

Значение hashCode Java String вычисляется как ( 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 функция hashCode для длинных строк работала путем выборки каждого n-го символа. Это довольно хорошо гарантирует, что у вас будет много хешированных строк с одним и тем же значением, что замедлит поиск в Hashtable. В JDK 1.2 функция была улучшена: полученный результат умножается на 31, а затем добавляется следующий символ по порядку. Это немного медленнее, но помогает избежать столкновений. Источник: http://mindprod.com/jgloss/hashcode.html

Что-то другое, потому что вам, кажется, нужен номер: как насчет использования CRC32 или MD5 вместо хэш-кода, и все готово - никаких дискуссий и никаких забот ...

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

Общий контракт hashCode:

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

EDIT Поскольку Javadoc для String.hashCode () определяет , как вычисляется хэш - код в строку, любое нарушение этого нарушило бы спецификацию общественного API.

Как было сказано выше, в целом не следует полагаться на то, что хеш-код класса остается неизменным. Обратите внимание, что даже последующие запуски одного и того же приложения на одной виртуальной машине могут давать разные хеш-значения. AFAIK хеш-функция Sun JVM вычисляет один и тот же хеш при каждом запуске, но это не гарантируется.

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

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

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

Суть в том, что я бы не стал полагаться на реализацию hashCode().

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

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

Sun 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;
}

Апач Гармония

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;
}

Не стесняйтесь проверить это сами ...

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

Хэш-код будет рассчитан на основе значений ASCII символов в строке.

Это реализация в классе String выглядит следующим образом

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.