在Java 9，新的工厂方法已经出台了List，Set和Map接口。这些方法允许快速实例化一行中包含值的Map对象。现在，如果我们考虑：

Map<Integer, String> map1 = new HashMap<Integer, String>(Map.of(1, "value1", 2, "value2", 3, "value3"));
map1.put(4, null);

如果我们这样做，则上面的内容毫无例外地被允许：

Map<Integer, String> map2 = Map.of(1, "value1", 2, "value2", 3, "value3", 4, null );

它抛出：

Exception in thread "main" java.lang.NullPointerException
    at java.base/java.util.Objects.requireNonNull(Objects.java:221)
..

我无法获得，为什么在第二种情况下不允许null。

我知道HashMap可以将null作为键和值，但是在Map.of的情况下为什么要限制它呢？

java.util.Set.of("v1", "v2", null)和的情况相同java.util.List.of("v1", "v2", null)。

正如其他人所指出的，在Map合同允许拒绝空...

[某些]实现禁止null键和值[...]。尝试插入不合格的键或值会引发未经检查的异常，通常为NullPointerException或ClassCastException。

...，而收集工厂（不仅在地图上）就利用了。

它们不允许null键和值。尝试使用null键或值创建它们会导致NullPointerException。

但为什么？

null到现在为止，允许集合被视为设计错误。这有多种原因。一个好的方面就是可用性，其中最著名的麻烦制造者是Map::get。如果返回null，则不清楚密钥是丢失还是值是null。一般来说，保证null免费的收藏集更易于使用。在实现方面，它们还需要较少的特殊大小写，从而使代码更易于维护且性能更高。

您可以在本演讲中听Stuart Marks的解释，但JEP 269（介绍工厂方法的人）也对此进行了总结：

空元素，键和值将被禁止。（最近没有引入的集合不支持空值。）此外，禁止空值提供了更紧凑的内部表示，更快的访问权限和更少的特殊情况的机会。

由于HashMap在慢慢发现它的时候就已经泛滥成灾，因此在不破坏现有代码的情况下进行更改为时已晚，但是这些接口的最新实现（例如ConcurrentHashMap）不再允许null了，并且工厂方法的新集合也不例外。

（我认为另一个原因是，明确地使用null值被视为可能的实现错误，但我错了。那将要复制同样也是非法的键。）

因此，不允许使用null某些技术原因，但也可以使用创建的集合来提高代码的健壮性。

没错-一个HashMap允许存储空，没有了Map由静态工厂方法返回。并非所有地图都相同。

通常，据我所知，首先要允许在HashMap键中为null的地方有一个错误，但较新的集合禁止这种可能性。

想一想当您的条目中HashMap有一个具有特定键且值== null的情况。你得到了，它返回null。什么意思 它具有的映射null或不存在？

同样的Key-从这样的空键开始的哈希码必须一直被特别对待。禁止以null开头-使其更容易。

虽然HashMap允许空值，Map.of但不使用a，HashMap并且如果将其用作键或值，则抛出异常，如记录所示：

Map.of（）和Map.ofEntries（）静态工厂方法提供了一种创建不可变地图的便捷方法。这些方法创建的Map实例具有以下特征：

• ...

• 它们不允许空键和值。尝试使用空键或空值创建它们会导致NullPointerException。

在地图中允许空值是一个错误。我们现在可以看到它，但是我猜不清楚何时HashMap引入。NullpointerException是生产代码中最常见的错误。

我想说的是，JDK朝着帮助开发人员抵抗NPE灾难的方向发展。一些例子：

• 介绍 Optional
• Collectors.toMap(keyMapper, valueMapper)不允许既没有keyMapper，也不是valueMapper函数返回一个null值
• Stream.findFirst()Stream.findAny()如果找到的值是NPE并抛出NPEnull

因此，我认为禁止null新的JDK9不可变集合（和地图）的方向相同。

主要区别在于：当您以“选项1”方式构建自己的Map时……您在暗中说：“我想在做的事情中拥有完全的自由”。

因此，当您决定自己的地图应具有null键或空值（也许出于此处列出的原因）时，您就可以这样做。

但是“选项2”是关于方便的事情-可能打算用于常量。而Java背后的人们只是简单地决定：“当您使用这些便捷方法时，生成的映射将是无空的”。

允许空值意味着

 if (map.contains(key)) 

与...不同

 if (map.get(key) != null)

有时候可能是个问题。或更准确地说：在处理该地图对象时要记住这一点。

还有一个轶事提示为什么这似乎是一种合理的方法：我们的团队自己实施了类似的便捷方法。想一想：在不了解有关未来Java标准方法的计划的情况下，我们的方法完全一样：它们返回输入数据的不变副本；当您提供null元素时，它们就会抛出。我们甚至非常严格，以至于当您传递空列表/地图/ ...时，我们也会抱怨。

该文档没有说明为什么 null不允许：

它们不允许null键和值。尝试使用null键或值创建它们会导致NullPointerException。

在我看来，将要产生常量的Map.of()和Map.ofEntries()静态工厂方法大部分是由开发人员在编译类型下形成的。那么，将a保留null为键或值的原因是什么？

相比之下，Map#put通常是通过在null可能会出现键/值的运行时填充地图来使用。

在我看来，不可为空对键有意义，但对值没有意义。

1. 该Map接口变为弱合同，你不能没有看落实信任它的行为，这是假设你有机会看到它。Java11Map.of()不允许同时允许null值HashMap，但是它们都实现相同的Map协定-怎么来的？
2. 不能有空值或根本没有值，并且可以说不应将其视为不同的情况。当您获得键的值而您获得null时，谁在乎它是否被明确放置在其中？提供的键根本没有值，地图不包含这样的键，就这么简单。Null为null，没有nullnull或null ^ 2
3. 现有的库大量使用map作为将属性传递给它们的方法，其中许多是可选的，这Map.of()对于构造此类结构毫无用处。
4. Kotlin在编译时强制执行可空性，并允许具有空值的映射而不会发生已知问题。
5. 不允许使用空值的原因可能仅仅是由于实现细节和创建者的便利。

并非所有的Map都允许null为键

提到的原因docs of Map。

一些地图实现对它们可能包含的键和值有限制。例如，某些实现禁止空键和空值，而某些实现对其键的类型有限制。尝试插入不合格的键或值会引发未经检查的异常，通常为NullPointerException或ClassCastException。