私は実装をチェックしました、それは意図的にそうします
public void put(E e) throws InterruptedException {
if (e == null) throw new NullPointerException();
この驚きは、ユーザー（たとえば、この方法でストリームの終了を通知したい）にとっては不便であり、null要素を簡単に受け入れるコレクションとの一般的な契約を破ります。null要素を区別するためのBlockingQueueのポイントは何ですか？nullが非常に悪い場合は、nullの使用をまったく控えて、JLSでこれを低くする必要がありますか？
nullを受け入れることは、契約の一部ではありません。Collection実際、Collection Javadocは具体的に次のように述べています。
一部のコレクションの実装には、含まれる可能性のある要素に制限があります。たとえば、一部の実装ではnull要素が禁止されており、一部の実装では要素のタイプに制限があります。不適格な要素を追加しようとすると、チェックされていない例外（通常はNullPointerExceptionまたはClassCastException）がスローされます。
多くの場合、nullコレクションに追加するということは、意図的にプログラムを追加するのではなく、プログラムのどこかにバグがあることを意味します。たとえば、Guavaライブラリ（私が寄稿している）は、コレクションの実装の多く、特に不変の実装からnullを拒否するという明示的な決定を下します。
Googleの内部コードベースについて徹底的な調査を行ったところ、コレクションでnull要素が許可される時間は約5％であり、他の95％のケースはnullで高速に失敗することが最も適切であることが示されました。
通常、nullを受け入れる回避策がありますが、多くのコレクション実装はnullを拒否する決定を下し（ほとんどのユーザーはバグを見つけるのに役立つため、役立つと思います）、明示的なnullが適切であるまれなケースの回避策を提供します。
正直なところ、このカテゴリに含まれる理由は、元のコレクションフレームワークが開発されたときにこれらすべてが理解されていなかったためだと思いますLinkedBlockingQueueが、同時コレクションが追加されるまでにはかなり明確でした。の作業の多くを行ったダグ・リーは、次のutil.concurrentように述べていると言われています。
ヌルは吸う。
最悪の場合、オブジェクトラッパーまたは「ポイズンオブジェクト」は常に有効な回避策です。Guavaは、Optional多くの場合、その役割を果たすことができるクラスを提供します。これについては、StackOverflowで詳しく説明しています。