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

发布时间:2024-11-07 10:14  浏览量:1

大家好呀~我是小米,今天来给大家分享一个真实工作场景中排查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。希望这篇文章能够帮助到大家在工作中更好地处理类似的异常问题!

外部推荐