背景

惯例先交待一下事件的背景，最近在调试接口的时候发现一个奇怪的现象，页面某一处显示的数据在我未对其做更改的情况下发生了变化。通过查看代码发现，页面会发送请求，然后将请求值做一层包装，之后传给其他模块做存储。

过程

一开始怀疑是其他模块动了数据，而且操作错了，经过调试代码发现不是那么回事儿~~，数据在传送之前就已经有问题了。更诡异的是，看上去根本没做啥啊，这代码的简单程度简直和HelloWord差不多了，类似于下面这样的

List<Item> list = items.stream().map(t -> {
    Item item = new Item();
    
    Map<String, Object> extraMap = t.getExtraMap();
    if (extraMap == null) {
        extraMap = new HashMap<>();
        item.setExtraMap(extraMap);
    }
    extraMap.put("decreaseRate", decreaseRateMap.get(t.getId()));
    item.setExtraMap(extraMap);
    return item;
}).collect(Collectors.toList());

其中items是我从DB里面查出来的数据，我这边要做的就是看看items里面extraMap这个字段有没有值，没有就新建一个，然后增加一个KV对赋值给新的对象，组成一个新的集合，decreaseRateMap是一个含有固定值的map。

但是诡异的现象是，decreaseRateMap有两个K-V对，1->0、2->800，然后items也有两个对象，分别对应的id是1和2。按照常理，最终得到的list里面应该有两个item对象，然后分别有有个extraMap属性值，一个是decreaseRate->0，一个是decreaseRate->800 。但是最后得到的结果却是两个都是decreaseRate->800。百思不得其解，打断点，发现直到item在循环中返回，它的extraMap的值还是对的，为啥最后collect就变了呢？

其实光看这段代码是没有问题的，还有一个隐藏剧情，Item是通过dubbo接口获取，里面有个set方法如下：

public void setExtra(String extra) {
    this.extra = extra;
    if(Strings.isNullOrEmpty(extra)){
        this.extraMap= Collections.emptyMap();
    } else{
        this.extraMap = JsonMapper.JSON_NON_EMPTY_MAPPER.fromJson(extra,  MAP_OF_STRING);
    }
}

大致意思就是extra是Item的一个json字段，String型的，落库，而extraMap是一个对应extra的Map，不落库，方便外部查询使用的。因为重写了setExtra方法，所以如果某个Item在数据库表中的extra字段为null，当它从DB被查出来的时候extraMap会被设置为一个空Map。

一切看上去很正常？看一下Collections.emptyMap()的源码：

/**
 * Returns an empty map (immutable).  This map is serializable.
 *
 * <p>This example illustrates the type-safe way to obtain an empty map:
 * <pre>
 *     Map<String, Date> s = Collections.emptyMap();
 * </pre>
 * @implNote Implementations of this method need not create a separate
 * {@code Map} object for each call.  Using this method is likely to have
 * comparable cost to using the like-named field.  (Unlike this method, the
 * field does not provide type safety.)
 *
 * @param <K> the class of the map keys
 * @param <V> the class of the map values
 * @return an empty map
 * @see #EMPTY_MAP
 * @since 1.5
 */
@SuppressWarnings("unchecked")
public static final <K,V> Map<K,V> emptyMap() {
    return (Map<K,V>) EMPTY_MAP;
}

可以看到，使用这个方法比直接new一个map的花费要小，但是这个方法返回的map是immutable的，也就是不可变的，是一个EmptyMap实例，继承自AbstractMap，当尝试对这个map执行put操作时，会抛异常:

Exception in thread "main" java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at com.example.demo.StreamSetDemo.lambda$main$0(StreamSetDemo.java:43)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at com.example.demo.StreamSetDemo.main(StreamSetDemo.java:46)

细心的同学会发现，不对呀，这个map是不可变的跟你出现的这个问题有半毛钱关系吗？你的代码在执行extraMap.put("decreaseRate", decreaseRateMap.get(t.getId()));这一句时就应该抛异常。没错，照理确实是这样，但是请注意我的标题，所以这里还跟dubbo有关系。一开始我也说了，Item对象是通过dubbo接口获得的，这有什么关系吗？我们来看个例子，这里省略了dubbo的相关配置和接口。

provider：

public class DemoServiceImpl implements DemoService {
    
    @Override
    public List<Item> getItems() {
        Item item1 = new Item();
        item1.setExtraMap(Collections.emptyMap());
        Item item2 = new Item();
        item2.setExtraMap(Collections.emptyMap());
        List<Item> itemList = new ArrayList<>();
        itemList.add(item1);
        itemList.add(item2);
        return itemList;
    }
}

provider启动类：

public class Application {
    public static void main(String[] args) throws Exception {
        ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
        service.setApplication(new ApplicationConfig("dubbo-demo-api-provider"));
        service.setRegistry(new RegistryConfig("multicast://224.5.6.7:1234"));
        service.setInterface(DemoService.class);
        service.setRef(new DemoServiceImpl());
        service.export();
        System.in.read();
    }
}

consumer：

public class Application {
    public static void main(String[] args) {
        ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
        reference.setApplication(new ApplicationConfig("dubbo-demo-api-consumer"));
        reference.setRegistry(new RegistryConfig("multicast://224.5.6.7:1234"));
        reference.setInterface(DemoService.class);
        DemoService service = reference.get();
        List<Item> items = service.getItems();
        System.out.println(items);
    }
}

启动provider，然后跑一下consumer，在System.out.println(items)打上断点

我们看到了什么！在consumer端，这里的extraMap从EmptyMap变成了HashMap，所以extraMap可以put了。这不是最令人惊奇的，注意两个item中map的内存地址，都是2446，也就是说，这两个map指向的是同一个对象！这就解释了我一开始碰到的问题，因为两个item中的map指向的是同一个对象，所以第二次put的时候就把第一次的值覆盖了，最终两个item中的map就都变成了最后的那次赋值。

但是这里为什么两个map会是同一个对象呢？这个跟Collections.emptyMap()方法有关，注释说这个方法能够减少消耗，返回不可变集合哪里减少消耗了？关键是，这个方法返回的是一个final型的内部变量

public static final Map EMPTY_MAP = new EmptyMap<>();

所以，如果在程序的不同地方都调用了Collections.emptyMap()，其实返回的是同一个对象。

以下是我关于hessian序列化的猜测了：

dubbo默认使用的hessian序列化会考虑到引用是否相同，所以虽然EmptyMap经历序列化和反序列化后变成了HashMap，但是引用指向相同的特性还是保留了下来，结果就变成了两个HashMap指向了相同的对象。

总结

1. 序列化的内部机制有时候会有隐藏的坑，小心误踩
2. Collections的某些方法要注意使用场景，只有确保返回接口不会被修改的情况下再去使用emptyMap()等方法