字符串作为hashmap中的键 [英] String as key in hashmap

问题描述

我在过去一小时内阅读了很多帖子，但我仍然不太清楚使用不可变对象作为Hashmap中的键的概念。我有一个将其键作为String的hashmap。 hashmap中的值是MyStore，其中MyStore表示有关我拥有的商店的信息。 String表示地址。在我的代码中，我的逻辑是，我首先在地图中查找该键，如果存在 - >获取其值，如果它不存在则将其放入hashmap中。我的经理告诉我，密钥将来会改变，那就是我的商店的地址将来会改变。他说在那种情况下，我首先检查密钥是否存在的逻辑不起作用。我不明白他的意思。我想非常清楚地理解以下几点 -

I have read a lot of posts in the past one hour, but I am still not very clear with the concept of using immutable objects as keys in a Hashmap. I have a hashmap that has its key as a String. The value in the hashmap is MyStore, where MyStore represents information regarding stores I own. The String represents address. In my code, the logic I have is, I first look in the map for that key, if present --> get its value, if its not present put it in hashmap. My manager just told me the key will change in the future, that is address of my stores will change in the future. He said in that case, my logic of first checking if the key exists won't work. I don't understand what he means here. I want to understand the below points very clearly -

1. hashmap的可变和不可变键之间的区别。


2. 如果使用可更改的不可变密钥会发生什么？ - 我知道这没有意义，但我想清楚地了解我的经理在这里谈论的内容。


3. 如果在一个hashmap缓存中使用它们的哈希码，有些帖子会讨论字符串 - 这是什么意思？


4. 如果让我说我在我的hashmap中使用可变对象作为实现hashcode和equals的键，那么它会起作用吗？我假设它会，因为如果密钥更改，contains方法将查看密钥是否存在。如果它不存在，它将输入条目，以便您将来获取。

1. Difference between mutable and immutable keys for a hashmap.
2. What happens if you use a immutable key that can change? - I know this doesn't make sense, but I want to clearly understand what my manager is talking about here.
3. Some posts talk about Strings if used as keys in a hashmap cache their hashcode -What does this mean?
4. If lets say I used mutable objects as keys in my hashmap that implemented hashcode and equals, then will it work? I am assuming it will because if the key changes, the contains method will look if the key is present. If it is not present, it will put the entry so you can get it in the future.

如果之前已经讨论过，我不是要创建一个重复的帖子。如果我错过了阅读有关我所有问题答案的帖子，请指出。如果没有，请以外行的方式解释我的上述问题，以便将来对其他读者有用:)。随意编辑我的帖子的主题，以便将来如果有人有类似的问题，他们会直接降落在这里：）

I don't mean to create a duplicate post if this has been discussed before. If I missed reading the post that has answers to all my questions, please point me to it. If not, please explain in layman terms the above questions I have so it is useful in the future for other readers :). Feel free to edit my post's subject so in future if anyone has a similar question, they land here directly :)

推荐答案

首先： HashMap是如何工作的？

First : how does a HashMap work?

基本上它有一个数组，当你把一个键值对放在地图中时，它存储在数组中的一个位置。数组中的位置是根据传递给散列方法的键的 hashCode（）的结果来选择的。这是为什么？好吧，如果您请求某个键的值，则可以简单地重新计算数组中用于查找键及其关联值的索引，以便再次在数组中查找索引。 （需要更多的逻辑来处理映射到同一索引的键，但我只是想让你理解基本机制）然后 equals（）是用于验证计算索引处的密钥是否确实是所请求的密钥。

Basically it has an array and when you put a key-value pair in the map, it is stored in one of the positions in the array. The position in the array is chosen based on the result of the key's hashCode() passed to a hashing method. Why is that? Well, if you request the value for a certain key, the index in the array to find the key and its associated value can simply be recalculated to find the index in the array again. (Some more logic is needed to deal with keys that map to the same index, but I'm just trying to get you to understand the basic mechanism) Then equals() is used to verify if the key at the calculated index is indeed the requested key.

1. 从此它应该更清楚一点为什么不可变键比可变键更好。不可变键将始终保持相同的 hashCode（）值，并且哈希函数将再次找到正确的桶（= hashMap的数组中的索引）。

1. From this it should be a bit more clear why immutable keys are better than mutable keys. An immutable key will always keep the same hashCode() value, and the hashing function will find the correct bucket ( = index in the hashMap's array) again.

这并不意味着可变密钥无法正常工作。如果密钥上的突变不影响哈希代码，或者只要使用hashMap就不会改变密钥，则可变密钥将起作用。

That doesn't mean mutable keys cannot work. A mutable key will work if mutations on the key do not affect the hash code or if the keys are simply not mutated as long as the hashMap is used.

一个不可变的密钥如何改变？好吧，密钥本身可能无法更改，但键值映射可能会在业务逻辑中发生变化。如果您使用地址作为键创建地图，则依赖于商店地址不会更改的事实。如果商店的地址发生变化，您将无法使用新地址作为密钥在地图中找到它。您的经理有一个有效点。

How can an immutable key change? Well, the key itself may not be able to change, but the key-value mapping can change in business logic. If you create a map, using the address as a key, you rely on the fact that a store's address will not change. If a store's address changes, you'll not find it in the Map using its new address as a key. Your manager has a valid point.

在Map中查找密钥的速度很大程度上取决于计算hashCode的速度。对于String，此计算将循环遍历String中的所有字符。如果你使用长字符串作为键并且有很多Map访问权限，这可能会导致性能瓶颈。因此，Java的String实现会缓存哈希值，因此它只会被计算一次。但是，如果再次使用相同的 String 实例（新实例将不具有缓存值），则只会避免计算哈希代码。您可以 intern（）您使用的密钥，但只有在可以显示确实存在性能瓶颈时才考虑这一点，因为 String 实习确实带来了自己的开销。

the speed of finding a key in a Map highly depends on the speed of calculating the hashCode. For a String this calculation loops over all the characters in the String. If you use long Strings as keys and have a lot of Map access this may lead to a performance bottle neck. Java's String implementation therefore caches the hash value, so it will be calculated only once. However you'll only avoid calculating the hash code if you use the same String instance again (new instances will not have the cached value). You may intern() the keys you use, but consider this only if it can be shown that there really is a performance bottle neck, as String interning does come with its own overhead.

如1中所述：如果哈希码不受突变影响，可变密钥可以正常工作。例如使用Customer作为键，其中 hashCode（）仅基于客户的名称，然后是仅允许更改名称但仍允许其他值的Customer实现改变，是一个可靠的关键。

as explained in 1 : mutable keys can work if their hash code is not affected by mutations. e.g. using a Customer as key, where the hashCode() is based only on the customer's name, then a Customer implementation that only does not allow the name to change, yet allows other values to change, is a reliable key.

这篇关于字符串作为hashmap中的键的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！