阿里巴巴編碼規範(Java)證明

程式設計一生發表於2020-05-28

背景

阿里雲上有個阿里巴巴編碼規範認證,我估算一下時間成本很低,多個認證也沒什麼壞處,就花了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裡自定義的。這個類不支援這些更新操作。

總結

小心集合類中返回一個子集或者轉換型別的操作,可能返回的是內部定義的類,不是我們平時用的類,這些類中對一些操作做了限制。

思考題

下面測試類體現了規範的哪一條?

 

相關文章