HertzBeat告警聚合模块中ImmutableMap导致的UnsupportedOperationException问题分析

问题背景

在Apache HertzBeat告警系统的告警聚合模块(AlarmCommonReduce)中，开发人员遇到了一个意外的运行时异常。当尝试修改告警对象的tags属性时，系统抛出UnsupportedOperationException异常，导致告警聚合功能无法正常工作。这个问题源于Java集合框架中不可变集合的特性与Lombok工具生成代码的交互问题。

问题现象

在AlarmCommonReduce类的reduceAndSendAlarm方法中，开发人员尝试对告警对象的tags属性进行修改操作时，系统抛出以下异常：

java.lang.UnsupportedOperationException
    at java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
    at java.base/java.util.ImmutableCollections$AbstractImmutableMap.put(ImmutableCollections.java:1072)

从异常堆栈可以明显看出，问题发生在尝试向一个不可变Map执行put操作时。

根本原因分析

经过深入分析，这个问题由以下几个因素共同导致：

1. Lombok的@Data注解行为：在Alert类上使用了Lombok的@Data注解，它会自动生成所有属性的getter和setter方法。对于Map类型的tags属性，生成的setter方法直接使用了传入的Map引用，而没有创建防御性副本。

2. 不可变集合的特性：当外部传入的Map是一个不可变Map(如Collections.unmodifiableMap或Map.of创建的Map)时，任何修改操作(如put)都会抛出UnsupportedOperationException。

3. 业务逻辑假设：AlarmCommonReduce.reduceAndSendAlarm方法的业务逻辑假设tags属性是可修改的Map，这在传入不可变Map时就会导致问题。

解决方案

针对这个问题，我们有以下几种解决方案：

方案一：修改Alert类的setTags方法

在Alert类中，覆盖Lombok自动生成的setTags方法，确保总是创建一个可修改的Map副本：

public void setTags(Map<String, String> tags) {
    this.tags = tags != null ? new HashMap<>(tags) : null;
}

方案二：在reduceAndSendAlarm方法中防御性处理

在业务方法中处理不可变Map的情况：

public void reduceAndSendAlarm(Alert alert) {
    alert.setTimes(1);
    Map<String, String> tags = alert.getTags();
    if (tags == null) {
        tags = new HashMap<>(8);
        alert.setTags(tags);
    } else if (tags.getClass().getSimpleName().contains("Unmodifiable")) {
        // 如果是不可变Map，则创建新Map替换
        tags = new HashMap<>(tags);
        alert.setTags(tags);
    }
    // 后续业务逻辑...
}

方案三：使用Lombok的定制配置

通过Lombok的配置注解指定setter方法的行为：

@Setter(AccessLevel.PROTECTED)
private Map<String, String> tags;

// 然后提供自定义的setter方法
public void setTags(Map<String, String> tags) {
    this.tags = tags != null ? new HashMap<>(tags) : null;
}

最佳实践建议

1. 防御性编程：对于集合类型的属性，在setter方法中总是创建防御性副本，避免外部修改影响内部状态。

2. 明确集合可变性：在API文档中明确说明集合参数是否接受不可变集合，以及方法是否会修改集合内容。

3. Lombok使用注意：谨慎使用Lombok的@Data注解，特别是当类包含集合类型属性时，考虑手动实现关键方法或使用更细粒度的注解组合。

4. 单元测试覆盖：编写单元测试验证方法对不可变集合的处理行为，及早发现问题。

总结

这个问题的出现提醒我们在使用便捷工具(如Lombok)时，仍需保持对底层实现的清醒认识。特别是在处理集合类型时，可变性问题往往容易被忽视，但却可能导致严重的运行时异常。通过分析这个问题，我们不仅解决了具体的bug，更重要的是建立了更健壮的编码实践，提高了系统的稳定性和可靠性。