BlockingQueue 的rainTo() 方法的线程安全性

发布于 2024-11-18 21:01:19 字数 861 浏览 4 评论 0原文

BlockingQueue 的文档说批量操作不是线程安全的，尽管它没有明确提及该方法drainTo()。

BlockingQueue 实现是线程安全。所有排队方式使用原子方式实现其效果内部锁或其他形式的并发控制。然而，大部分集合操作addAll， containsAll、retainAll 和 removeAll 不一定执行除非另有说明，否则以原子方式在一个实现中。原来如此可能，例如，对于 addAll(c) 之后失败（抛出异常）仅添加 c 中的部分元素。

DrainTo() 方法的文档指定不能以线程安全的方式修改 BlockingQueue 元素排出到的集合。但是，它没有提到有关 danceTo() 操作是线程安全的任何内容。

删除所有可用元素这个队列并将它们添加到给定的收藏。这个操作可能会比较多比重复轮询更有效队列。期间遇到故障尝试添加元素到集合 c 可能会产生元素两者都不存在、其中之一或两者都存在当关联时集合抛出异常。尝试排水队列本身导致 IllegalArgumentException。此外，此操作的行为是如果指定集合则未定义操作进行时被修改进展。

那么，drainTo()方法是线程安全的吗？换句话说，如果一个线程在阻塞队列上调用了rainTo()方法，而另一个线程在同一队列上调用了add()或put()，那么在这两个操作结束时队列的状态是否一致？

原文

分享到QQ

分享到微博

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

发布评论

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

倥絔 2024-11-25 21:01:19

我认为您混淆了术语“线程安全”和“原子”。它们的意思不同。方法可以是线程安全的但不是原子的，也可以是原子的（对于单个线程）而不是线程安全的。

线程安全是一个橡皮术语，很难在不循环的情况下进行定义。根据 Goetz 的说法，一个好的工作模型是，如果一个方法在多线程上下文中使用时与在单线程上下文中运行时“一样正确”，那么该方法就是线程安全的。弹性在于，正确性是主观的，除非有正式的规范来衡量。

相比之下，原子很容易定义。它只是意味着该操作要么完全发生，要么根本不发生。

所以你的问题的答案是，drainTo()是线程安全的，但不是原子的。它不是原子的，因为它可能在耗尽过程中抛出异常。但是，以此为模，无论其他线程是否同时对队列执行操作，队列仍将处于一致状态。

（上面的讨论隐含地表明，BlockingQueue 接口的具体实现正确地实现了该接口。如果没有正确实现，则一切都失败了。）

回复收藏 0 原文

暮色兮凉城 2024-11-25 21:01:19

DrainTo() 是线程安全的，因为同时发生的队列上的任何操作都不会更改结果，也不会破坏队列的状态。否则，该方法将毫无意义。

如果目标集合（添加结果的集合）做了一些“聪明”的事情，您可能会遇到问题。但由于您通常将队列排空到只有单个线程可以访问的集合，因此这更多是一个理论上的问题。

回复收藏 0 原文

安静 2024-11-25 21:01:19

偶然发现这个问题，想添加一个实施信息。

来自 Java 8 source of PriorityBlockingQueue ：

 /**
     * @throws UnsupportedOperationException {@inheritDoc}
     * @throws ClassCastException            {@inheritDoc}
     * @throws NullPointerException          {@inheritDoc}
     * @throws IllegalArgumentException      {@inheritDoc}
     */
    public int drainTo(Collection<? super E> c, int maxElements) {
        if (c == null)
            throw new NullPointerException();
        if (c == this)
            throw new IllegalArgumentException();
        if (maxElements <= 0)
            return 0;
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            int n = Math.min(size, maxElements);
            for (int i = 0; i < n; i++) {
                c.add((E) queue[0]); // In this order, in case add() throws.
                dequeue();
            }
            return n;
        } finally {
            lock.unlock();
        }
    }

您可以看到一个 ReentrantLock 用于锁定关键部分。 poll() 和 offer() 方法也使用相同的锁。因此，在本例中 PriorityBlockingQueue 的 BlockingQueue 实现确实是阻塞！

stumbled upon this question and felt like adding an implementation info.

From Java 8 source of PriorityBlockingQueue :

 /**
     * @throws UnsupportedOperationException {@inheritDoc}
     * @throws ClassCastException            {@inheritDoc}
     * @throws NullPointerException          {@inheritDoc}
     * @throws IllegalArgumentException      {@inheritDoc}
     */
    public int drainTo(Collection<? super E> c, int maxElements) {
        if (c == null)
            throw new NullPointerException();
        if (c == this)
            throw new IllegalArgumentException();
        if (maxElements <= 0)
            return 0;
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            int n = Math.min(size, maxElements);
            for (int i = 0; i < n; i++) {
                c.add((E) queue[0]); // In this order, in case add() throws.
                dequeue();
            }
            return n;
        } finally {
            lock.unlock();
        }
    }

You can see that a ReentrantLock is used to lock the critical section. The methods poll() and offer() are also using the same lock. So the BlockingQueue implementation in this case of PriorityBlockingQueue is indeed Blocking!

回复收藏 0 原文

~没有更多了~