背景


阿里云上有个阿里巴巴编码规范认证,我估算一下时间成本很低,多个认证也没什么坏处,就花了1分钱报了个名。这个认证报名后就可以下载链接下的编码规范,然后参加个考试应该就OK了。 


共48页的规范实际上每读一遍都是要花一些时间的,因为每读一遍就会发现上面有些东西我不信。我需要去证明。过去证明过的因为JDK版本升级迭代有可能需要继续证明。下面是其中的一些证明过程。

 

案例1

规范原文

【强制】不要在foreach循环里进行元素的remove/add操作。remove元素请使用Iterator方式,如果并发操作需要对Iterator对象加锁。

正例:

List<String> list = new ArrayList<>();

list.add("1");

list.add("2");

Iterator<String> iteraot = list.interator();

while(iterator.hasNext()){

    String item = iterator.next();

    if(删除元素的条件) {

          iterator.remove();

    }

}

反例:

for(String item : list) {

      if("1".equals(item)) {

             list.remove(item);

      }

}

说明:以上代码的执行结果肯定会出乎大家的意料,那么试一下把"1"换成"2",会是同样的结果吗?

证明

1.先按照反例例文运行测试(test1)



list里两个元素,remove掉一个,剩下1个。这应该是符合大多数人预期的。

2.按照说明把"1"换成"2"运行测试(test2)



这里没有按照预期remove掉"2",而是抛出了并发修改异常。点击到异常的地方

3.根据异常提示。找到抛出异常代码的地方查看是哪个方法抛出异常:



4.对源码做一个解析:

抛出并发修改异常的条件是modCount!=expectedModCount。


5.根据这个条件,我做一个推测:在一个操作里把这两者的值改的不一样了,因为这里调用了remove修改方法。我自然就推测是remove方法做的修改,来看remove方法的源码:





6.果然,源码中将modCount++,但是expectedModCount并没有修改。证明了推测。运行完remove后需要判断for(String
item : list) ,这时候调用了迭代器的next方法。这样我理解了上面test2里为什么会抛出异常。那么再来思考下test1为什么不抛出异常呢?

7.我们来debug一下test1的情况1

运行完remove方法后,可看到这时候modCount!=expectedModCount,但是这时候只执行了hasNext(),判断了cursor !=
size,这时候不会执行next方法,所以不会产生异常。而下面再用到list时迭代器是新的迭代器,会把modCount=expectedModCount;



结论


如果list在for循环里调用remove方法是会抛出并发修改异常的,但是如果只修改了第1个就返回的情况是个例外,因为这时候不会调用next方法判断modCount和expectedModCount是否相等。


使用代码规范推荐的迭代器,底层remove方法会将modCount和expectedModCount一起修改,所以单线程不会有并发问题,作为类的成员变量,多线程情况下被修改就不确定了。

思考题

下面代码的执行结果是多少?



案例2

规范原文


【强制】在JDK7版本及以上,Comparotor实现类要满足如下三个条件,不然Arrays.sort、Collections.sort会抛IllegalArgumentException异常。

说明:三个条件如下

1)x、y的比较结果和y、x的比较结果相反。

2)x>y, y>z,则x>z。

3)x=y,则x,z比较结果和y,z比较结果相同。

反例:下例中没有处理相等的情况,交换两个对象判断结果并不互反,不符合第一个条件,在实际使用中可能会出现异常。

new Comparotor<Student>() {

    @Override

    public int compare(Student o1, Student o2) {

           return o1.getId()>o2.getId()?1:-1;

    }

}

证明

1.我们先来看看反例在实际使用中会抛出什么异常。



 

 




2.测试发现不论是Collections.sort还是Arrays.sort都抛出错误说必须实现Comparable接口而不是Comparator接口。而Comparable接口是不需要满足规范里所说的自反性、传递性和对称性的。

那为什么规范里会这么说呢?


3.我查了Collections类的源码,确实有几个方法用到了Comparator类。包括反转、二分查找、最大值、最小值和几个sort等。后面的原来sort是可以后面接Comparator参数的。



4. 然而我用源码的两个参数形式传入后,运行了几个例子并没有抛出非法参数异常。于是我又在源码中找线索。


Collections.sort底层用了Arrays.sort,Arrays.sort底层用了TimSort,TimSort有两处会抛出这个异常,看源码是在二分查找merge结果的时候。



5.使用这个sort果然是发生了非法参数异常。



6.具体为什么会发生异常,我打了断点,使用debug跟了一下TimSort源码,大体是有部分排序使用了if(x<y) else
判断,又一些方法里使用了if(x<=y)来判断。这两个结果对于等于的情况是冲突的。这时候会发生异常。

总结

实现Comparator的compare方法要满足自反性、对称性、传递性。

案例3

规范原文





分析


1.从上面总结来看线程安全的Map的key和value都不能为null。线程不安全的可以为null。大家都知道map的key要进行hash。对null进行hash不会空指针吗?

带着这个疑问,打开HashMap的源码看到hash方法有对null做判断,如果null则hash值为0。所以不会NPE



 

2.TreeMap的put方法没有对key做任何的判断,然后会调用compare方法,这里会抛出NPE



3.那么对于key如果不做特殊处理,肯定是要抛出NPE的,应该没有什么疑问了。为什么有的value为空也会NPE呢?



从上面源码可知道ConcurrentHashMap就是这么处理的,算是强制。

 

4.而Hashtable也是强制。



 


5.为什么线程安全的容器要设计成key和value不能为null呢?在网上找到了类设计者Lea的原话,主要表达的意思是因为map需要实现containsKey和containsValue方法。这个方法对于null的情况实际上是用get(XX)来实现的,如果为null就不好区分到底是因为不存在还是值就是null。

6.而线程不安全的就是按单线程处理,下面是TreeMap里containsValue的处理,如果为输入为null,并且有个对象值为null就是true了。

总结

四种常用map中线程安全的Map的key和value都不能为null。线程不安全的value都可以为null。TreeMap的key不能为null。

案例4

规范原文 

【强制】多线程并行处理定时任务时,Timer 运行多个 TimeTask 时,只要其中之一没有捕获
抛出的异常,其它任务便会自动终止运行,如果在处理定时任务时使用ScheduledExecutorService 则没有这个问题。 

证明

1.先让Timer 运行多个 TimeTask,让其中之一没有捕获 抛出的异常



这段代码的意思是在10秒内运行两个定时任务,其中一个定时任何每10ms做前后打印。另外一个抛出异常,结果抛出异常后两个都停止了。

2.从Timer源代码可知,本质上多个任务通过一个队列来维护。处理的时候整个过程整体try catch。那么一个出异常整个过程都停止了。

3.再验证使用ScheduledExecutorService的情况, 可看到抛出异常的线程运行了一次之后就停止了,另外一个线程一直继续运行。



4. 从源码可知如果一个工作线程出现了问题会直接从工作队列里移除,不影响其他的。

 

总结

ScheduledExecutorService相比Timer能避免多个任务之间的出现问题时的副作用。

案例5

规范原文

【强制】使用工具类Arrays.asList()把数组转换成集合时,不能使用其修改集合相关的方 法,它的 add/remove/clear 方法会抛出
UnsupportedOperationException 异常。说明:asList 的返回对象是一个 Arrays
内部类,并没有实现集合的修改方法。Arrays.asList 体现的是适 配器模式,只是转换接口,后台的数据仍是数组。

String[] str = new String[] { "yang", "hao" };

List list = Arrays.asList(str);第一种情况:list.add("yangguanbao");
运行时异常。第二种情况:str[0] = "changed"; 也会随之修改,反之亦然。

证明

1.Arrays.asList()把数组转换成集合后添加元素,测试运行,果然抛出异常




跟踪源码可知道虽然asList生成的是ArrayList,但它并不是java.util.ArrayList,而是Arrays里自定义的。这个类不支持这些更新操作。



总结

小心集合类中返回一个子集或者转换类型的操作,可能返回的是内部定义的类,不是我们平时用的类,这些类中对一些操作做了限制。

思考题

下面测试类体现了规范的哪一条?