blocks|key|182519|text|您是否在插入后修改了集合？如果是这样的话，很可能集合被排序到了与它正在查找的存储桶不同的存储桶中。在迭代时，它确实会找到您的集合，因为它会在整个map中查找。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|182520|我相信HashMap的合同规定不允许修改用作键的对象的哈希码，|182521|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Did you modify the set after insertion? If so, it's possible the set got sorted into a different bucket than the one it's looking in. When iterating, it does find your set, because it looks in the whole map.

I believe the contract for HashMap states you're not allowed to modify the hashcode for objects used as a key,

blocks|key|928282|text|在比较关键字时，您是否传递了确切的集合(您想要查找的集合)？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|928283|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Are you passing the exact set (the set you want to find) when comparing for the key?

blocks|key|930922|text|你应该努力使用不可变的类型作为Map的键。集合和集合通常是非常容易改变的，所以使用这种方式通常不是一个好主意。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|930923|如果希望使用许多键值作为Map键，则应该使用为此目的而设计的类实现，如Apache+Commons+Collections+MultiKey。|930924|如果您确实必须使用Set或Collection作为键，请首先将其设置为不可变(Collections.unmodifiableSet(...))，然后不要保留对可变支持对象的引用。|930925|使用集合作为键的另一个困难是它们可能以不同的顺序构造。只有排序后的集合才有很高的匹配概率。例如，如果您使用顺序排序的ArrayList，但第二次以不同的方式构造列表，它将不会与键匹配-散列码和值的顺序是不同的。|930926|编辑：我纠正了下面这句话，我从来没有用过Set+for+ket。我刚刚用AbstractHashSet阅读了hashCode实现的一部分。它使用所有值的简单总和，因此不依赖于顺序。Equals还检查一个集合是否包含另一个集合中的所有值。然而，这仍然适用于Java语言中的其他类型的集合(ArrayList顺序确实很重要)。|BOLD|930927|如果您的集合实际上是一个HashSet，那么创建顺序也很重要。事实上，任何类型的散列管理的集合都会有更大的问题，因为任何容量的改变都会触发整个集合的重新构建，这可能会重新排序元素。考虑按冲突发生的顺序存储的散列的冲突(转换后的散列值相同的所有元素的简单链接链)。|930928|entityMap|0|LINK|mutability|MUTABLE|url|http://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/keyvalue/MultiKey.html^0|F|3|0|C|3|1Q|8|1Q|8|0|0|13|W|0|1M|9|0|0|2|0|C|7|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@$9|16|A|17|1|18]]|E|$]]|$1|H|3|I|5|6|7|19|8|@$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1C|8|@$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1F|8|@$9|1G|A|1H|B|N]]|D|@]|E|$]]|$1|O|3|P|5|6|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|1L|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

You should strive to use immutable types as keys for <code>Map</code>s. Collections and sets are generally very easily mutable so usually are a bad idea to use this way.

If you want to use many key values as a <code>Map</code> key you should use a class implementation designed for that purpose, like Apache Commons Collections <a href="http://commons.apache.org/proper/commons-collections/javadocs/api-release/org/apache/commons/collections4/keyvalue/MultiKey.html" rel="nofollow noreferrer"><code>MultiKey</code></a>.

If you really must use a Set or Collection as a key, first make it immutable (<code>Collections.unmodifiableSet(...)</code>) and then do not keep a reference to the mutable backing object.

Another difficulty with using Collections as keys is that they could be constructed in a different order. Only a sorted collection will have a high likely-hood of matching. For instance, if you use a sequentially ordered <code>ArrayList</code> but construct the list in a different way the second time it will not match the key - the hash code and order of values is different.

EDIT: I stand corrected on this statement below, never having had to use Set for a ket. I just read a portion of the hashCode implementation in AbstractHashSet. This uses a simple total of all values so is not dependent of the order. Equals also checks that one set contains all values in the other set. However, this still is true with other kinds of Collections in the Java (ArrayList order does matter).

If your collection is actually a <code>HashSet</code>, the creation order can matter as well. In fact a hash managed collection of any kind will be even more problematic as any capacity changes trigger a rebuild of the entire collection which can reorder the elements. Think of collisions of hashes which are stored in the order the collision occur (a simple linked chain of all elements where the transformed hash value is the same).

blocks|key|1327333|text|在映射中使用时，键不应发生变化。Map+java文档中写道：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1327334|1327335|注意:如果将可变对象用作映射键，则必须非常小心。当对象是映射中的键时，如果对象的值以影响等于比较的方式更改，则不指定映射的行为。此禁令的一个特例是，不允许映射将其自身包含为关键字。虽然允许映射将其自身包含为值，但建议您格外小心:+equals和hashCode方法在这样的映射上不再定义良好。|blockquote|1327336|1327337|1327338|我知道这个问题，但直到现在才进行测试。然后我再详细阐述一下：|1327339|+++Map<Set<String>,+Object>+map++=+new+HashMap<Set<String>,+Object>();

+++Set<String>+key1+=+new+HashSet<String>();
+++key1.add(+"hello");

+++Set<String>+key2+=+new+HashSet<String>();
+++key2.add(+"hello2");

+++Set<String>+key2clone+=+new+HashSet<String>();
+++key2clone.add(+"hello2");

+++map.put(+key1,+new+Object()+);
+++map.put(+key2,+new+Object()+);

+++System.out.println(+map.containsKey(key1));+//+true
+++System.out.println(+map.containsKey(key2));+//+true
+++System.out.println(+map.containsKey(key2clone));+//+true

+++key2.add(+"mutate"+);

+++System.out.println(+map.containsKey(key1));+//+true
+++System.out.println(+map.containsKey(key2));+//+false
+++System.out.println(+map.containsKey(key2clone));+//+false+(*)

+++key2.remove(+"mutate"+);

+++System.out.println(+map.containsKey(key1));+//+true
+++System.out.println(+map.containsKey(key2));+//+true
+++System.out.println(+map.containsKey(key2clone));+//+true|code-block|syntax|javascript|1327340|在key2发生突变后，地图将不再包含它。我们可以认为地图在添加数据时对数据进行了“索引”，然后我们可以预期它仍然包含key2克隆(用*标记的行)。但有趣的是，事实并非如此。|1327341|因此，正如java文档所说，键不应该改变，否则行为将是未指定的。句号。|1327342|我想这就是你的情况。|1327343|entityMap^0|G|3|0|0|0|0|0|0|0|1|4|1U|1|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|13|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|14|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|15|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|16|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|17|8|@]|D|@]|E|$]]|$1|N|3|O|5|P|7|18|8|@]|D|@]|E|$Q|R]]|$1|S|3|T|5|6|7|19|8|@$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|1E|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|1F|8|@]|D|@]|E|$]]|$1|Y|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]]|Z|$]]

Key should not be mutated while used in the map. The <code>Map</code> java doc says:

<blockquote>
 Note: great care must be exercised if
 mutable objects are used as map keys.
 The behavior of a map is not specified
 if the value of an object is changed
 in a manner that affects equals
 comparisons while the object is a key
 in the map. A special case of this
 prohibition is that it is not
 permissible for a map to contain
 itself as a key. While it is
 permissible for a map to contain
 itself as a value, extreme caution is
 advised: the equals and hashCode
 methods are no longer well defined on
 a such a map.
</blockquote>

I knew this issue, but never made the test until now. I elaborate then a bit more:

<pre><code> Map&lt;Set&lt;String&gt;, Object&gt; map = new HashMap&lt;Set&lt;String&gt;, Object&gt;();

 Set&lt;String&gt; key1 = new HashSet&lt;String&gt;();
 key1.add( "hello");

 Set&lt;String&gt; key2 = new HashSet&lt;String&gt;();
 key2.add( "hello2");

 Set&lt;String&gt; key2clone = new HashSet&lt;String&gt;();
 key2clone.add( "hello2");

 map.put( key1, new Object() );
 map.put( key2, new Object() );

 System.out.println( map.containsKey(key1)); // true
 System.out.println( map.containsKey(key2)); // true
 System.out.println( map.containsKey(key2clone)); // true

 key2.add( "mutate" );

 System.out.println( map.containsKey(key1)); // true
 System.out.println( map.containsKey(key2)); // false
 System.out.println( map.containsKey(key2clone)); // false (*)

 key2.remove( "mutate" );

 System.out.println( map.containsKey(key1)); // true
 System.out.println( map.containsKey(key2)); // true
 System.out.println( map.containsKey(key2clone)); // true
</code></pre>

After <code>key2</code> is mutated, the map does not contain it anymore. We could think that the map "indexes" the data when it's added and we would then expect that it still contains the key2 clone (line marked with <code>*</code>). But funny enough, this is not the case. 

So, as the java doc says, keys should not be mutated otherwise the behavior is unspecified. Period.

I guess that's what happens in your case.

I have a Map that uses a Set for the key type, like this:

<pre><code>Map&lt;Set&lt;Thing&gt;, Val&gt; map;
</code></pre>

When I query map.containsKey(myBunchOfThings), it returns false, and I don't understand why. I can iterate through each key in the keyset and verify there is a key that (1) has the same hashCode, and (2) is equals() to myBunchOfThings.

<pre><code>System.out.println(map.containsKey(myBunchOfThings)); // false.
for (Set&lt;Thing&gt; k : map.keySet()) {
 if (k.hashCode() == myBunchOfThings.hashCode() &amp;&amp; k.equals(myBunchOfThings) {
 System.out.println("Fail at life."); // it prints this.
 }
}
</code></pre>

Do I just fundamentally misunderstand the contract for containsKey? Is there a secret to using sets (or more generally, collections) as keys to maps?

How to use Sets as keys in Java Maps

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个Map，它使用Set作为key类型，如下所示：Map<Set<Thing>, Val> map;当我查询map.containsKey(myBunchOfThings)时，它返回false，我不知道为什么。我可以遍历密钥集中的每个密钥，并验证是否有一个密钥(1)具有相同的hashCode，并且(2)等于() m...

问如何在Java Maps中使用集合作为键
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在Java Maps中使用集合作为键EN