为什么两个原子整数永远不相等？

发布于 2024-12-06 20:33:37 字数 261 浏览 0 评论 0原文

我偶然发现了 AtomicInteger 的源代码，并意识到其

new AtomicInteger(0).equals(new AtomicInteger(0))

计算结果为 false。

这是为什么呢？这是与并发问题相关的某种“防御性”设计选择吗？如果是这样，如果以不同的方式实施会出现什么问题？

（我确实意识到我可以使用 get 和 == 来代替。）

原文

I stumbled across the source of AtomicInteger and realized that

new AtomicInteger(0).equals(new AtomicInteger(0))

evaluates to false.

Why is this? Is it some "defensive" design choice related to concurrency issues? If so, what could go wrong if it was implemented differently?

(I do realize I could use get and == instead.)

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

孤星 2024-12-13 20:33:37

部分原因是 AtomicInteger 不是 Integer 的通用替代品。

java.util.concurrent.atomic 包摘要指出：

原子类不是通用目的的替代品
java.lang.Integer 及相关类。他们没有定义方法
例如 hashCode 和 compareTo。（因为原子变量是
预计会发生变异，因此它们对于哈希表键来说是糟糕的选择。）

hashCode 未实现，equals 的情况也是如此。这部分是由于中讨论的一个更大的理由。邮件列表存档，关于 AtomicInteger 是否应该扩展 Number 。

AtomicXXX 类不是原语的直接替代品，并且它没有实现 Comparable 接口的原因之一是，比较 AtomicXXX 类的两个实例是没有意义的。大多数场景。如果两个线程可以访问并改变 AtomicInteger 的值，则如果线程改变 AtomicInteger 的值，则在使用结果之前比较结果无效。同样的原理也适用于 equals 方法 - 相等测试的结果（取决于 AtomicInteger 的值）仅在线程改变其中之一之前才有效。有问题的AtomicInteger。

回复收藏 0 原文

长梦不多时 2024-12-13 20:33:37

从表面上看，这似乎是一个简单的遗漏，但实际上仅使用 Object.equals 提供的身份等于确实有意义，

例如：

AtomicInteger a = new AtomicInteger(0)
AtomicInteger b = new AtomicInteger(0)

assert a.equals(b)

看起来合理，但是 b 并不是真正的 a，它被设计为值的可变持有者，因此不能真正替换程序中的 a。

另外：

assert a.equals(b)
assert a.hashCode() == b.hashCode()

应该可以，但是如果 b 的值在两者之间发生变化怎么办？

如果这就是原因，那么遗憾的是它没有记录在 AtomicInteger 的源代码中。

顺便说一句：一个不错的功能可能是允许 AtomicInteger 等于 Integer。

AtomicInteger a = new AtomicInteger(25);

if( a.equals(25) ){
    // woot
}

麻烦的是，这意味着为了在这种情况下具有自反性，Integer 也必须在它的 equals 中接受 AtomicInteger 。

On the face of it, it seems like a simple omission but it maybe it does make some sense to actually just use the idenity equals provided by Object.equals

For instance:

AtomicInteger a = new AtomicInteger(0)
AtomicInteger b = new AtomicInteger(0)

assert a.equals(b)

seems reasonable, but b isn't really a, it is designed to be a mutable holder for a value and therefore can't really replace a in a program.

also:

assert a.equals(b)
assert a.hashCode() == b.hashCode()

should work but what if b's value changes in between.

If this is the reason it's a shame it wasn't documented in the source for AtomicInteger.

As an aside: A nice feature might also have been to allow AtomicInteger to be equal to an Integer.

AtomicInteger a = new AtomicInteger(25);

if( a.equals(25) ){
    // woot
}

trouble it would mean that in order to be reflexive in this case Integer would have to accept AtomicInteger in it's equals too.

回复收藏 0 原文

淡忘如思 2024-12-13 20:33:37

我认为，因为 AtomicInteger 的要点是操作可以原子地完成，所以很难确保两个值以原子方式进行比较，并且因为 AtomicIntegers 通常是计数器，所以你会出现一些奇怪的行为。

因此，如果不确保 equals 方法同步，您就无法确定在 equals 返回时原子整数的值没有更改。然而，由于原子整数的全部意义不是使用同步，所以你最终不会得到什么好处。

回复收藏 0 原文

音栖息无 2024-12-13 20:33:37

我怀疑比较这些值是不行的，因为没有办法以可移植的方式原子地完成它（即没有锁）。

如果没有原子性，那么即使变量从未同时包含相同的值，变量也可以比较相等（例如，如果 a 从 0 更改为 1 与 b 从 1 更改为 0 的同一时间）。

回复收藏 0 原文

冰雪之触 2024-12-13 20:33:37

AtomicInteger 继承自 Object 并不是 Integer，它使用标准引用相等性检查。

如果你用谷歌搜索，你会发现这个具体案例的讨论< /a>.

回复收藏 0 原文

一口甜 2024-12-13 20:33:37

想象一下，如果 equals 被覆盖，并将其放入 HashMap 中，然后更改值。不好的事情会发生:)

回复收藏 0 原文

有深☉意 2024-12-13 20:33:37

equals 不仅用于相等，而且还满足其与 hashCode 的约定，即在哈希集合中。哈希集合的唯一安全方法是可变对象不依赖于其内容。即对于可变键，HashMap 与使用 IdentityMap 相同。这样，当键内容改变时，hashCode 和两个对象是否相等不会改变。

所以 new StringBuilder().equals(new StringBuilder()) 也是 false。

要比较两个 AtomicInteger 的内容，需要 ai.get() == ai2.get() 或 ai.intValue() == ai2.intValue()

让假设您有一个可变键，其中 hashCode 和 equals 根据内容而变化。

static class BadKey {
    int num;
    @Override
    public int hashCode() {
        return num;
    }

    @Override
    public boolean equals(Object obj) {
        return obj instanceof BadKey && num == ((BadKey) obj).num;
    }

    @Override
    public String toString() {
        return "Bad Key "+num;
    }
}

public static void main(String... args) {
    Map<BadKey, Integer> map = new LinkedHashMap<BadKey, Integer>();
    for(int i=0;i<10;i++) {
        BadKey bk1 = new BadKey();
        bk1.num = i;
        map.put(bk1, i);
        bk1.num = 0;
    }
    System.out.println(map);
}

正如

{Bad Key 0=0, Bad Key 0=1, Bad Key 0=2, Bad Key 0=3, Bad Key 0=4, Bad Key 0=5, Bad Key 0=6, Bad Key 0=7, Bad Key 0=8, Bad Key 0=9}

你所看到的，我们现在有 10 个键，它们都相等并且具有相同的 hashCode！

equals is not only used for equality but also to meet its contract with hashCode, i.e. in hash collections. The only safe approach for hash collections is for mutable object not to be dependant on their contents. i.e. for mutable keys a HashMap is the same as using an IdentityMap. This way the hashCode and whether two objects are equal does not change when the keys content changes.

So new StringBuilder().equals(new StringBuilder()) is also false.

To compare the contents of two AtomicInteger, you need ai.get() == ai2.get() or ai.intValue() == ai2.intValue()

Lets say that you had a mutable key where the hashCode and equals changed based on the contents.

static class BadKey {
    int num;
    @Override
    public int hashCode() {
        return num;
    }

    @Override
    public boolean equals(Object obj) {
        return obj instanceof BadKey && num == ((BadKey) obj).num;
    }

    @Override
    public String toString() {
        return "Bad Key "+num;
    }
}

public static void main(String... args) {
    Map<BadKey, Integer> map = new LinkedHashMap<BadKey, Integer>();
    for(int i=0;i<10;i++) {
        BadKey bk1 = new BadKey();
        bk1.num = i;
        map.put(bk1, i);
        bk1.num = 0;
    }
    System.out.println(map);
}

prints

{Bad Key 0=0, Bad Key 0=1, Bad Key 0=2, Bad Key 0=3, Bad Key 0=4, Bad Key 0=5, Bad Key 0=6, Bad Key 0=7, Bad Key 0=8, Bad Key 0=9}

As you can see we now have 10 keys, all equal and with the same hashCode!

回复收藏 0 原文

独闯女儿国 2024-12-13 20:33:37

equals 已正确实现：AtomicInteger 实例只能等于其自身，因为随着时间的推移，只有同一个实例才能证明存储相同的值序列。

请记住，Atomic* 类充当引用类型（就像 java.lang.ref.*），旨在包装实际的“有用”值。与函数式语言中的情况不同（参见 Clojure 的 Atom 或 Haskell 的 IORef ），Java 中引用和值之间的区别相当模糊（归咎于可变性），但它仍然在那里。

将 Atomic 类的当前包装值视为相等的标准显然是一种误解，因为这意味着 new AtomicInteger(1).equals(1)。

回复收藏 0 原文

俯瞰星空 2024-12-13 20:33:37

Java 的一个限制是，无法区分可以且将会发生变异的可变类实例与永远不会暴露于可能发生变异的任何事物的可变类实例 (*)。对前一种类型的事物的引用只有在引用同一对象时才应被视为相等，而对后一种类型的事物的引用如果引用具有相同状态的对象，则通常应被视为相等。因为 Java 只允许对虚拟 equals(object) 方法进行一次重写，所以可变类的设计者必须猜测是否有足够的实例满足后一种模式（即以永远不会出现的方式保存）。被变异）来证明 equals() 和 hashCode() 以适合这种用法的方式运行。

对于像 Date 这样的情况，有很多类封装了对永远不会被修改的 Date 的引用，并希望拥有自己的等价关系并包含封装的 Date 的值等价性。因此，Date 重写 equals 和 hashCode 来测试值的等价性是有意义的。另一方面，持有对永远不会被修改的 AtomicInteger 的引用是愚蠢的，因为该类型的整个目的以可变性为中心。出于所有实际目的，永远不会改变的 AtomicInteger 实例可能只是一个 Integer。

(*) 只要 (1) 某处存在有关其身份哈希值的信息，或者 (2) 宇宙中某处存在对该对象的多个引用，任何特定实例永不变异的要求才具有约束力。如果这两个条件都不适用于 Foo 引用的实例，则将 Foo 替换为对 Foo 克隆的引用将不会产生明显的效果。因此，通过假装用克隆替换 Foo 并改变“克隆”，就可以在不违反“从不改变”的要求的情况下改变实例。