最近线上遇到几个小问题,排查代码发现基本都是些细节问题,做些总结提示大家不要掉到坑中。
一、fastjson的序列化SerializerFeature使用注意
我们都知道Integer、Double、Boolean等包装类型的字段默认值是null。如果不对这些字段设置值,那么在反序列化时得到的相应的值也应该是null。
本次服务接口升级后导致调用方业务逻辑判断失败,比如Integer type 在升级之前是返回的null,而升级后返回了数字0。究其原因发现同事在序列化时设置了SerializerFeature.WriteNullNumberAsZero,而导致Number类型(Boolean,Integer,Float,Double等)都转成了0。
我们常用的SerializerFeature:
总结:
1、服务接口的测试用例覆盖率还是太低
2、对于通用处理工具,在做修改时对工具类的前因后果要清楚
二、java.util.List.subList的陷阱
我们一般都会使用java.util.List中有一个subList方法,返回一个以fromIndex为起始索引(包含),以toIndex为终止索引(不包含)的一部分的视图(List)。
List<E> subList(int fromIndex, int toIndex);
之所以说是视图,是因为实际上,返回的list是靠原来的list支持的。原来的list和返回的list做的“非结构性修改”(non-structural changes),都会影响到彼此对方。
所谓的“非结构性修改”,是指不涉及到list的大小改变的修改。相反,结构性修改,指改变了list大小的修改。
如果发生结构性修改的是返回的子list,那么原来的list的大小也会发生变化;
如果发生结构性修改的是原来的list(不包括由于返回的子list导致的改变),那么会是抛出一个ConcurrentModificationException。
list.remove(index)
list.subList(int fromIndex, int toIndex).clear();
List<Integer> subList2 = new ArrayList<Integer>(list2.subList(2, list2.size()));
三、illegal character: \65279
同事使用SVN提交java文件,发现有冲突使用UltraEdit进行了修改,重新编译时却报了异常
java:[1,0] illegal character: \65279
解决方法
将文件重新保存成UTF-8 无BOM即可。
具体原因参看高人的解释
http://blog.csdn.net/shixing_11/article/details/6976900
由于本人经验有限,文章中难免会有错误,请浏览文章的您指正或有不同的观点共同探讨!
线上问题 - illegal character: \65279、FastJson SerializerFeature和java.util.List.subList
原文:http://www.cnblogs.com/exceptioneye/p/4887290.html