[[381764]]

本文轉載自微信公眾號「蘇三說技術」，作者因為熱愛所以堅持ing。轉載本文請聯系蘇三說技術公眾號。  

 前言

最近我們通過sonar靜態代碼檢測，同時配合人工代碼review，發現了項目中很多代碼問題。除了常規的bug和安全漏洞之外，還有幾處方法用法錯誤，引起了我極大的興趣。我為什么會對這幾個方法這么感興趣呢?因為它們極具迷惑性，可能會讓我們傻傻分不清楚。

1. replace會替換所有字符?

很多時候我們在使用字符串時，想把字符串比如：ATYSDFA*Y中的字符A替換成字符B，第一個想到的可能是使用replace方法。

如果想把所有的A都替換成B，很顯然可以用replaceAll方法，因為非常直觀，光從方法名就能猜出它的用途。

那么問題來了：replace方法會替換所有匹配字符嗎?

jdk的官方給出了答案。

 

該方法會替換每一個匹配的字符串。

既然replace和replaceAll都能替換所有匹配字符，那么他們有啥區別呢?

1.replace有兩個重載的方法。

其中一個方法的參數：char oldChar 和 char newChar，支持字符的替換。

source.replace('A', 'B') 

另一個方法的參數是：CharSequence target 和 CharSequence replacement，支持字符串的替換。

source.replace("A", "B") 

2.replaceAll方法的參數是：String regex 和 String replacement，基于正則表達式的替換。普通字符串替換：

source.replaceAll("A", "B") 

正則表達替換(將*替換成C)：

source.replaceAll("\\*", "C") 

順便說一下，將*替換成C使用replace方法也可以實現：

source.replace("*", "C") 

無需對特殊字符進行轉義。

不過，千萬注意，切勿使用如下寫法：

source.replace("\\*", "C") 

這種寫法會導致字符串無法替換。

還有個小問題，如果我只想替換第一個匹配的字符串該怎么辦?

這時可以使用replaceFirst方法：

source.replaceFirst("A", "B") 

2. Integer不能用==判斷相等?

不知道你在項目中有沒有見過，有些同事對Integer類型的兩個參數使用==比較是否相等?

反正我見過的，那么這種用法對嗎?

我的回答是看具體場景，不能說一定對，或不對。

有些狀態字段，比如：orderStatus有：-1(未下單)，0(已下單)，1(已支付)，2(已完成)，3(取消)，5種狀態。

這時如果用==判斷是否相等：

Integer orderStatus1 = new Integer(1); 
 Integer orderStatus2 = new Integer(1); 
 System.out.println(orderStatus1 == orderStatus2); 

返回結果會是true嗎?

答案：是false。

有些同學可能會反駁，Integer中不是有范圍是：-128-127的緩存嗎?

為什么是false?

先看看Integer的構造方法：

它其實并沒有用到緩存。

 

那么緩存是在哪里用的?

答案在valueOf方法中：

 

如果上面的判斷改成這樣：

String orderStatus1 = new String("1"); 
String orderStatus2 = new String("1"); 
System.out.println(Integer.valueOf(orderStatus1) == Integer.valueOf(orderStatus2)); 

返回結果會是true嗎?

答案：還真是true。

我們要養成良好編碼習慣，盡量少用==判斷兩個Integer類型數據是否相等，只有在上述非常特殊的場景下才相等。

而應該改成使用equals方法判斷：

Integer orderStatus1 = new Integer(1); 
Integer orderStatus2 = new Integer(1); 
System.out.println(orderStatus1.equals(orderStatus2)); 

3. 使用BigDecimal就不丟失精度?

通常我們會把一些小數類型的字段(比如：金額)，定義成BigDecimal，而不是Double，避免丟失精度問題。

使用Double時可能會有這種場景：

double amount1 = 0.02; 
double amount2 = 0.03; 
System.out.println(amount2 - amount1); 

正常情況下預計amount2 - amount1應該等于0.01

但是執行結果，卻為：

0.009999999999999998 

實際結果小于預計結果。

Double類型的兩個參數相減會轉換成二進制，因為Double有效位數為16位這就會出現存儲小數位數不夠的情況，這種情況下就會出現誤差。

常識告訴我們使用BigDecimal能避免丟失精度。

但是使用BigDecimal能避免丟失精度嗎?

答案是否定的。

為什么?

BigDecimal amount1 = new BigDecimal(0.02); 
BigDecimal amount2 = new BigDecimal(0.03); 
System.out.println(amount2.subtract(amount1)); 

這個例子中定義了兩個BigDecimal類型參數，使用構造函數初始化數據，然后打印兩個參數相減后的值。

結果：

0.0099999999999999984734433411404097569175064563751220703125 

不科學呀，為啥還是丟失精度了?

jdk中BigDecimal的構造方法上有這樣一段描述：

 

大致的意思是此構造函數的結果可能不可預測，可能會出現創建時為0.1，但實際是0.1000000000000000055511151231257827021181583404541015625的情況。

由此可見，使用BigDecimal構造函數初始化對象，也會丟失精度。

那么，如何才能不丟失精度呢?

BigDecimal amount1 = new BigDecimal(Double.toString(0.02)); 
BigDecimal amount2 = new BigDecimal(Double.toString(0.03)); 
System.out.println(amount2.subtract(amount1)); 

使用Double.toString方法對double類型的小數進行轉換，這樣能保證精度不丟失。

其實，還有更好的辦法：

BigDecimal amount1 = BigDecimal.valueOf(0.02); 
BigDecimal amount2 = BigDecimal.valueOf(0.03); 
System.out.println(amount2.subtract(amount1)); 

使用BigDecimal.valueOf方法初始化BigDecimal類型參數，也能保證精度不丟失。在新版的阿里巴巴開發手冊中，也推薦使用這種方式創建BigDecimal參數。

4. 字符串拼接不能用String?

String類型的字符串被稱為不可變序列，也就是說該對象的數據被定義好后就不能修改了，如果要修改則需要創建新對象。

String a = "123"; 
String b = "456"; 
String c = a + b; 
System.out.println(c); 

在大量字符串拼接的場景中，如果對象被定義成String類型，會產生很多無用的中間對象，浪費內存空間，效率低。

這時，我們可以用更高效的可變字符序列：StringBuilder和StringBuffer，來定義對象。

那么，StringBuilder和StringBuffer有啥區別?

StringBuffer對各主要方法加了synchronized關鍵字，而StringBuilder沒有。所以，StringBuffer是線程安全的，而StringBuilder不是。

其實，我們很少會出現需要在多線程下拼接字符串的場景，所以StringBuffer實際上用得非常少。一般情況下，拼接字符串時我們推薦使用StringBuilder，通過它的append方法追加字符串，它只會產生一個對象，而且沒有加鎖，效率較高。

String a = "123"; 
String b = "456"; 
StringBuilder c = new StringBuilder(); 
c.append(a).append(b); 
System.out.println(c); 

接下來，關鍵問題來了：字符串拼接時使用String類型的對象，效率一定比StringBuilder類型的對象低?

答案是否定的。

為什么?

使用javap -c StringTest命令反編譯：

 

從圖中能看出定義了兩個String類型的參數，又定義了一個StringBuilder類的參數，然后兩次使用append方法追加字符串。

如果代碼是這樣的：

String a = "123"; 
String b = "789"; 
String c = a + b; 
System.out.println(c); 

使用javap -c StringTest命令反編譯的結果會怎樣呢?

 

我們會驚訝的發現，同樣定義了兩個String類型的參數，又定義了一個StringBuilder類的參數，然后兩次使用append方法追加字符串。跟上面的結果是一樣的。

其實從jdk5開始，java就對String類型的字符串的+操作做了優化，該操作編譯成字節碼文件后會被優化為StringBuilder的append操作。

5. isEmpty和isBlank的區別

我們在對字符串進行操作的時候，需要經常判斷該字符串是否為空。如果沒有借助任何工具，我們一般是這樣判斷的：

if (null != source && !"".equals(source)) { 
    System.out.println("not empty"); 
} 

但是如果每次都這樣判斷，會有些麻煩，所以很多jar包都對字符串判空做了封裝。目前市面上主流的工具有：

• spring中的StringUtils
• jdbc中的StringUtils
• apache common3中的StringUtils

不過spring中的StringUtils類只有isEmpty方法，沒有isNotEmpty方法。

jdbc中的StringUtils類只有isNullOrEmpty方法，也沒有isNotNullOrEmpty方法。

所以在這里強烈推薦一下apache common3中的StringUtils類，它里面包含了很多實用的判空方法：isEmpty、isBlank、isNotEmpty、isNotBlank等，還有其他字符串處理方法。

問題來了，isEmpty和isBlank有啥區別?

使用isEmpty方法判斷：

StringUtils.isNotEmpty(null)      = true 
 StringUtils.isNotEmpty("")        = true 
 StringUtils.isNotEmpty(" ")       = false 
 StringUtils.isNotEmpty("bob")     = false 
 StringUtils.isNotEmpty("  bob  ") = false 

使用isBlank方法判斷：

StringUtils.isBlank(null)      = true 
StringUtils.isBlank("")        = true 
StringUtils.isBlank(" ")       = true 
StringUtils.isBlank("bob")     = false 
StringUtils.isBlank("  bob  ") = false 

兩個方法關鍵的區別在于這種" "空字符串的情況，isNotEmpty返回false，而isBlank返回true。

6. mapper查詢結果要判空?

有次代碼review的時候，當時有個同事說這里的判空可以去掉，讓我記憶猶新：

List<User> list = userMapper.query(search); 
if(CollectionUtils.isNotEmpty(list)) { 
    List<Long> idList = list.stream().map(User::getId).collect(Collectors.toList()); 
} 

因為按常理，一般調用方法查詢出來的集合，可能為null，需要判空的。但是，這里比較特殊，我查了一下mybatis的源碼，這個判空的代碼還真的可以去掉。

怎么回事呢?

mybatis的查詢方法最終都會調到DefaultResultSetHandler類的handleResultSets方法：

該方法會返回一個multipleResultsList集合對象，在方法剛開始就new出來了，肯定是不會為空。

 

所以，如果你在項目的代碼中看到有人直接使用查詢出的結果，不判空也不要驚訝：

List<User> list = userMapper.query(search); 
List<Long> idList = list.stream().map(User::getId).collect(Collectors.toList()); 

因為mapper底層已經處理過的，它不會出現空指針異常。

7. indexOf方法的正確用法

有次在review別人代碼的時候，看到有個地方indexOf使用了這種寫法，讓我印象比較深刻：

String source = "#ATYSDFA*Y"; 
if(source.indexOf("#") > 0) { 
    System.out.println("do something"); 
} 

你們說這段代碼會打印出do something嗎?

答案是否定的。

為什么呢?

jdk官方說了不存在的情況會返回-1

 

indexOf方法返回的是指定元素在字符串中的位置，從0開始。而上面的例子#在字符串的第一個位置，所以調用indexOf方法后的值其實是0。所以，條件是false，不會打印do something。

 

 

如果想通過indexOf判斷某個元素是否存在時，要用：

if(source.indexOf("#") > -1) { 
    System.out.println("do something"); 
} 

其實，還有更優雅的contains方法：

if(source.contains("#")) { 
   System.out.println("do something"); 
}