您好,登錄后才能下訂單哦!
本篇內容主要講解“Java中那些分不清的小細節有哪些”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Java中那些分不清的小細節有哪些”吧!
前言
最近我們通過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"); }
到此,相信大家對“Java中那些分不清的小細節有哪些”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。