(已链接)BlockingQueue.put(Null)抛出NullPointerException

Question

我已经检查了它的实现，它是故意这样做的

 public void put(E e) throws InterruptedException {
     if (e == null) throw new NullPointerException();

这种惊喜对于用户(例如，他们想以这种方式发出结束流的信号)并不方便，并且打破了集合的常规约定，因为集合很容易接受null元素。BlockingQueue区别空元素的意义是什么？如果空值如此糟糕，我们是否应该完全避免使用它们，并在JLS中强制执行此低值？

Answer 1

接受nulls不是Collection合同的一部分。事实上，Collection Javadoc特别声明：

某些集合实现对它们可能包含的元素有限制。例如，一些实现禁止null元素，而另一些则对其元素的类型有限制。尝试添加不合格的元素会抛出未检查的异常，通常是NullPointerException或ClassCastException。

在许多情况下，将null添加到集合中意味着程序中的某个地方存在错误，而不是您故意将其放入。例如，Guava库(我对其有贡献) makes the explicit decision拒绝来自其许多集合实现的空值，特别是不可变的实现：

我们对谷歌的内部代码库做了一个详尽的研究，表明集合中允许null元素的概率约为5%，其他95%的情况下最好的方法是在null上快速失败。

通常有接受空值的变通方法，但许多集合实现决定拒绝空值(大多数用户发现这很有帮助，因为它有助于他们找到bug)，并为显式空值合适的极少数情况提供变通方法。

老实说，我认为LinkedBlockingQueue属于这一类的原因是，在开发原始集合框架时，所有这些都还没有弄清楚，但在添加并发集合时，这一点已经很清楚了。Doug Lea在util.concurrent上做了大量工作，他说，

Null糟糕透了。

在最坏的情况下，对象包装器或“有毒对象”总是有效的变通方法；Guava提供了一个Optional类，它可以在许多情况下充当这个角色，here在StackOverflow上对此进行了广泛的讨论。