如何修复HashMap更新每个现有值而不是单个值

我一直在研究醉酒的沃克编码问题（自定义用户类等），而要解决这个小问题我会发疯。

我弄乱了代码（无济于事），因此在看不到希望的情况下，我决定征询外界的意见。

我用于添加到哈希图中的代码如下：

if (hashMap.containsKey(key) == false) {
    hashMap.put(key, 1);
}
else {
    hashMap.put(key, value + 1);
}

从理论上讲，这应该是完全可以的。如果键未保存在地图中，则将其值添加到地图中。值为1。如果键实际上在地图中，则该值将增加1。键只是一个带有两个整数变量的自定义类的实例。它正在不断更新。

在程序的最后，如果我在哈希图中显示的值大于1，则应如下所示：

Visited Intersection [avenue=8, street=42] 3 times!
Visited Intersection [avenue=8, street=63] 2 times!

但是，当我观察每个函数调用的哈希图时，它看起来像这样：

Hash Map: {Intersection [avenue=6, street=22]=1}

Hash Map: {Intersection [avenue=6, street=23]=1, Intersection 
[avenue=6, street=23]=1}

Hash Map: {Intersection [avenue=6, street=22]=2, Intersection 
[avenue=6, street=22]=1}

Hash Map: {Intersection [avenue=5, street=22]=2, Intersection 
[avenue=5, street=22]=1, Intersection [avenue=5, street=22]=1}

Hash Map: {Intersection [avenue=6, street=22]=3, Intersection 
[avenue=6, street=22]=1, Intersection [avenue=6, street=22]=1}

...

哈希图中的每个条目都被覆盖，最终产品是这样的：

Visited Intersection [avenue=8, street=20] 3 times!
Visited Intersection [avenue=8, street=20] 2 times!
Visited Intersection [avenue=8, street=20] 2 times!
Visited Intersection [avenue=8, street=20] 2 times!
...

最初，我认为添加到哈希图中的代码是不正确的，因为每个键都被覆盖，并且仅显示最后更新的键，但是现在我认为这与键的实际更新有关。

竹enny你的想法？抱歉，如果有点含糊。

哈希图中的每个条目都被覆盖...

我怀疑您不太了解其HashMap工作原理。 HashMap存储对非副本的引用key。我怀疑您Intersection将其放入地图后将覆盖这些字段。这是一个非常糟糕的模式，可能会导致一些非常奇怪的结果。

几件事要检查。

您应该new Intersection(avenue, street)每次都做。

考虑在您的Intersectionbe中设置2个字段final。这始终是一个好的模式，因此您不会无意间更改键的值。确保一个或两个字段均为“ identity”字段，则应为final。

您需要确保该Intersection对象有适当hashcode()和equals()正确标识每个值的方法。否则，每个Intersection将被存储在地图上，不管它们有相同的avenue和street值。在这里查看我的答案：https : //stackoverflow.com/a/9739583/179850

您应该从地图上获取相交的数量，然后增加值。

也许像：

Intersection key = new Intersection(8, 42);
...
Integer count = hashMap.get(key);
if (count == null) {
   hashMap.put(key, 1);
} else {
   hashMap.put(key, value + 1);
}
...
public class Intersection {
   // these fields can't be changed
   private final int avenue;
   private final int street;
   ...