起因
在项目中遇到一个很"奇葩"的问题。情况大致是这样的：Android终端和服务器(Spring)，完全相同的字符串键值对放入HashMap中竟然顺序不一样，这直接导致了服务器和Android终端用HmacSHA256算法加密出的摘要也不一样，服务器也无法进行正确的数据验证。
然后带着郁闷的心情给程序加断点进行原因寻找，发现原来是HashMap的中服务器和终端双方对于同样的key存放顺序竟然不一样！
在HashCode产生冲突的情况下，不同的key在HashMap中存入的位置应该是相同的，即使在hashCode产生冲入，如果key-value put的顺序相同，其存放的位置
标题中的核心知识点主要围绕“HashMap在Android和Java中的不同实现”，描述中提到的问题是由于Android和Java中HashMap的实现差异导致的，特别是初始化时默认表大小（table size）和阈值计算方式的不同，影响了键值对的存储顺序，进而影响了基于HashMap的哈希算法结果。
1. **哈希表的顺序问题**：
在哈希表如HashMap中，键值对的插入顺序并不保证，因为哈希表基于数组和链表结构，不同平台或实现可能会有不同的策略处理哈希冲突。哈希表的插入顺序依赖于`hashCode()`方法和负载因子（load factor），以及表的大小。当多个键的哈希值相同时，它们会在同一个槽位形成链表，但如果表的大小不同，相同的哈希值可能落在不同的相对位置。
2. **Android与Java中HashMap的默认构造函数差异**：
- **Android**：默认的table大小为`MINIMUM_CAPACITY>>>1`，即2，这是由于Android的HashMapEntry数组初始化为`MINIMUM_CAPACITY`的一半。
- **Java**：默认的table大小为`DEFAULT_INITIAL_CAPACITY`，即16，并且负载因子为`DEFAULT_LOAD_FACTOR`，即0.75。因此，Java中的初始容量通常是16×0.75=12。
3. **阈值计算**：
- **Android**：阈值计算为新容量的一半加上新容量的四分之一，即`threshold = (newCapacity >> 1) + (newCapacity >> 2)`，这确保了在扩容时的阈值固定为表容量的3/4。
- **Java**：阈值取容量乘以负载因子或`MAXIMUM_CAPACITY + 1`之间的较小值，即`threshold = (int)Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1)`，这样更灵活，但也可能导致更高的冲突率。
4. **哈希码冲突与顺序**：
尽管哈希码冲突时，相同的key在理论上应该在HashMap中占据相同的位置，但实际存储顺序可能受负载因子、初始容量和阈值设置影响。由于Android和Java的默认设置不同，相同的键值对在两者中存储顺序可能不一致，导致哈希算法的结果产生差异。
5. **建议与教训**：
- 当涉及到顺序敏感的操作，比如加密算法的输入序列时，避免使用HashMap，因为它不保证插入顺序。考虑使用LinkedHashMap，它保留插入顺序。
- 对于跨平台的数据交换，确保理解并考虑到不同实现的差异，避免依赖于特定实现的行为。
- 对于一致性要求高的场景，使用固定顺序的结构，或者在编码时统一哈希算法和容器实现。
总结，HashMap在Android和Java中的实现差异主要体现在默认构造函数和阈值计算上，这些差异可能导致在特定场景下行为不一致。在使用HashMap时，应谨慎对待顺序问题，并了解所使用的环境和实现。
