当dubbo序列化遇上Collections

3 篇文章 0 订阅

背景

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

过程

一开始怀疑是其他模块动了数据,而且操作错了,经过调试代码发现不是那么回事儿~~,数据在传送之前就已经有问题了。更诡异的是,看上去根本没做啥啊,这代码的简单程度简直和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这个字段有没有值,没有就新建一个,然后增加一个K-V对赋给新的对象,组成一个新的集合,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是通过dubb接口获取,里面的有个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(),其实返回的是同一个对象。

以下是我的猜测了,如果后期研究证实了会补上:

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

总结

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

本文由博客一文多发平台 OpenWrite 发布!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值