gpt4 book ai didi

java - 通过 Collections.synchronizedSet(...).forEach() 进行的迭代是否保证是线程安全的?

转载 作者:IT老高 更新时间:2023-10-28 21:16:11 28 4
gpt4 key购买 nike

我们知道,默认情况下迭代并发集合不是线程安全的,所以不能使用:

Set<E> set = Collections.synchronizedSet(new HashSet<>());
//fill with data
for (E e : set) {
process(e);
}

这是因为在迭代过程中可能会添加数据,因为 set 上没有排他锁。

这在 javadoc 中有描述Collections.synchronizedSet:

public static Set synchronizedSet(Set s)

Returns a synchronized (thread-safe) set backed by the specified set. In order to guarantee serial access, it is critical that all access to the backing set is accomplished through the returned set.

It is imperative that the user manually synchronize on the returned set when iterating over it:

Set s = Collections.synchronizedSet(new HashSet());
...
synchronized (s) {
Iterator i = s.iterator(); // Must be in the synchronized block
while (i.hasNext())
foo(i.next());
}

Failure to follow this advice may result in non-deterministic behavior.

然而,这不适用于Set.forEach,它从Iterable.forEach 继承了默认方法forEach .

现在我查看了源代码,在这里我们可以看到我们有以下结构:

  1. 我们要求 Collections.synchronizedSet()
  2. 我们得到一个:

    public static <T> Set<T> synchronizedSet(Set<T> s) {
    return new SynchronizedSet<>(s);
    }

    ...

    static class SynchronizedSet<E>
    extends SynchronizedCollection<E>
    implements Set<E> {
    private static final long serialVersionUID = 487447009682186044L;

    SynchronizedSet(Set<E> s) {
    super(s);
    }
    SynchronizedSet(Set<E> s, Object mutex) {
    super(s, mutex);
    }

    public boolean equals(Object o) {
    if (this == o)
    return true;
    synchronized (mutex) {return c.equals(o);}
    }
    public int hashCode() {
    synchronized (mutex) {return c.hashCode();}
    }
    }
  3. 它扩展了 SynchronizedCollection,除了显而易见的方法之外,还有以下 有趣的 方法:

    // Override default methods in Collection
    @Override
    public void forEach(Consumer<? super E> consumer) {
    synchronized (mutex) {c.forEach(consumer);}
    }
    @Override
    public boolean removeIf(Predicate<? super E> filter) {
    synchronized (mutex) {return c.removeIf(filter);}
    }
    @Override
    public Spliterator<E> spliterator() {
    return c.spliterator(); // Must be manually synched by user!
    }
    @Override
    public Stream<E> stream() {
    return c.stream(); // Must be manually synched by user!
    }
    @Override
    public Stream<E> parallelStream() {
    return c.parallelStream(); // Must be manually synched by user!
    }

这里使用的 mutexCollections.synchronizedSetall 操作锁定到的对象相同。

现在我们可以,根据实现判断,使用 Collections.synchronizedSet(...).forEach(...) 是线程安全的,但是它也是线程安全的规范吗?

(令人困惑的是,Collections.synchronizedSet(...).stream().forEach(...) 在实现上是 not 线程安全的,并且结论规范似乎也是未知的。)

最佳答案

正如你所写,从实现来看,forEach() 对于 JDK 提供的集合(参见下面的免责声明)是线程安全的,因为它需要获取互斥锁的监视器才能继续。

Is it also thread safe by specification?

我的意见 - 不,这里有一个解释。 Collections.synchronizedXXX()用简短的语言重写的 javadoc 说 - “所有方法都是线程安全的,除了那些用于迭代它的方法”。

我的另一个,虽然非常主观的论点是 yshavit 写的 - 除非被告知/阅读,否则请考虑 API/类/任何不是线程安全的。

现在,让我们仔细看看 javadocs。我想我可以说明该方法forEach()用于对其进行迭代,因此,按照 javadoc 的建议,我们应该认为它不是线程安全的,尽管它与现实相反(实现)。

无论如何,我同意 yshavit 的声明,即应该更新文档,因为这很可能是文档,而不是实现缺陷。但是,除了 JDK 开发人员之外,没有人可以肯定地说,请参阅下面的问题。

我想在本次讨论中提到的最后一点——我们可以假设自定义集合可以用 Collections.synchronizedXXX() 包装。 ,以及 forEach() 的实现这个集合可以是……可以是任何东西。该集合可能对 forEach() 中的元素执行异步处理。方法,为每个元素生成一个线程......它仅受作者想象的限制,同步(互斥)包装不能保证这种情况下的线程安全。该特定问题可能是不声明 forEach() 的原因。作为线程安全的方法..

关于java - 通过 Collections.synchronizedSet(...).forEach() 进行的迭代是否保证是线程安全的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23450227/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com