先确认现象：你遇到的其实是二义性问题

当你在多线程环境下尝试向ConcurrentHashMap存入null键或null值时，代码会直接抛出NullPointerException。很多从HashMap迁移过来的开发者会感到困惑——明明HashMap允许null，为什么ConcurrentHashMap不行？我通常先问对方：你是想在get返回null时区分“键不存在”和“值为null”吗？如果是，那ConcurrentHashMap的设计恰恰是为了消除这种歧义。先确认这个现象，才能理解后续的约束。

设计原因：并发场景下的歧义必须消除

ConcurrentHashMap不允许key或value为null，根本原因在于它需要消除多线程环境下的歧义。在单线程的HashMap中，如果get返回null，既可以表示key不存在，也可以表示value本身就是null。但在并发场景下，这种二义性会引发严重问题。例如线程A先判断containsKey返回false，正准备put时，线程B可能插入了一个null值，导致A的判断失效。ConcurrentHashMap的设计者通过禁止null值，强制要求调用者明确区分“键不存在”和“值为null”这两种情况，从而简化并发控制逻辑。

除了二义性，还有一个底层原因：ConcurrentHashMap的内部实现（如红黑树转换、迁移节点）依赖value的非空性来进行同步判断。如果value为null，某些CAS操作或条件判断会失效，进而导致死循环或数据丢失。这不是性能问题，是API层面的硬性约束。

容易误判的地方：computeIfAbsent的null返回值陷阱

一个常见的陷阱是认为ConcurrentHashMap的computeIfAbsent方法允许null返回值。实际上，如果computeIfAbsent中的映射函数返回null，该方法会移除该key的映射，而不是保留一个null值。这与HashMap的行为不同，可能导致意外结果。例如：map.computeIfAbsent("key", k -> null); 执行后，map中不存在key="key"的映射。如果期望的是保留null值，则需要改用putIfAbsent并配合特殊标记。此外，在遍历ConcurrentHashMap时，如果value为null，迭代器不会抛异常，但这类情况本就不该出现。

另一个容易误判的地方是：认为可以借助Optional包装后存入ConcurrentHashMap。需要注意Optional本身不是Serializable，在分布式或需要序列化的场景中会引入额外问题。而且Optional的创建开销在频繁存取时不可忽视，是否选择取决于具体场景。

建议的处理顺序：先替换null，再考虑包装

在使用ConcurrentHashMap时，应避免将null作为key或value传入。如果业务上确实需要表示“无值”或“占位”，建议使用一个特殊的静态常量对象作为标记，例如private static final Object NULL_MARKER = new Object();。存储时用该标记替换null，读取后再通过标记判断是否对应原始null。这样既能保留语义，又符合ConcurrentHashMap的约束。另一种做法是使用Optional包装value，但需注意Optional本身不是Serializable，在分布式场景中需谨慎。

具体操作顺序：第一步，在put或putIfAbsent之前，检查入参是否为null，抛出IllegalArgumentException。第二步，如果需要将null作为有效值，用NULL_MARKER对象替换，并在get后做标记检查。第三步，对于批量操作（如putAll），也要确保null被过滤或替换。这样既保证了代码健壮性，也避免了运行时NPE。编码过程中，还可以借助IDE的静态分析或自定义代码检查规则来拦截null相关操作。ConcurrentHashMap的put和putIfAbsent方法会在传入null时直接抛出NullPointerException，运行时即可捕获。更主动的做法是在调用前显式判断入参是否为null：if (key == null || value == null) { throw new IllegalArgumentException(...); }。对于团队规范，建议在代码评审中重点检查ConcurrentHashMap的存取是否涉及null，避免因为习惯性地使用HashMap而引入隐患。

验证方法与后续维护

验证自己的处理是否正确，最直接的方法是在单元测试中构造并发场景：使用CountDownLatch模拟多线程同时put null，观察是否抛出NPE；或者使用标记对象后，验证get返回的正确性。对于使用了Optional包装的情况，需要额外测试序列化反序列化是否正常。在生产环境，可以通过日志监控NullPointerException的出现频率，一旦发现来自ConcurrentHashMap的存取，立即排查调用方代码。

后续维护时，需要注意：如果强行通过反射或Unsafe向ConcurrentHashMap写入null值，会破坏其内部的数据结构一致性，导致不可预知的并发错误。例如，ConcurrentHashMap的某些方法依赖于value的非空性来进行同步控制（如ForwardingNode），null值可能使这些判断失效，进而引发死循环或数据丢失。因此，任何绕过接口的null写入都不应出现在生产代码中。

当需要在并发容器中存储可能为null的值时，还可以考虑使用一个包装类来携带null语义。例如，定义一个ValueWrapper，包含一个boolean isNull和T actualValue。存储时，如果值为null，则创建isNull=true的包装实例；读取时再解包。另一种方案是改用ConcurrentSkipListMap，它允许value为null（但key不能为null），不过其排序特性可能带来额外成本。选择哪种替代取决于具体场景的读写比和null出现频率。