JVM調優總結(十)-調優方法
轉自:http://pengjiaheng.iteye.com/blog/552456
JVM調優工具
Jconsole,jProfile,VisualVM
Jconsole : jdk自帶,功能簡單,但是可以在系統有一定負荷的情況下使用。對垃圾回收演算法有很詳細的跟蹤。詳細說明參考這裡
JProfiler:商業軟體,需要付費。功能強大。詳細說明參考這裡
VisualVM:JDK自帶,功能強大,與JProfiler類似。推薦。
如何調優
觀察記憶體釋放情況、集合類檢查、物件樹
上面這些調優工具都提供了強大的功能,但是總的來說一般分為以下幾類功能
堆資訊檢視
可檢視堆空間大小分配(年輕代、年老代、持久代分配)
提供即時的垃圾回收功能
垃圾監控(長時間監控回收情況)
檢視堆內類、物件資訊檢視:數量、型別等
物件引用情況檢視
有了堆資訊檢視方面的功能,我們一般可以順利解決以下問題:
--年老代年輕代大小劃分是否合理
--記憶體洩漏
--垃圾回收演算法設定是否合理
執行緒監控
執行緒資訊監控:系統執行緒數量。
執行緒狀態監控:各個執行緒都處在什麼樣的狀態下
Dump執行緒詳細資訊:檢視執行緒內部執行情況
死鎖檢查
熱點分析
CPU熱點:檢查系統哪些方法佔用的大量CPU時間
記憶體熱點:檢查哪些物件在系統中數量最大(一定時間記憶體活物件和銷燬物件一起統計)
這兩個東西對於系統優化很有幫助。我們可以根據找到的熱點,有針對性的進行系統的瓶頸查詢和進行系統優化,而不是漫無目的的進行所有程式碼的優化。
快照
快照是系統執行到某一時刻的一個定格。在我們進行調優的時候,不可能用眼睛去跟蹤所有系統變化,依賴快照功能,我們就可以進行系統兩個不同執行時刻,物件(或類、執行緒等)的不同,以便快速找到問題
舉例說,我要檢查系統進行垃圾回收以後,是否還有該收回的物件被遺漏下來的了。那麼,我可以在進行垃圾回收前後,分別進行一次堆情況的快照,然後對比兩次快照的物件情況。
記憶體洩漏檢查
記憶體洩漏是比較常見的問題,而且解決方法也比較通用,這裡可以重點說一下,而執行緒、熱點方面的問題則是具體問題具體分析了。
記憶體洩漏一般可以理解為系統資源(各方面的資源,堆、棧、執行緒等)在錯誤使用的情況下,導致使用完畢的資源無法回收(或沒有回收),從而導致新的資源分配請求無法完成,引起系統錯誤。
記憶體洩漏對系統危害比較大,因為他可以直接導致系統的崩潰。
需要區別一下,記憶體洩漏和系統超負荷兩者是有區別的,雖然可能導致的最終結果是一樣的。記憶體洩漏是用完的資源沒有回收引起錯誤,而系統超負荷則是系統確實沒有那麼多資源可以分配了(其他的資源都在使用)。
年老代堆空間被佔滿
異常: java.lang.OutOfMemoryError: Java heap space
說明:
這是最典型的記憶體洩漏方式,簡單說就是所有堆空間都被無法回收的垃圾物件佔滿,虛擬機器無法再在分配新空間。
如上圖所示,這是非常典型的記憶體洩漏的垃圾回收情況圖。所有峰值部分都是一次垃圾回收點,所有谷底部分表示是一次垃圾回收後剩餘的記憶體。連線所有谷底的點,可以發現一條由底到高的線,這說明,隨時間的推移,系統的堆空間被不斷佔滿,最終會佔滿整個堆空間。因此可以初步認為系統內部可能有記憶體洩漏。(上面的圖僅供示例,在實際情況下收集資料的時間需要更長,比如幾個小時或者幾天)
解決:
這種方式解決起來也比較容易,一般就是根據垃圾回收前後情況對比,同時根據物件引用情況(常見的集合物件引用)分析,基本都可以找到洩漏點。
持久代被佔滿
異常:java.lang.OutOfMemoryError: PermGen space
說明:
Perm空間被佔滿。無法為新的class分配儲存空間而引發的異常。這個異常以前是沒有的,但是在Java反射大量使用的今天這個異常比較常見了。主要原因就是大量動態反射生成的類不斷被載入,最終導致Perm區被佔滿。
更可怕的是,不同的classLoader即便使用了相同的類,但是都會對其進行載入,相當於同一個東西,如果有N個classLoader那麼他將會被載入N次。因此,某些情況下,這個問題基本視為無解。當然,存在大量classLoader和大量反射類的情況其實也不多。
解決:
1. -XX:MaxPermSize=16m
2. 換用JDK。比如JRocket。
堆疊溢位
異常:java.lang.StackOverflowError
說明:這個就不多說了,一般就是遞迴沒返回,或者迴圈呼叫造成
執行緒堆疊滿
異常:Fatal: Stack size too small
說明:java中一個執行緒的空間大小是有限制的。JDK5.0以後這個值是1M。與這個執行緒相關的資料將會儲存在其中。但是當執行緒空間滿了以後,將會出現上面異常。
解決:增加執行緒棧大小。-Xss2m。但這個配置無法解決根本問題,還要看程式碼部分是否有造成洩漏的部分。
系統記憶體被佔滿
異常:java.lang.OutOfMemoryError: unable to create new native thread
說明:
這個異常是由於作業系統沒有足夠的資源來產生這個執行緒造成的。系統建立執行緒時,除了要在Java堆中分配記憶體外,作業系統本身也需要分配資源來建立執行緒。因此,當執行緒數量大到一定程度以後,堆中或許還有空間,但是作業系統分配不出資源來了,就出現這個異常了。
分配給Java虛擬機器的記憶體愈多,系統剩餘的資源就越少,因此,當系統記憶體固定時,分配給Java虛擬機器的記憶體越多,那麼,系統總共能夠產生的執行緒也就越少,兩者成反比的關係。同時,可以通過修改-Xss來減少分配給單個執行緒的空間,也可以增加系統總共內生產的執行緒數。
解決:
1. 重新設計系統減少執行緒數量。
2. 執行緒數量不能減少的情況下,通過-Xss減小單個執行緒大小。以便能生產更多的執行緒。
相關文章
- JVM調優總結-調優方法JVM
- 【JVM進階之路】十:JVM調優總結JVM
- JVM調優總結(十一)-反思JVM
- JVM調優引數、方法、工具以及案例總結JVM
- JVM調優總結:一些概念JVM
- JVM調優JVM
- JVM調優總結(一)-- 一些概念JVM
- JVM調優總結(二)-一些概念JVM
- JVM調優總結-典型配置舉例1JVM
- JVM調優總結-典型配置舉例2JVM
- jvm 調優總結 -Xms -Xmx -Xmn -XssJVM
- Oracle 調優總結Oracle
- Oracle調優總結Oracle
- 【轉】JVM調優總結(二)-一些概念JVM
- JVM調優總結(七)-典型配置舉例1JVM
- JVM調優總結(八)-典型配置舉例2JVM
- JVM調優策略JVM
- JVM調優總結(三)-基本垃圾回收演算法JVM演算法
- JVM調優總結-分代垃圾回收詳述1JVM
- JVM調優總結-分代垃圾回收詳述2JVM
- JVM調優推薦JVM
- JVM調優淺談JVM
- JVM調優總結(四)-垃圾回收面臨的問題JVM
- JVM調優總結(五)-分代垃圾回收詳述1JVM
- JVM調優總結(六)-分代垃圾回收詳述2JVM
- java jvm 引數 -Xms -Xmx -Xmn -Xss 調優總結JavaJVM
- JVM 調優命令&工具使用JVM
- JVM 引數調優(qbit)JVM
- JVM調優-學習篇JVM
- "簡單"的jvm調優JVM
- “簡單”的jvm調優JVM
- JVM 調優(學習篇)JVM
- JVM常用調優引數JVM
- Java jvm 診斷調優JavaJVM
- JVM 調優示例和配置JVM
- jvm系列(七):jvm調優-工具篇JVM
- MySQL 索引和 SQL 調優總結MySql索引
- ORACLE調優方法Oracle