add()方法导致NPE？不可变集合singletonList的隐藏陷阱！

大家好呀~我是小米，今天来给大家分享一个真实工作场景中排查NPE（NullPointerException）异常的过程。昨天，测试童鞋找到我们，说在测试环境中打开退单详情时，页面直接崩了！NPE报错突然出现，而且竟然是在调用集合的add方法时出问题了。为了不影响后续测试进度，我们立刻投入排查，最终快速定位到了问题代码，并解决了问题。接下来，带大家一起回顾下我们是如何排查和修复这个问题的，希望对大家有所帮助！

1. 接到报错请求

测试环境的退单详情页面无法打开，直接报NPE异常。在这种情况下，我们首先要了解报错的具体场景，以便重现并分析问题。

场景描述：测试人员在测试环境中打开退单详情，页面直接报错。初步猜测：一般情况下，退单详情报错大概率出现在数据初始化、调用方法过程或者前后端数据交互过程中。

2. 查看日志信息

为了定位错误点，我们迅速打开了日志，通过日志找到相关信息。看到如下报错信息：

通过日志定位，我们很快找到了出错的具体位置。在代码中，是一个对集合进行add操作的地方发生了NPE。

3. 锁定代码片段

打开代码后，我们找到了对应的错误代码。错误的代码大概如下所示：

通过代码来看，returnItemList是通过Collections.singletonList(returnItemVO)创建的。显然，后续在调用add方法时出现了NPE异常。

看到Collections.singletonList和add方法的组合出错，我们先来分析一下这个singletonList到底是个什么鬼！看名字singletonList，似乎代表“单例集合”的意思，那它究竟是什么特性导致了NPE呢？

什么是Collections.singletonList？

Collections.singletonList(T o)是JDK集合工具类中的一个静态方法，用于返回一个只有一个元素的不可变集合。简单来说，它构造了一个只能包含单个元素的集合，而且这个集合是不可修改的。

为什么调用add会报错？

singletonList方法返回的是一个特殊的实现类：SingletonList，该类的add方法是由抽象类AbstractList实现的。由于这是一个不可变集合，add操作会直接抛出UnsupportedOperationException。因此在上面的代码中，returnItemList.add(new ReturnItemVO)直接触发了NPE。

因此问题根源在于Collections.singletonList的特性，这一特性导致集合在被创建后无法进行修改操作。

为了帮助大家更深入地理解这个报错，让我们进一步分析singletonList的实现细节。通过阅读源码，我们可以看到singletonList返回的是一个由AbstractList抽象类实现的不可变集合。源码中的核心代码如下：

在SingletonList类的内部，并没有实现add方法，而是通过父类AbstractList的默认实现来实现。因此调用add会抛出UnsupportedOperationException。

特性总结

Collections.singletonList的几个主要特点：

既然singletonList无法满足我们的需求，那我们该如何修改代码呢？要解决这个问题，最简单的方式是使用一个可以正常操作的可变集合，比如ArrayList。可以通过如下代码来替换：

这样一来，我们就将不可变集合替换为了可变的ArrayList，成功规避了add方法的报错。

修改后的代码

我们将原始代码中的不可变集合Collections.singletonList替换为Google Guava中的Lists.newArrayList来创建一个可变集合。代码修改如下：

这里我们使用了Lists.newArrayList(returnItemVO)来创建一个新的ArrayList，初始化时包含returnItemVO对象，同时可以正常执行add方法。

测试验证正确选择集合类型：Collections.singletonList创建的是不可变集合，在尝试对其进行添加或删除操作时会直接报错。因此在实际开发中，我们要慎用不可变集合，特别是在需要动态增删集合元素的场景下，应该优先选择ArrayList等可变集合。掌握集合工具类的特性：Collections类提供了很多方便的方法来创建集合，像singletonList、emptyList等不可变集合的创建方法在某些特殊场景下非常有用，但同时也容易引发NPE等异常。因此要熟悉并掌握工具类的特性和局限，避免不必要的坑。日志定位与源码阅读的重要性：在实际工作中，异常处理不仅要依赖IDE调试工具，还需要通过日志快速定位问题，找到问题代码后，通过阅读相关类和方法的源码，进一步确定问题的根本原因，这样才能更快速地解决问题。

这次的NPE问题给我们团队一个小小的提醒：即使是一个简单的集合类型选择也可能引发应用级别的问题。在今后的开发中，我们会更加注意代码细节，避免不必要的Bug。希望这篇文章能够帮助到大家在工作中更好地处理类似的异常问题！