Непротиворечивость хэш-кода () на строке Java

Я нашел кое-что о 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 должен последовательно возвращать одно и то же целое число при условии никакая информация, используемая в сравнениях равных на объекте, не изменяется. Это целое число не должно оставаться согласованным при выполнении одного приложения другому исполнению того же приложения.

РЕДАКТИРОВАТЬ Поскольку javadoc для String.hashCode () определяет способ вычисления хеш-кода String, любое нарушение этого может привести к нарушению спецификации публичного API.

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

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

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

Using

SELECT max(id) FROM table;

should be fine from inside a transaction, or does ODBC not support transactions?

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

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

java.lang.String является особым случаем, поскольку алгоритм его 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;
}

Apache Harmony

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

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