一些常見異常解決方案彙總

1. 空指標

1) 原因：引用了空物件

2) 解決方案：

① 對於別人介面的返回物件要做非空判斷，因為我們不清楚獲得的物件會不會為空，

對於map，可以採用getorelse來代替get；對於集合判斷是否為空，可用isempty判斷。判斷乙個字串是否為空，用option來判斷，例如：val sqlresult: list[list[string]] = sql(sql).query.value.map(x => x.map(y => if (option(y).isdefined) y else "--"))。

② 對於自己建立的物件，要留心物件進行哪些操作，中間會不會造成物件為空，如果可能加非空判斷。

③ 對於前台的領域物件要非常的留心，因為這些物件是框架建立的，假如我沒有在前台的文字框內輸入值，雖然提交時後台獲得的

是空串，但發生nullpointerexception的概率很高。

2. 陣列下標越界

1) 原因：在

引用陣列元素時，使用的下標超過了該陣列下標的應有範圍。

2) 解決方案：

因為編譯器不會自動檢測你的陣列下標是否越界，而是把這個任務交給了

程式設計師自己，所以我們在寫程式，引用陣列元素時，一定注意不要讓陣列的下標越界。

還有，初學者一定不能忘了陣列的下標是從0開始的，不是常識中的從1開始。

3. 記憶體溢位

1) 原因：

①　記憶體中載入的資料量過於龐大，如一次從資料庫取出過多資料；

②　集合類中有對物件的引用，使用完後未清空，使得jvm不能**； ③　

**中存在死迴圈或迴圈產生過多重複的物件實體；

④　使用的第三方軟體中的bug；啟動引數記憶體值設定的過小；

2) 解決方案：

①　修改jvm啟動引數，直接增加記憶體。(-xms，-xmx引數一定不要忘記加。) ②　

檢查錯誤日誌，檢視「outofmemory」錯誤前是否有其它異常或錯誤。 ③　

對**進行走查和分析，找出可能發生記憶體溢位的位置。

重點檢查一下幾項

a. 檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢盡量採用分頁的方式查詢。

b. 檢查**中是否有死迴圈或遞迴呼叫。

c. 檢查是否有大迴圈重複產生新物件實體。

d. 檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢盡量採用分頁的方式查詢。

e. 檢查list、map等集合物件是否有使用完後，未清除的問題。list、map等集合物件會始終存有對物件的引用，使得這些物件不能被gc**。 ④

使用記憶體檢視工具動態檢視記憶體使用情況。

例如：jconsole 以gui的方式更直觀化呈現jvm程序的實時情況, 比如記憶體占用, 執行緒執**況等;

在jdk_home/bin目錄下執行 jconsole.exe 開啟圖形化介面, 然後選擇要檢查的程序就可以檢視所有相關jvm情況的資訊了.

一些常見異常解決方案彙總

Pandas一些常見場景的解決方案

異常解決方案

過擬合一些解決方案

一些常見異常解決方案彙總

Pandas一些常見場景的解決方案

異常解決方案

過擬合一些解決方案

相關推薦