为什么 iterator.hasNext 不能与 BlockingQueue 一起使用？

Question

我试图在 BlockingQueue 上使用迭代器方法，发现 hasNext() 是非阻塞的 - 即它不会等到添加更多元素，而是在没有元素时返回 false。

以下是问题：

1. 这是糟糕的设计，还是错误的 期待？
2. 有没有办法使用阻塞 BLockingQueue 的方法与 其父 Collection 类方法 （例如，如果期望某种方法 一个集合，我可以通过一个阻塞 排队并希望其处理 将等到队列有更多 元素）

这是一个示例代码块

public class SomeContainer{
     public static void main(String[] args){
        BlockingQueue bq = new LinkedBlockingQueue();
        SomeContainer h = new SomeContainer();
        Producer p = new Producer(bq);
        Consumer c = new Consumer(bq);
        p.produce();
        c.consume();
    }

    static class Producer{
        BlockingQueue q;
        public Producer(BlockingQueue q) {
            this.q = q;
        }

        void produce(){
        new Thread(){
            public void run() {
            for(int i=0; i<10; i++){
                for(int j=0;j<10; j++){
                    q.add(i+" - "+j);
                }
                try {
                    Thread.sleep(30000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            };
        }.start();
        }
    }


    static class Consumer{
         BlockingQueue q;

         public Consumer(BlockingQueue q) {
             this.q = q;
         }

        void consume() {
            new Thread() {
                public void run() {
                    Iterator itr = q.iterator();
                    while (itr.hasNext())
                        System.out.println(itr.next());
                }
            }.start();
        }
        }
    }

此代码最多只打印一次迭代。

Answer 1

1) 这是糟糕的设计，还是错误的预期？

错误的期望，否则会违反Iterator 的合同，Iterator.next() 上写着：Throws: NoSuchElementException - iteration has no more elements. 如果next() 会阻塞，则永远不会抛出异常。

2) 有没有办法使用阻塞方法

是的，例如通过扩展类并覆盖next 和hasNext 方法来使用阻塞例程。请注意，在这种情况下，hasNext 需要始终返回 true - 这再次违反了合同。

Answer 2

LinkedBlockingQueue 的迭代器将其作为 hasNext 实现：

  private Node<E> current;

   public boolean hasNext() {
        return current != null;
    }

所以这只会在每次调用时起作用。如果要等待元素并使用标准的 java Iterator 习惯用法，可以将方法包装在 while(true) 循环中：

    while (true) {     
       if(itr.hasNext()) {
          System.out.println(itr.next());
        }
    }

Answer 3

只是不要将迭代器与队列一起使用。如果是BlockingQueue，请改用peek() 或poll() 或take()：

void consume() {
    new Thread() {
        @Override
        public void run() {
            Object value;
            // actually, when using a BlockingQueue,
            // take() would be better than poll()
            while ((value=q.poll())!=null)
                System.out.println(value);
        }
    }.start();
}

Queue 是一个 Iterable，因为它是一个 Collection，因此需要提供一个 iterator() 方法，但不应该使用它，或者你不应该在第一名。

Answer 4

如果一个迭代器在hasNext 上阻塞，那么除非你明确地打破它，否则迭代将永远不会完成，这将是一个非常奇怪的设计。

无论如何LinkedBlockingQueue javadoc 有这个说法

Returns an iterator over the elements in this queue in proper sequence. 
The returned <tt>Iterator</tt> is a "weakly consistent" iterator that will 
never throw {@link ConcurrentModificationException}, and guarantees to 
traverse elements as they existed upon construction of the iterator, and 
may (but is not guaranteed to) reflect any modifications subsequent to 
construction.

Answer 5

我认为在某些情况下，有一个 Iterable 会阻止 iterator() 可能是合理的，尽管有一个单独的 BlockingIterator 会很愚蠢。这样做的原因是，以免您使用增强的for 循环，在某些情况下，它可以使您的代码更干净。 （如果在您的特定情况下无法做到这一点，请不要这样做。）

for(Request request:requests) process(request);

然而，迭代器仍然没有终止条件！一旦队列对新项目关闭，迭代器应该终止，并且元素用完。

但问题仍然存在，如果循环已经阻塞在迭代器的 next() 方法上，如果队列关闭，退出的唯一方法是抛出异常，周围的代码需要正确处理, 如果您选择这样做，请确保非常清楚准确地解释您的实现如何在 javadoc cmets 中工作。