我在大厂做 CR——如何体系化防控空指针异常
大家好,我是木宛哥,今天和大家分享下——代码 CR 时针对恼人的空指针异常(NullPointerException
)如何做到体系化去防控;
什么是空指针异常
从内存角度看,对象的实例化需要在堆内存中分配空间。如果一个对象没有被创建,那也就没有分配内存,当应用程序访问空对象时,实际上是访问一个“无效”的内存区域,从而导致系统抛出异常。
我们在 Java 编程时,空指针异常是一个常见的运行时错误,严重甚至会导致进程退出。所以这也是为什么我们要在 CR 时如此重视它的原因。
CR 我们要做什么
木宛哥认为 CR 应该重点关注三点:
- 业务逻辑正确性
- 代码的可读性和可维护性
- 代码的健壮性和稳定性
OK,再回过头来看,针对空指针异常,在 CR 时,更多要从代码的健壮性和稳定性切入,可分为:
- 防御性去杜绝空指针异常的出现(大多是访问了不存在的对象)
- 对三方框架或者 JDK 认知不完善导致的潜在空指针异常发生(更多靠评审参与者经验分享)
防御性编程
防御性编程是非常有必要的,一方面可以提高系统稳定性和健壮性,另一方面可以形成比较好的代码规范;同时也是非常重要的思想,每个人都会如此去实践,在 CR 时针对空指针异常的防御是 common sense
;例如:
1.防御使用了未初始化的对象:
MyObject obj = null;
if (obj!= null){
obj.someMethod();
}
2.防御使用了对象没有初始化的字段;
class MyClass {
String name;
}
MyClass obj = new MyClass();
if (StringUtils.isNotBlank(obj.getName())){
// do something
}
3.防御当调用方法返回 null 后,试图对返回的对象调用其方法或属性:
MyObject obj = getMyObject(); // 假设返回 null
if (obj != null) {
obj.someMethod();
}
4.防御访问了集合中不存在的元素:
- Map.get() 方法返回 null
- Queue 的方法如 poll() 或 peek() 返回 null
Map<String ,String> dummyMap = new HashMap<>();
String value = dummyMap.get("key");
if (org.apache.commons.lang3.StringUtils.isNotBlank(value)){
// do something
}
三方框架或 JDK 使用不当引发空指针异常提前排雷
这一类更多是三方框架或 JDK 的内部机制不清楚导致的踩坑,只有踩了这种类,
才会恍然大悟:“哦,原来这样啊,下回得注意了”;
所以针对这类问题,更多需要评审参与人的经验去发现,需要团队去共创,共建知识体系,例如:在团队空间维护“ TOP 100 踩坑记”等等;
在上篇文章《为什么建议使用枚举来替换布尔值》中,木宛哥提到过 Boolean
为 null
时产生的第三种结果,易造成 if
条件判断拆箱引发空指针问题,今天再继续分享其他:
1.三目运算符拆箱空指针问题
int var1 = 20;
Integer var2 = null;
boolean condition = true;
// 三目运算符拆箱问题,发生 NullPointerException
System.out.println(condition ? var2 : var1);
这里:condition
为 true
,所以三目运算符选择了 var2
(即 null
)。即: var2
(Integer
类型)赋值给 num
(Integer
类型)。理论上在这里应该是 num
被赋值为 null
。
但在 Java 中,三目运算符的返回类型需要通过类型来推导:
- 如果
var1
是int
类型,而var2
是Integer
类型,三目运算符会将它们的类型推导合并,令返回值为int
类型。 - 这意味着,如果
condition
为true
,则会尝试将var2
(null
)拆箱成int
。由于null
不能拆箱成int
,因此会抛出NullPointerException
这类典型的问题更多需要在 CR 时提前暴露出来,保证一致的参数类型来避免拆箱;
2.日志打印使用 fastjson 序列化时造成的空指针问题
大部分程序员编程开发习惯,喜欢打印参数到日志里,但有时候一个不起眼的 log.info
打印日志有可能导致接口异常;
如下打印日志,结果 fastjson
序列化异常,发生 NullPointerException
@Test
public void testJSONString() {
Employee employee = new Employee("jack", 100);
//fastjson 序列化异常,发生 NullPointerException
LoggerUtil.info(logger,"{}",JSON.toJSONString(employee));
}
static class Employee {
private EmployeeId employeeId;
private String name;
private Integer salary;
public Employee(String name, Integer salary) {
this.name = name;
this.salary = salary;
}
public String getName() {
return name;
}
public Integer getSalary() {
return salary;
}
public String getEmployeeId() {
return this.employeeId.getId();
}
}
static class EmployeeId {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
原因在于 fastjson
使用 JSON.toJSONString(employee)
序列化成 JSON 时,底层实际通过解析 get
开头方法来识别属性,即:调用 get
方法获取属性的 value
值;上述代码:employeeId
为 null
,但序列化时执行了 getEmployeeId
引发的空指针异常;
所以:特别是大家在实践 DDD 的时候,因为领域模型往往是充血模型,不仅有数据还包含了行为,对于行为可能习惯有 get
开头命名,要特别重视在打印领域模型时序列化问题;
3.对 Stream 流操作认知不完善导致的空指针异常
如果 Stream 流中存在空值,需要非常小心。
例如,如果第一个元素恰好为 null
,findFirst()
将抛出 NullPointerException
。这是因为 findFirst()
返回一个 Optional
,而 Optional
不能包含空值。
Arrays.asList(null, 1, 2).stream().findFirst();//发生 NullPointerException
max()
、min()
和 reduce()
,也表现出类似的行为。如果 null
是最终结果,则会抛出异常。
List<Integer> list = Arrays.asList(null, 1, 2);
var comparator = Comparator.<Integer>nullsLast(Comparator.naturalOrder());
System.out.println(list.stream().max(comparator));//发生 NullPointerException
再例如:我们在使用 Stream
流式编程时,如果流包含 null
,可以转换为 toList()
或 toSet()
;
然而,toMap()
要注意, 不允许空值(允许空Key):
Employee employee1 = new Employee("Jack", 10000);
Employee employee2 = new Employee(null, 10000);
//toMap的Value不能为空,此处异常
Map<Integer, String> salaryMap = Arrays.asList(employee1, employee2)
.stream()
.collect(Collectors.toMap(Employee::getSalary, Employee::getName));
以及:groupingBy()
不允许空 Key:
Employee employee1 = new Employee("Jack", 10000);
Employee employee2 = new Employee(null, 10000);
//groupingBy的Key不能为空,此处抛异常
Map<String, List<Employee>> result = Stream.of(employee1, employee2)
.collect(Collectors.groupingBy(Employee::getName));
可见在流中使用了空对象存在许多陷阱;所以,在 CR 时,要重点关注 Stream 流的数据来源,避免在流中存在 null
,不确定的话建议用 filter(Objects::nonNull)
将它们过滤掉。
再谈空指针防控手段
上一章更多还是从防御空指针去解问题,但能保证每个人都是认知一样吗,同时在 CR 时也会有漏网之鱼;下面代码我想每个人都会这样去避免空指针,但难免在某个加班到凌晨的日子,脑袋一抽筋写反了:(
if("DEFAULT".equals(var)){
//do something
}
所以,在这一章,木宛哥从数据来源切入,回答:“能否数据天生就是存在非空的、方法天生就是不会返回 null”?
从程序角度来看,是合理的;许多变量永远不包含 null
,许多方法也永远不返回 null
。我们可以分别称它们为“非空变量”和“非空方法”(NonNull
);
其他变量和方法在某些情况下可能会包含或返回 null
,它们称为“可空”(Nullable
);
基于这个理论,在解空指针问题时,提供了另一种方式解法:
- 数据来自三方系统,控制权不在我们,故:不可信任,需要做好防御编程;
- 数据来自自身,控制权在我们,控制数据创建即非空,故:可信任;如下:
尽可能屏蔽 null 值
对输入值进行校验——在公共方法和构造函数中。需在每个 set
字段的入口处添加 Objects.requireNonNull()
调用。requireNonNull()
方法会在其参数为 null
时抛出 NullPointerException
。
public class Employee {
public Employee(String name, Integer salary) {
this.name = Objects.requireNonNull(name);
this.salary = Objects.requireNonNull(salary);
}
}
这样做有助于在入口处屏蔽 null
值的写入
如果你的方法接受集合作为输入,也可以在方法入口遍历该集合以确保它不包含 null
值:
public void check(Collection<String> data) {
data.forEach(Objects::requireNonNull);
}
注:此处需要视具体集合的大小以及评估性能损耗;
同样的类型场景,不详细举例了:
- 当你的类型是集合时,返回一个空容器,而不是返回
null
,可以避免消费方出现空指针异常; - 使用枚举常量来替换
Boolean
来避免拆箱引入的空指针异常 - 非法数据状态,直接短路抛出异常而不是返回
null
;
善用静态分析工具来辅助
介绍两个重要的注解:@Nullable
和@NotNull
注解:
@Nullable
注解意味着预期被注释的变量可能包含null
,或者被注释的方法可能返回null
;@NotNull
注释意味着预期的值绝不是null
。并为静态分析提供了提示
这类注解,可以在静态分析工具实时分析潜在的异常;
interface Processor {
@NotNull
String getNotNullValue();
@Nullable
String getNullable();
public void process() {
//此处警告:条件永远为假,不用多次一举
if (getNotNullValue() == null) {
//do something
}
//此处警告:trim() 调用可能导致 NullPointerException
System.out.println(getNullable().trim());
}
}
再谈使用 Optional 替代 null 的一些注意事项
为了避免使用 null
,一些开发者倾向于使用 Optional
类型。可以将 Optional
想象成一个盒子,它要么是空的,要么包含一个非 null
的值:
获取Optional对象有三种标准方式:
Optional.empty()
—— 获取一个空的Optional
Optional.of(value)
—— 获取一个非空的Optional
,如果值为null
则抛出NullPointerException
Optional.ofNullable(value)
—— 如果值为null
则获取一个空的Optional
,否则获取一个包含值的非空Optional
使用 Optional
来预防空指针,大问题没有,但有几个细节需要注意:
1.勿滥用 ofNullable
一些开发者喜欢在所有地方使用 ofNullable()
,因为它被认为是更安全的,它从不抛出异常。但不能滥用,如果你已经知道你的值永远不会为null
,最好使用 Optional.of()
。在这种情况下,如果你看到一个异常,你会立即知道错了并且修复;
2.Optional 造成的代码可读性降低
如下代码获取员工地址,虽然简洁,但可读性很差,对于嵌套特别深的情况下,我还是不建议使用 Opinional
,毕竟代码除了给自己看还得让别人也一眼明白意图
String employeeAddress = Optional.ofNullable(employee)
.map(Employee::getAddress)
.map(Address::getStreet)
.map(Street::getNo)
.map(No::getNumber).orElseThrow(() -> new IllegalArgumentException("非法参数"));
事后的异常监控
事前禁止写入 null
,事中防御性编程空指针异常,但真的高枕无忧了吗?
未必,事后所以建立一套好的异常告警机制是非常重要的;
我建议针对关键字:NullPointerException
做单独的日志采集,同时配上相应的告警级别:理论上出现 1 次空指针异常就应该介入定位;
当然,特别是在发布周期内,如果 N
分钟内出现超过 M
次空指针异常那就肯定要快速定位和回滚了;
写在最后
欢迎关注我的公众号:编程启示录,第一时间获取最新消息;
微信 | 公众号 |
---|---|