为什么ConcurrentHashMap不允许插入null值？

95 阅读 0 评论 63 点赞

我是靠谱客的博主自然冬瓜，最近开发中收集的这篇文章主要介绍为什么ConcurrentHashMap不允许插入null值？，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

需要面试文档的扫描下方二维码

在Java语言中，给ConcurrentHashMap和Hashtable这些线程安全的集合中的Key或者Value插入 null（空）值的会报空指针异常，但是单线程操作的HashMap又允许 Key 或者 Value 插入 null（空）值。这到底是为什么呢？

1、探寻源码

为了找到原因，我们先来看这样一段源码片段，打开ConcurrentHashMap的putVal()方法，源码中第一句就非常明确地做了判断，如果 Key 或者 Value 为 null（空）值，就直接抛出空指针异常。

我们在源码中似乎已经找到了原因，你可以这样回答面试官，说JDK源码就是这么规定的。然而，这个原因是不能说服面试官的，虽然，源码是这样设计的，我们要思考的是，这样设计背后更深层次的原因。

那到底为什么ConcurrentHashMap不允许插入 null （空）值，HashMap又允许插入呢？

2、歧义问题

因为给ConcurrentHashMap中插入 null （空）值会存在歧义。我们可以假设ConcurrentHashMap允许插入 null（空）值，那么，我们取值的时候会出现两种结果：

1、值没有在集合中，所以返回的结果就是 null （空）；

2、值就是 null（空），所以返回的结果就是它原本的 null（空）值。

这就产生了歧义问题。

那HashMap允许插入 null（空）值，难道它就不担心出现歧义吗？这是因为HashMap的设计是给单线程使用的，所以如果取到 null（空）值，我们可以通过HashMap的 containsKey(key)方法来区分这个 null（空）值到底是插入值是 null（空），还是本就没有才返回的 null（空）值。

而 ConcurrentHashMap 就不一样了，因为 ConcurrentHashMap 是在多线程场景下使用的，它的情况更加复杂。

举个例子，现在有线程T1调用了 ConcurrentHashMap 的 containsKey(key) 方法，我们期望返回的结果是false，也就是说，T1并没有往ConcurrentHashMap中 put null（空）值。

但是，恰恰出了个意外，在线程T1还没有得到返回结果之前，线程T2又调用了ConcurrentHashMap 的 put() 方法，插入了一个Key，并且存入的Value是 null（空）值。那么，线程T1 最终得到的返回结果就变成 true 了。

显然，这个结果和我们之前期望的 false 完全不一致。

也就是说，在多线程的复杂情况下，我们多线程的复杂情况下，到底是插入的 null（空）值，还是本就没有才返回的 null（空）值。也就是说，产生的歧义不能被证伪，

3、作者回复

对于 ConcurrentHashMap 不允许插入 null 值的问题，有人问过 ConcurrentHashMap 的作者 Doug Lea，以下是他回复的邮件内容：

The main reason that nulls aren't allowed in ConcurrentMaps (ConcurrentHashMaps, ConcurrentSkipListMaps) is that ambiguities that may be just barely tolerable in non-concurrent maps can't be accommodated. The main one is that if map.get(key) returns null, you can't detect whether the key explicitly maps to null vs the key isn't mapped.
In a non-concurrent map, you can check this via map.contains(key),but in a concurrent one, the map might have changed between calls.

Further digressing: I personally think that allowing
nulls in Maps (also Sets) is an open invitation for programs
to contain errors that remain undetected until
they break at just the wrong time. (Whether to allow nulls even
in non-concurrent Maps/Sets is one of the few design issues surrounding
Collections that Josh Bloch and I have long disagreed about.)

It is very difficult to check for null keys and values
in my entire application .

Would it be easier to declare somewhere
static final Object NULL = new Object();
and replace all use of nulls in uses of maps with NULL?

-Doug