Bir Java dizesindeki hashCode () tutarlılığı

Bir Java Dizesinin hashCode değeri ( String.hashCode () ) olarak hesaplanır :

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

Aşağıdaki ifadenin yanlış olarak değerlendirileceği herhangi bir koşul (örneğin JVM sürümü, satıcı vb.) Var mı?

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

1. Güncelleme: Cevabın "evet, böyle durumlar var" olduğunu iddia ediyorsanız - o zaman lütfen "Bu bir Java dizesidir" .hashCode ()! = 586653468 ile ilgili somut bir örnek verin. Spesifik / somut olmaya çalışın olabildiğince.

2. Güncelleme: Hepimiz hashCode () 'un uygulama detaylarına güvenmenin genel olarak kötü olduğunu biliyoruz. Bununla birlikte, özellikle String.hashCode () hakkında konuşuyorum - bu yüzden lütfen cevabı String.hashCode () 'a odaklayın. Object.hashCode () bu soru bağlamında tamamen alakasızdır.

Bu belgeleri Java 1.2'ye kadar görebiliyorum.

Genel olarak aynı kalan bir karma kod uygulamasına güvenmemeniz gerektiği doğru olsa da , artık bunun için davranış olarak belgelenmiştir java.lang.String, bu nedenle onu değiştirmek mevcut sözleşmeleri bozmak olarak sayılır.

Mümkün olan yerlerde, sen sürümleri vb genelinde aynı kalıyor hash kodları güvenmemelisiniz - ama aklımda java.lang.Stringalgoritma çünkü özel bir durumudur etti belirtilmiş ... bu kadar uzun gibi doğru önce sürümleriyle uyumluluk terk etmeye istekli elbette algoritma belirtildi.

JDK 1.0 ve 1.1 ve> = 1.2 ile ilgili bir şey buldum:

JDK 1.0.x ve 1.1.x sürümlerinde, uzun Dizeler için hashCode işlevi her n'inci karakteri örnekleyerek çalıştı. Bu, aynı değere sahip birçok Dizeye sahip olacağınızı ve böylece Hashtable aramasını yavaşlatacağınızı garanti eder. JDK 1.2'de fonksiyon, şimdiye kadar sonucu 31 ile çarpacak ve ardından sırayla bir sonraki karakteri ekleyecek şekilde geliştirilmiştir. Bu biraz daha yavaştır, ancak çarpışmalardan kaçınmada çok daha iyidir. Kaynak: http://mindprod.com/jgloss/hashcode.html

Farklı bir şey, çünkü bir sayıya ihtiyacınız var gibi görünüyor: Karma kod yerine CRC32 veya MD5 kullanmaya ne dersiniz ve gitmekte fayda var - tartışma yok ve hiç endişe yok ...

Bir hash kodunun belirli bir değere eşit olmasına güvenmemelisiniz. Sadece aynı uygulama içinde tutarlı sonuçlar verecek. API belgeleri şunları söylüyor:

HashCode'un genel sözleşmesi:

• Bir Java uygulamasının yürütülmesi sırasında aynı nesne üzerinde birden çok kez çağrıldığında, nesnede eşittir karşılaştırmalarında kullanılan hiçbir bilgi değiştirilmediği sürece, hashCode yöntemi tutarlı bir şekilde aynı tamsayıyı döndürmelidir. Bu tam sayının, bir uygulamanın bir yürütmesinden aynı uygulamanın başka bir yürütmesine kadar tutarlı kalması gerekmez.

DÜZENLE String.hashCode () için javadoc, bir String'in karma kodunun nasıl hesaplandığını belirttiğinden, bunun herhangi bir ihlali genel API spesifikasyonunu ihlal eder.

Yukarıda belirtildiği gibi, genel olarak aynı kalan bir sınıfın hash koduna güvenmemelisiniz. Aynı uygulamanın aynı VM üzerinde daha sonra çalıştırılmasının bile farklı hash değerleri üretebileceğini unutmayın. AFAIK, Sun JVM'nin karma işlevi her çalıştırmada aynı karmayı hesaplar, ancak bu garanti edilmez.

Bunun teorik olmadığını unutmayın. Java.lang.String için karma işlevi , JDK1.2'de değiştirildi (eski karma, URL'ler veya dosya adları gibi hiyerarşik dizelerle ilgili sorunlar yaşadı, çünkü dizeler için yalnızca sonunda farklı olan aynı karmayı üretme eğilimindeydi).

java.lang.String özel bir durumdur, çünkü hashCode () algoritması (şimdi) belgelenmiştir, bu yüzden muhtemelen buna güvenebilirsiniz. Yine de kötü bir uygulama olduğunu düşünüyorum. Özel, belgelenmiş özelliklere sahip bir karma algoritmaya ihtiyacınız varsa, sadece bir tane :-) yazın.

Endişelenilmesi gereken bir diğer (!) Konu, Java'nın erken / geç sürümleri arasındaki olası uygulama değişikliğidir. Uygulama ayrıntılarının sabit olduğuna inanmıyorum ve bu nedenle gelecekteki bir Java sürümüne yükseltme yapılması sorunlara neden olabilir.

Sonuç olarak, uygulamasına güvenmem hashCode().

Belki de bu mekanizmayı kullanarak gerçekten çözmeye çalıştığınız sorunu vurgulayabilirsiniz ve bu daha uygun bir yaklaşımı vurgulayacaktır.

Sadece sorunuzu cevaplamak ve tartışmaya devam etmemek için. Apache Harmony JDK uygulaması farklı bir algoritma kullanıyor gibi görünüyor, en azından tamamen farklı görünüyor:

Güneş 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;
}

Kendiniz kontrol etmekten çekinmeyin ...

Değişikliklerden ve muhtemelen uyumsuz VM'lerden endişeleniyorsanız, mevcut karma kod uygulamasını kendi yardımcı program sınıfınıza kopyalayın ve bunu, karma kodlarınızı oluşturmak için kullanın.

Karma kod, Dizedeki karakterlerin ASCII değerlerine göre hesaplanacaktır.

Bu, String Sınıfındaki uygulama aşağıdaki gibidir

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

Karma kodda çarpışmalar kaçınılmazdır. Örneğin, "Ea" ve "FB" dizeleri 2236 ile aynı hashcode verir