111 JVM調優總結

棧解決程序的運行問題，即程序如何執行，或者說如何處理數據；

堆解決的是數據存儲的問題，即數據怎麼放、放在哪兒。

    在Java中一個線程就會相應有一個線程棧與之對應，這點很容易理解，由於不一樣的線程執行邏輯有所不一樣，所以須要一個獨立的線程棧。而堆則是全部線程共享的。棧由於是運行單位，所以裏面存儲的信息都是跟當前線程（或程序）相關信息的。包括局部變量、程序運行狀態、方法返回值等等；而堆只負責存儲對象信息。

堆中存的是對象。棧中存的是基本數據類型和堆中對象的引用。一個對象的大小是不可估計的，或者說是能夠動態變化的，可是在棧中，一個對象只對應了一個4btye的引用（堆棧分離的好處：））。

http://pengjiaheng.iteye.com/blog/518623

 

解析Java對象的大小

一個空Object對象的大小是8byte，但須要佔用4byte+8byte，其中4byte是Java棧中保存引用的所須要的空間。8byte則是Java堆中對象的信息。

強引用:就是咱們通常聲明對象是時虛擬機生成的引用，強引用環境下，垃圾回收時須要嚴格判斷當前對象是否被強引用，若是被強引用，則不會被垃圾回收

軟引用:軟引用通常被作爲緩存來使用。與強引用的區別是，軟引用在垃圾回收時，虛擬機會根據當前系統的剩餘內存來決定是否對軟引用進行回收。若是剩餘內存比較緊張，則虛擬機會回收軟引用所引用的空間；若是剩餘內存相對富裕，則不會進行回收。換句話說，虛擬機在發生OutOfMemory時，確定是沒有軟引用存在的。

弱引用:弱引用與軟引用相似，都是做爲緩存來使用。但與軟引用不一樣，弱引用在進行垃圾回收時，是必定會被回收掉的，所以其生命週期只存在於一個垃圾回收週期內。

http://pengjiaheng.iteye.com/blog/519471

 

垃圾回收算法：

 

按照基本回收策略分 

引用計數（Reference Counting）

標記-清除（Mark-Sweep）

複製（Copying）

標記-整理（Mark-Compact）

按分區對待的方式分

增量收集（Incremental Collecting）／分代收集（Generational Collecting）

按系統線程分：串行收集／並行收集／併發收集

http://pengjiaheng.iteye.com/blog/520228

*********  http://pengjiaheng.iteye.com/blog/523230

 

年輕代（Young Generation），又分 一個Eden區，兩個Survivor區(通常而言)。

年老點（Old Generation）

持久代（Permanent Generation）。

GC有兩種類型：

Scavenge GC：當新對象生成，而且在Eden申請空間失敗時，就會觸發Scavenge GC，對Eden區域進行GC，清除非存活對象，而且把尚且存活的對象移動到Survivor區。而後整理Survivor的兩個區。

Full GC：對整個堆進行整理，包括Young、Tenured和Perm。

http://pengjiaheng.iteye.com/blog/524024

 

串行處理器：

--適用狀況：數據量比較小（100M左右）；單處理器下而且對響應時間無要求的應用。 
--缺點：只能用於小型應用

並行處理器：

--適用狀況：「對吞吐量有高要求」，多CPU、對應用響應時間無要求的中、大型應用。舉例：後臺處理、科學計算。 
--缺點：垃圾收集過程當中應用響應時間可能加長

併發處理器：

併發收集器主要減小年老代的暫停時間，他在應用不中止的狀況下使用獨立的垃圾回收線程，跟蹤可達對象。在每一個年老代垃圾回收週期中，在收集初期併發收集器 會對整個應用進行簡短的暫停，在收集中還會再暫停一次。第二次暫停會比第一次稍長，在此過程當中多個線程同時進行垃圾回收工做。

--適用狀況：「對響應時間有高要求」，多CPU、對應用響應時間有較高要求的中、大型應用。舉例：Web服務器/應用服務器、電信交換、集成開發環境。

http://pengjiaheng.iteye.com/blog/528034

 

堆大小設置

32位系統下，通常限制在1.5G~2G；64爲操做系統對內存無限制。

JVM參數設置

http://pengjiaheng.iteye.com/blog/538582

調優總結

年輕代大小選擇

響應時間優先的應用：儘量設大，直到接近系統的最低響應時間限制（根據實際狀況選擇）。在此種狀況下，年輕代收集發生的頻率也是最小的。同時，減小到達年老代的對象。

吞吐量優先的應用：儘量的設置大，可能到達Gbit的程度。由於對響應時間沒有要求，垃圾收集能夠並行進行，通常適合8CPU以上的應用。

年老代大小選擇

響應時間優先的應用：年老代使用併發收集器，因此其大小須要當心設置，通常要考慮併發會話率和會話持續時間等一些參數。若是堆設置小了，能夠會形成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；若是堆大了，則須要較長的收集時間。最優化的方案，通常須要參考如下數據得到：

  1. 併發垃圾收集信息

  2. 持久代併發收集次數

  3. 傳統GC信息

  4. 花在年輕代和年老代回收上的時間比例

減小年輕代和年老代花費的時間，通常會提升應用的效率

吞吐量優先的應用

通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。緣由是，這樣能夠儘量回收掉大部分短時間對象，減小中期的對象，而年老代盡存放長期存活對象。

較小堆引發的碎片問題

由於年老代的併發收集器使用標記、清除算法，因此不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合併，這樣能夠分配給較大的對象。可是，當堆空間較小時，運行一段時間之後，就會出現「碎片」，若是併發收集器找不到足夠的空間，那麼併發收集器將會中止，而後使用傳統的標記、清除方式進行回收。若是出現「碎片」，可能須要進行以下配置：

    1. -XX:+UseCMSCompactAtFullCollection：使用併發收集器時，開啓對年老代的壓縮。

    2. -XX:CMSFullGCsBeforeCompaction=0：上面配置開啓的狀況下，這裏設置多少次Full GC後，對年老代進行壓縮

http://pengjiaheng.iteye.com/blog/545015

 

新一代垃圾回收算法 G1

G1可謂博採衆家之長，力求到達一種完美。他吸收了增量收集優勢，把整個堆劃分爲一個一個等大小的區域（region）。內存的回收和劃分都以region爲單位；同時，他也吸收了CMS的特色，把這個垃圾回收過程分爲幾個階段，分散一個垃圾回收過程；並且，G1也認同分代垃圾回收的思想，認爲不一樣對象的生命週期不一樣，能夠採起不一樣收集方式，所以，它也支持分代的垃圾回收。爲了達到對回收時間的可預計性，G1在掃描了region之後，對其中的活躍對象的大小進行排序，首先會收集那些活躍對象小的region，以便快速回收空間（要複製的活躍對象少了），由於活躍對象小，裏面能夠認爲多數都是垃圾，因此這種方式被稱爲Garbage First（G1）的垃圾回收算法，即：垃圾優先的回收。

http://pengjiaheng.iteye.com/blog/548472

 

調優方法，內存泄漏檢查

http://pengjiaheng.iteye.com/blog/552456

 

http://pengjiaheng.iteye.com/blog/558619

http://pengjiaheng.iteye.com/blog/558620