Java中常犯的錯誤有哪些

本篇內容介紹了“Java中常犯的錯誤有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1. 忽略訪問修飾符

雖然有點莫名其妙，但候選者真的經常忘記Java中protected訪問修飾符的作用域。也許是因為面試過程中過于焦慮和緊張，他們通常只能答出其一：

• 可從子類訪問protected字段、方法和構造函數。

• 可從同一包中訪問protected字段、方法和構造函數。

此外，包的作用域能幫助許多開發人員編寫自己的測試：可以從測試路徑訪問受保護的方法。所以忘記這個屬性等同于在面試中表明自己從來沒有編寫過測試!

2. 字符串連接

如果使用大量字符串或大型字符串，則可能會在連接過程中浪費大量內存。

上述示例是創建一些StringBuilder和String對象：準確來說，是10.000.000個StringBuilder和10.000.001個String。

解釋：

先退一步，看看發生了什么。

當使用+運算符進行字符串連接時，將創建一個中間對象，該對象存儲連接的結果后，將結果賦值給目標對象。

在如上示例中，一共創建了3個對象：2個用于文本，1個用于連接，即第一個字符串result的副本加上第二個字符串“world!”。因為String是不可變的，所以這種字符串連接是可以實現的。

但是編譯器是足夠智能的，可以將代碼轉化為以下內容(Java9+不適用，因為它使用StringContactFacotry，但結果非常相似)：

此優化刪除了中間連接對象，內存被2個字符串文本和1個StringBuilder占用。總體而言，字符串對象的數量從O(n²)下降到O(n)。

回到第一個示例，編譯器對代碼的優化如下：

編譯器只是優化了內部連接，但這會創建很多StringBuilder和String對象!連接字符串的正確方法如下，只需一個StringBuilder和一個String。

3. 沒有使用equals()

如果你正在使用==(比較運算符)而不是調用equals()函數，那么你需要改變這個習慣，結果可能會令人大吃一驚。

解釋：

當想要比較兩個String以及其他任何對象時，不要使用==。==只比較兩個操作數的對象引用(內存地址比較)而非內容。

在上面的例子中，字符串不能啟動字符串駐留機制：它的內存地址與x不同。

4. 返回null

筆者已經發現了很多次這樣的方法：

返回null的問題是強行讓調用方對結果進行空檢查;在這種情況下，如果沒有項，調用方就會返回空列表。

開發人員總是希望返回一個異常或特殊對象(如空列表)，否則使用代碼的應用程序將受到NullPointerException的影響。

5. 密碼為字符串

將用戶提供的密碼存儲在字符串對象中是一個安全問題，字符串容易受到內存攻擊。

應該使用char[]，就如同JPasswordField和Password4j正在做的那樣。但如果討論的是Web應用程序，大多數Web容器都將HttpServletRequest對象中的純文本密碼作為String傳遞，所以開發人員幾乎對此無能為力。

解釋：

字符串由Java虛擬機(JVM)(駐留)緩存并存儲在PermGen空間(Java8之前)或堆空間中。在這兩種情況下，只有在垃圾回收發生后才刪除緩存值：這意味著無法得知特定值何時會從字符串池中刪除，因為垃圾收集器的行為是不確定的。

另一個問題是，String是不可變的，因此不能清除它們。然而char[]是可變的，并且可以在處理后刪除(例如用0替換每個元素)。通過這個簡單的技巧，攻擊者只能在內存中找到全為零的數組而不是純文本密碼。

6. 傳遞null

傳遞null意味著，理所當然地認為調用的代碼可以管理null。如果不能，那么應用程序肯定會拋出NullPointerException。

另外，顯式傳遞null會使代碼越來越混亂。下面是一個典型實例：

調用init()時，沒有可用的User對象。那么，如果一個User都沒有，為什么要調用一個對User進行操作的函數呢?如果需要grantAccessToUser()中的邏輯，就應該從其他的函數中提取并使用，而非傳遞null。

7. Heavy methods

以下示例可能會導致系統性能損失：

Pattern.compile()是一個資源占用極高的函數，不應在每次檢查字符串是否與同一模式匹配時都調用它。

解釋：

Pattern.compile() 將模式預編譯，以便使用更快的內存表示。與單個匹配相比，此操作需要極強的計算能力。

增加性能的經典方法是在靜態字段中緩存Pattern對象，如下所示：

每次使用同一個資源占用極高的無狀態對象時，都應該使用這個解決方案。

8. 迭代時處理集合

這段代碼將拋出ConcurrentModificationException。

解釋：

在迭代時從列表中刪除某個項目，列表迭代器會運行不良，例如跳過元素、重復元素、索引數組末尾等。這就是許多集合更容易拋出oncurrentModificationException的原因。

使用底層數組迭代器：

9. 使用“返回碼”而不是拋出異常

在某種意義上，開發人員認為異常是不祥的，因此他們傾向于編寫返回奇怪值的函數，如-1或“C_ERR”。

這是一個值得創建自定義Exception的典型情況。該示例可以改寫如下：

正如所見，代碼的可讀性和可維護性大大提高。調用者只需讀取DeviceStartException的內容，而不必處理每個返回碼。

10. 使用StringBuffer

由于StringBuffer的同步特性，此示例會產生大量內存占用。在更復雜的環境中，讀取器可能會錯認為某些不必要的同步是必要的。

如果項目中包含StringBuffer，可能是因為某些遺留API(即Java5之前)需要它，而很少是因為代碼試圖在并發環境中追加String。改用StringBuilder：在Java5時引入，其所有操作是不同步的。

這只是筆者在面試和活動項目中看到的部分錯誤，還沒有提到面向對象編程(OOP)的陷阱、設計模式、過度設計、內存泄漏等缺陷

如果你有這些問題，那么是時候改變編碼風格。這并不難，避免這些陷阱能增強開發人員的經驗，并且使人主動為下一次面試做更多的準備。

多使用像SonarQube這樣的靜態代碼分析器，它能指出實際錯誤，突顯潛在錯誤。

“Java中常犯的錯誤有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！