阅读目录

// 第三方的实体类对象class Count{     Integer total;     String name;     String leavingNum;     //...}  public class DemoTest {      public void fun() {         Count count = new Count();         // 经过一系类对应值的获取之后         // 需要判断total是否为0,如果为0就进行其他的业务操作。        if (count.total == 0) {             // 比方说打印日志。        }     }      @Test     public void test() {         fun();     } }

　　他给我看的代码就是类似fun()方法中的代码, 我一看这个代码就感觉不对劲，我说你这个Count类下的total属性是int吗？如果是int就可以这么用。他说为什么？ “如果是Integer类型，那么它的初始值不是0而是null, 而你上面的这些逻辑又不能保证total 一定会获取到数值，那么它就还有可能是null，你这样使用的话就有可能包NPE的问题。所以针对对象的使用提前判空更有保障。” 我接着说。 在我说的过程中他反应还是很快的，立马查看了这个实体类中total字段的类型，于是就明白了。 如果没有养成提前使用判空的习惯（除非你能保证一定会有值），老手都容易会踩这样的坑。比方说针对Boolean类型的使用，有很多人会直接这样的哦（这样肯定会有问题的）。

        Boolean flag = null;         // 经过一系类操作处理         // 进行判断        if (flag) {           //......          }

　　另外针对基本类型的封装类型使用还有些要注意的请看这篇文章：https://www.cnblogs.com/yuanfy008/p/8321217.html

二、subList带来的隐患

　　现在有很多都是基于分布式服务，那应该会存在这个域对应数据需要同步到其他域下，然后这种同步必然会产生差异，需要一种自检的job去检测差异。打个比方有些商家自己有官网售卖自己的产品，也还有可能会在天猫开旗舰店售卖。假如它分配在天猫的商品信息是通过它本地天猫数据库同步过去的，那么这种难免会产生差异，特别是库存，如果一边多一边少就可能会导致超卖的情况。 所以这种情况需要有个job对比两边的差异，下面先简单模拟下事发情况（注意下面的用法）：

 1 public class SubListTest {  2  3     @Test  4     public void test1() {  5         // 初始集合（有序） 6         List<Integer> list = new ArrayList<>();  7         list.addAll(Arrays.asList(1, 2, 3, 4));  8  9         // 业务场景：需要将list集合与很多场景下的数据进行对比，然后取出不同的。 
                        
关键字：