阿里巴巴Java開發(fā)手冊正確學習姿勢是怎樣的？刷新代碼規(guī)范認知

很多人都知道，阿里巴巴在2017發(fā)布了《阿里巴巴Java開發(fā)手冊》，前后推出了很多個版本，并在后續(xù)推出了與之配套的IDEA插件和書籍。

相信很多Java開發(fā)都或多或少看過這份手冊，這份手冊有7個章節(jié)，覆蓋了編程規(guī)約、異常日志、單元測試、安全規(guī)約、MySQL數(shù)據(jù)庫、工程結(jié)構(gòu)以及設計規(guī)約等方面。

這份規(guī)約可以說是覆蓋了Java開發(fā)的方方面面，如果還有人沒看的話，強烈建議大家好好看看，并且仔細研讀。

手冊中，有那么一些規(guī)則，是比較容易理解的。比如一些變量命名規(guī)范，有另外一些規(guī)則，是不太容易理解的，背后是有很多思考的，有一些則是阿里這么多年來遇到的坑的總結(jié)。

這份手冊在誕生之初，是在阿里內(nèi)部的，那時候就引起了廣泛的討論。最終外界看到的那份手冊，是阿里無數(shù)工程師"挑剔"后的結(jié)果，可以說是凝聚了無數(shù)工程師成功的經(jīng)驗、踩過的坑等。

其實，規(guī)約最大的價值，應該是促使人去思考規(guī)約制定背后的思考。真的去探查規(guī)約背后的原理，這個過程中可以學習到很多東西。

《阿里巴巴Java開發(fā)手冊》還沒有的小伙伴可以來私信我【阿里學習手冊】領取一份

一、為什么阿里巴巴禁止工程師直接使用日志系統(tǒng)(Log4j、Logback)中的 API

在Java生態(tài)體系中，圍繞著日志，有很多成熟的解決方案。關于日志輸出，主要有兩類工具。

一類是日志框架，主要用來進行日志的輸出的，比如輸出到哪個文件，日志格式如何等。另外一類是日志門面，主要一套通用的API，用來屏蔽各個日志框架之間的差異的。

所以，對于Java工程師來說，關于日志工具的使用，最佳實踐就是在應用中使用如Log4j + SLF4J 這樣的組合來進行日志輸出。

這樣做的最大好處，就是業(yè)務層的開發(fā)不需要關心底層日志框架的實現(xiàn)及細節(jié)，在編碼的時候也不需要考慮日后更換框架所帶來的成本。這也是門面模式所帶來的好處。

二、為什么阿里巴巴建議集合初始化時，指定集合容量大??？

HashMap有擴容機制，就是當達到擴容條件時會進行擴容。如果我們沒有設置初始容量大小，隨著元素的不斷增加，HashMap會發(fā)生多次擴容，而HashMap中的擴容機制決定了每次擴容都需要重建hash表，是非常影響性能的。

默認情況下，當我們設置HashMap的初始化容量時，實際上HashMap會采用第一個大于該數(shù)值的2的冪作為初始化容量。

但是，為了最大程度的避免擴容帶來的性能消耗，我們建議可以把默認容量的數(shù)字設置成expectedSize / 0.75F + 1.0F 。在日常開發(fā)中，可以使用

Map<String,String>map=Maps.newHashMapWithExpectedSize(10);

來創(chuàng)建一個HashMap，計算的過程guava會幫我們完成。

但是，以上的操作是一種用內(nèi)存換性能的做法，真正使用的時候，要考慮到內(nèi)存的影響。

三、為什么阿里巴巴禁止在 foreach 循環(huán)里進行元素的 remove/add 操作

我們使用的增強for循環(huán)，其實是Java提供的語法糖，其實現(xiàn)原理是借助Iterator進行元素的遍歷。

但是如果在遍歷過程中，不通過Iterator，而是通過集合類自身的方法對集合進行添加/刪除操作。那么在Iterator進行下一次的遍歷時，經(jīng)檢測發(fā)現(xiàn)有一次集合的修改操作并未通過自身進行，那么可能是發(fā)生了并發(fā)被其他線程執(zhí)行的，這時候就會拋出異常，來提示用戶可能發(fā)生了并發(fā)修改，這就是所謂的fail-fast機制。

當然還是有很多種方法可以解決這類問題的。比如使用普通for循環(huán)、使用Iterator進行元素刪除、使用Stream的filter、使用fail-safe的類等。

四、為什么阿里巴巴禁止把SimpleDateFormat定義為static類型的？

SimpleDateFormat主要可以在String和Date之間做轉(zhuǎn)換，還可以將時間轉(zhuǎn)換成不同時區(qū)輸出。但是在并發(fā)場景中SimpleDateFormat是不能保證線程安全的，需要開發(fā)者自己來保證其安全性。

SimpleDateFormat中的format方法在執(zhí)行過程中，會使用一個成員變量calendar來保存時間。這其實就是問題的關鍵。

如果一個SimpleDateFormat使用的是static定義的。那么這個SimpleDateFormat就是一個共享變量，隨之，SimpleDateFormat中的calendar也就可以被多個線程訪問到。就會有并發(fā)安全問題。

五、為什么阿里巴巴不建議在for循環(huán)中使用"+"進行字符串拼接

使用+拼接字符串，其實只是Java提供的一個語法糖，通過反編譯，我們可以發(fā)現(xiàn)，其實字符串常量使用"+"在拼接過程中，是將String轉(zhuǎn)成了StringBuilder后，使用其append方法進行處理的。

如果在一個for循環(huán)中，使用"+"對字符串進行拼接，那么每一次都會重新new一個StringBuilder，然后再把String轉(zhuǎn)成StringBuilder，再進行append。

而頻繁的新建對象當然要耗費很多時間了，不僅僅會耗費時間，頻繁的創(chuàng)建對象，還會造成內(nèi)存資源的浪費。

六、為什么阿里巴巴要求程序員謹慎修改serialVersionUID 字段的值

序列化提供了一種方案，可以讓你在即使JVM停機的情況下也能把對象保存下來的方案。就像我們平時用的U盤一樣。把Java對象序列化成可存儲或傳輸?shù)男问剑ㄈ缍M制流），比如保存在文件中。這樣，當再次需要這個對象的時候，從文件中讀取出二進制流，再從二進制流中反序列化出對象。

虛擬機是否允許反序列化，不僅取決于類路徑和功能代碼是否一致，一個非常重要的一點是兩個類的序列化 ID 是否一致，這個所謂的序列化ID，就是我們在代碼中定義的serialVersionUID。

在進行反序列化時，JVM會把傳來的字節(jié)流中的serialVersionUID與本地相應實體類的serialVersionUID進行比較，如果相同就認為是一致的，可以進行反序列化，否則就會出現(xiàn)序列化版本不一致的異常，即是InvalidCastException。

七、為什么阿里巴巴要求謹慎使用ArrayList中的subList方法

subList是List接口中定義的一個方法，該方法主要用于返回一個集合中的一段、可以理解為截取一個集合中的部分元素，他的返回值也是一個List。

但是subList 返回的并不是一個全新的List，而是一個視圖。就是說，SubList并沒有重新創(chuàng)建一個List，而是直接引用了原有的List（返回了父類的視圖），只是指定了一下他要使用的元素的范圍而已（從fromIndex（包含），到toIndex（不包含））。

所以，首先我們無法將subList方法得到的集合直接轉(zhuǎn)換成ArrayList。因為SubList只是ArrayList的內(nèi)部類，他們之間并沒有繼承關系，故無法直接進行強制類型轉(zhuǎn)換。

另外，視圖和原List的修改還需要注意幾點，尤其是他們之間的相互影響：

• 1、對父(sourceList)子(subList)List做的非結(jié)構(gòu)性修改（non-structural changes），都會影響到彼此。

• 2、對子List做結(jié)構(gòu)性修改，操作同樣會反映到父List上。

• 3、對父List做結(jié)構(gòu)性修改，會拋出異常ConcurrentModificationException。

所以，阿里巴巴Java開發(fā)手冊中有另外一條規(guī)定：

八、為什么阿里巴巴建議開發(fā)者謹慎使用繼承？

作為一門面向?qū)ο箝_發(fā)的語言，代碼復用是Java引人注意的功能之一。Java代碼的復用有繼承，組合以及代理三種具體的表現(xiàn)形式。

繼承，在寫代碼的時候就要指明具體繼承哪個類，所以，類的繼承關系是在編譯期就確定的。并且從基類繼承來的實現(xiàn)是無法在運行期動態(tài)改變的，因此降低了應用的靈活性。

組合，在寫代碼的時候可以采用面向接口編程。所以，類的組合關系一般在運行期確定。另外，代碼復用方式上也有一定區(qū)別：

• 繼承結(jié)構(gòu)中，父類的內(nèi)部細節(jié)對于子類是可見的。所以我們通常也可以說通過繼承的代碼復用是一種白盒式代碼復用。如果基類的實現(xiàn)發(fā)生改變，那么派生類的實現(xiàn)也將隨之改變。這樣就導致了子類行為的不可預知性。

• 組合是通過對現(xiàn)有的對象進行拼裝（組合）產(chǎn)生新的、更復雜的功能。因為在對象之間，各自的內(nèi)部細節(jié)是不可見的，所以我們也說通過組合的代碼復用是黑盒式代碼復用。因為組合中一般都定義一個類型，所以在編譯期根本不知道具體會調(diào)用哪個實現(xiàn)類的方法。

還有，Java中不支持多繼承，而組合是沒有限制的。就像一個人只能有一個父親，但是他可以有很很多輛車。

九、為什么阿里巴巴禁止開發(fā)人員使用isSuccess作為變量名

?fastjson和jackson在把對象序列化成json字符串的時候，是通過反射遍歷出該類中的所有g(shù)etter方法，得到getHollis和isSuccess，然后根據(jù)JavaBeans規(guī)則，他會認為這是兩個屬性hollis和success的值。

但是Gson并不是這么做的，他是通過反射遍歷該類中的所有屬性，并把其值序列化成json

可以看到，由于不同的序列化工具，在進行序列化的時候使用到的策略是不一樣的，所以，對于同一個類的同一個對象的序列化結(jié)果可能是不同的。

如果對于同一個對象，我使用fastjson進行序列化，再使用Gson反序列化，并且恰巧這個對象中某個屬性是以isXXX命名的，那么就會產(chǎn)生問題。

作為開發(fā)者，我們應該想辦法盡量避免這種問題的發(fā)生，對于POJO的設計者來說，只需要做簡單的一件事就可以解決這個問題了，那就是把isSuccess改為success。

十、為什么阿里巴巴不讓使用 COUNT(列名)或 COUNT(常量)來替代 COUNT(*)呢

因為COUNT(*)是SQL92定義的標準統(tǒng)計行數(shù)的語法，所以MySQL對他進行了很多優(yōu)化，MyISAM中會直接把表的總行數(shù)單獨記錄下來供COUNT(*)查詢，而InnoDB則會在掃表的時候選擇最小的索引來降低成本。當然，這些優(yōu)化的前提都是沒有進行where和group的條件查詢。

在InnoDB中COUNT(*)和COUNT(1)實現(xiàn)上沒有區(qū)別，而且效率一樣，但是COUNT(字段)需要進行字段的非NULL判斷，所以效率會低一些。

因為COUNT(*)是SQL92定義的標準統(tǒng)計行數(shù)的語法，并且效率高，所以請直接使用COUNT(*)查詢表的行數(shù)！

十一、為什么阿里巴巴不允許使用Executors創(chuàng)建線程池？

Java中的BlockingQueue主要有兩種實現(xiàn)，分別是ArrayBlockingQueue 和 LinkedBlockingQueue。

ArrayBlockingQueue是一個用數(shù)組實現(xiàn)的有界阻塞隊列，必須設置容量。

LinkedBlockingQueue是一個用鏈表實現(xiàn)的有界阻塞隊列，容量可以選擇進行設置，不設置的話，將是一個無邊界的阻塞隊列，最大長度為Integer.MAX_VALUE。

這里的問題就出在：不設置的話，將是一個無邊界的阻塞隊列，最大長度為Integer.MAX_VALUE。也就是說，如果我們不設置LinkedBlockingQueue的容量的話，其默認容量將會是Integer.MAX_VALUE。

而newFixedThreadPool中創(chuàng)建LinkedBlockingQueue時，并未指定容量。此時，LinkedBlockingQueue就是一個無邊界隊列，對于一個無邊界隊列來說，是可以不斷的向隊列中加入任務的，這種情況下就有可能因為任務過多而導致內(nèi)存溢出問題。

上面提到的問題主要體現(xiàn)在newFixedThreadPool和newSingleThreadExecutor兩個工廠方法上，并不是說newCachedThreadPool和newScheduledThreadPool這兩個方法就安全了，這兩種方式創(chuàng)建的最大線程數(shù)可能是Integer.MAX_VALUE，而創(chuàng)建這么多線程，必然就有可能導致OOM。

總結(jié)

以上，就是我之前一段時間通過學習《手冊》中的部分規(guī)則之后，自己總結(jié)的一些內(nèi)容，這個過程中自己也學習到很多東西。

所以想說，這才是學習《手冊》的正確姿勢，這樣才能最大程度的成長！

這個系列還在繼續(xù)更新，后面還會會逐步完善。歡迎關注與交流。

《阿里巴巴Java開發(fā)手冊》還沒有的小伙伴可以來加VX：haolagui521備注“51CTO”領取一份