不阻塞的有界BlockingQueue

Question

这个问题的题目使我怀疑这个问题是否存在，但仍然：

我感兴趣的是，是否有一个由大小限制的BlockingQueue实现，而不是块，而是在尝试对太多元素进行队列时抛出异常。

编辑--我将BlockingQueue传递给一个执行器，我认为它使用的是add()方法，而不是BlockingQueue()。可以编写一个BlockingQueue，它包装另一个BlockingQueue并委托调用add()来提供()。

Answer 1

编辑:基于你的新描述，，我相信你问错了问题。如果您使用的是执行器，您可能应该定义一个自定义的RejectedExecutionHandler，而不是修改队列。这只在使用ThreadPoolExecutor时才有效，但如果不使用，则修改执行器而不是队列可能是一个更好的主意。

这是我的意见，这是一个错误的超越提供，并使它的行为像添加。接口方法构成契约。使用阻塞队列的客户端代码取决于实际执行文档指定的方法。打破这一规则会给世界带来伤害。那是不雅致的。

加()方法在BlockingQueues上是这样做的，但是他们也有一个要约()方法，这通常是一个更好的选择。从报盘()的文件：

如果可以在不超过队列容量的情况下立即这样做，则在此队列的尾部插入指定的元素，成功时返回true，如果该队列已满，则返回false。此方法通常比方法add(E)更可取，后者只能通过抛出异常才能插入元素。

这适用于所有这类队列，而不管具体实现(ArrayBlockingQueue、LinkedBlockingQueue等)。

BlockingQueue<String> q = new LinkedBlockingQueue<String>(2);
System.out.println(q.offer("foo")); // true
System.out.println(q.offer("bar")); // true
System.out.println(q.offer("baz")); // false

Answer 2

可以编写一个BlockingQueue，它包装另一个BlockingQueue并委托调用add()来提供()。

如果这应该是个问题..。答案是“是”，但是您可以通过创建一个覆盖add()的子类来更整洁地完成这一任务。唯一的问题(在这两种情况下)是，您的add版本不能抛出正在重写的方法中没有的任何检查异常，因此您的“will块”异常将需要不受检查。

Answer 3

这是可悲的，你不能阻止，有那么多的用例，你会想要阻止，整个想法提供你自己有限制的阻塞队列给执行者没有任何意义。

public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) {
            if (runState == RUNNING && workQueue.***offer***(command)) {
                if (runState != RUNNING || poolSize == 0)
                    ensureQueuedTaskHandled(command);
            }
            else if (!addIfUnderMaximumPoolSize(command))
                reject(command); // is shutdown or saturated
        }
    }