在 Java 語言中，ConcurrentHashMap 和 Hashtable 這些執行緒安全的集合是不允許 key 或 value 插入 null 值的，但是非執行緒安全的 HashMap 又可以插入 null 值，這到底是為什麼呢？
# null 值插入
首先給 HashMap 插入 null 值，實現程式碼如下：
HashMap<String, Object> map = new HashMap();// 插入 null 值map.put(null, null);if (map.containsKey(null)) {
System.out.println("存在 null");} else {
System.out.println("不存在 null");}
以上程式的執行結果如下：
從上述結果可以看出，HashMap 是允許 key 或 value 插入 null 值的。 接著我們使用同樣的方式嘗試給 ConcurrentHashMap 的 key 和 value 插入 null 值，實現程式碼如下：
編譯階段沒有報錯，執行以上程式，得到的結果如下：
從上述報錯資訊可以看出，使用 ConcurrentHashMap 是不能插入 null 值的，否者程式在執行期間就會報空指標異常。
PS：Hashtable 使用與 ConcurrentHashMap 類似，這裏就不再重複演示了。
# ConcurrentHashMap 原始碼分析
爲了尋找報錯的原因，我們嘗試開啟 ConcurrentHashMap 的原始碼一探究竟。 開啟 ConcurrentHashMap 新增元素的方法 put 實現原始碼如下： 
從上述原始碼可以看出，在新增方法的第一句就加了判斷：如果 key 值為 null 或者是 value 值為 null，就直接丟擲異常 NullPointerException 空指標異常，這就是咱們前面程式報錯的原因了。
# 探索最終原因
透過上面原始碼分析，我們似乎已經找到了 ConcurrentHashMap 不允許插入 null 值的原因，用一句話概括就是：烏龜的屁股“規定”！ 然而，這個原因是不能說服面試官的，雖然原始碼是這樣設計的，但我們要思考的是，這樣設計背後更深層次的原因，為什麼 ConcurrentHashMap 不允許插入 null？而 HashMap 又允許插入 null 呢？
# 二義性問題
所謂的二義性問題是指含義不清或不明確。 我們假設 ConcurrentHashMap 允許插入 null，那麼此時就會有二義性問題，它的二義性含義有兩個：
值沒有在集合中，所以返回 null。
值就是 null，所以返回的就是它原本的 null 值。
可以看出這就是 ConcurrentHashMap 的二義性問題，那為什麼 HashMap 就不怕二義性問題呢？
# 可證偽的 HashMap
上面說到 HashMap 是不怕二義性問題的，為什麼呢？ 這是因為 HashMap 的設計是給單執行緒使用的，所以如果查詢到了 null 值，我們可以透過 hashMap.containsKey(key) 的方法來區分這個 null 值到底是存入的 null？還是壓根不存在的 null？這樣二義性問題就得到了解決，所以 HashMap 不怕二義性問題。
# 不可證偽的 ConcurrentHashMap
而 ConcurrentHashMap 就不一樣了，因為 ConcurrentHashMap 使用的場景是多執行緒，所以它的情況更加複雜。 我們假設 ConcurrentHashMap 可以存入 null 值，有這樣一個場景，現在有一個執行緒 A 呼叫了 concurrentHashMap.containsKey(key)，我們期望返回的結果是 false，但在我們呼叫 concurrentHashMap.containsKey(key) 之後，未返回結果之前，執行緒 B 又呼叫了 concurrentHashMap.put(key,null) 存入了 null 值，那麼執行緒 A 最終返回的結果就是 true 了，這個結果和我們之前預想的 false 完全不一樣。
也就是說，多執行緒的狀況非常複雜，我們沒辦法判斷某一個時刻返回的 null 值，到底是值為 null，還是壓根就不存在，也就是二義性問題不可被證偽，所以 ConcurrentHashMap 纔會在原始碼中這樣設計，直接杜絕 key 或 value 為 null 的歧義問題。
# ConcurrentHashMap 設計者的回答
對於 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
以上信件的主要意思是，Doug Lea 認為這樣設計最主要的原因是：不容忍在併發場景下出現歧義！
# 小結
在 Java 語言中，HashMap 這種單執行緒下使用的集合是可以設定 null 值的，而併發集合如 ConcurrentHashMap 或 Hashtable 是不允許給 key 或 value 設定 null 值的，這是 JDK 原始碼層面直接實現的，這樣設計的目的主要是爲了防止併發場景下的歧義問題。
# 參考文件
www.cnblogs.com/fanguangdexiaoyuer/p/12335921.html
