Different implementations of HashMap in Android and Java

This article reproduced others, the original address: http://www.xyczero.com/blog/article/16/

Cause

Today in the project encountered a very "wonderful" problem. This is basically the case: Android terminal and Server (Spring), the exact same string key value to put in the HashMap in order, which directly led to the server and Android terminal with the HmacSHA256 algorithm encryption of the digest is not the same, The server will not be able to verify the data correctly.

And then with a depressed mood to the program add a breakpoint for reasons to find, found that the original is hashmap in the server and the terminal of the same key store order is not the same!

In the case of hashcode conflict, different keys should be stored in the same position in the HashMap, even if the hashcode generates a flush, and if the Key-value put is in the same order, the location should be the same.

Look for, solve

So the problem should be out on the HashMap, only to see the Java and Android on the source of HashMap, found that the Hashcode () method is not the same, a little excited a bit, can look carefully, Discover that Android is just optimizing the Hashcode () method in Java to make it easier to read, but the same principle is true =. =
The specific code is compared as follows:

<！-- Android -->@Override public int hashCode() {    int hash = hashCode;    if (hash == 0) {        if (count == 0) {            return 0;        }        final int end = count + offset;        final char[] chars = value;        for (int i = offset; i < end; ++i) {            hash = 31*hash + chars[i];        }        hashCode = hash;    }    return hash;}<！-- Java-->public int hashCode() {    int h = hash;    int len = count;    if (h == 0 && len > 0) {        int off = offset;        char val[] = value;        for (int i = 0; i < len; i++) {            h = 31*h + val[off++];        }        hash = h;    }    return h;}

Helpless, I can only continue to view the comparison in the source code, and finally found that the default constructor is different, in essence, the table size is not the same, Java table default size is 16*0.75=12 (capacity * load factor), The default size of table in Android is 2, so even the same strings are placed in HashMap in the same order, and their key values are stored in a different order.

<!-- Android -->private static final Entry[] EMPTY_TABLE        = new HashMapEntry[MINIMUM_CAPACITY >>> 1];//默认构造函数public HashMap() {    table = (HashMapEntry<K, V>[]) EMPTY_TABLE;    threshold = -1; // Forces first put invocation to replace EMPTY_TABLE}<!-- Java -->static final int DEFAULT_INITIAL_CAPACITY = 16;static final float DEFAULT_LOAD_FACTOR = 0.75f;//默认构造函数public HashMap() {    this(DEFAULT_INITIAL_CAPACITY,DEFAULT_LOAD_FACTOR);}

In fact, carefully read the source code will find that in Android implementation of the HashMap class about the "threshold (threshold)" setting has been different from Java, specifically, see the source of interception:

<!-- Android -->//阈值固定取其table大小的3/4threshold = (newCapacity >> 1) + (newCapacity >> 2); <!-- Java -->//阈值取容量*负载因子或最大容量+1间的小值threshold = (int)Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);

Summary

So summing up to see HashMap in different platforms or different language implementation details are not the same, a fall into, your wit, anyway, remember, involved in order when HashMap really not fit!

HashMap different implementations in Android and Java