2. 程式人生 > >JVM內存調優

JVM內存調優

阿新 • • 發佈：2018-04-30
move tof 現象 AC sep 臨時 開啟 xmx per

JVM性能調優有很多設置,這個參考JVM參數即可.

主要調優的目的:

  1. 控制GC的行為.GC是一個後臺處理,但是它也是會消耗系統性能的,因此經常會根據系統運行的程序的特性來更改GC行為

  2. 控制JVM堆棧大小.一般來說,JVM在內存分配上不需要你修改,(舉例)但是當你的程序新生代對象在某個時間段產生的比較多的時候,就需要控制新生代的堆大小.同時,還要需要控制總的JVM大小避免內存溢出

  3. 控制JVM線程的內存分配.如果是多線程程序,產生線程和線程運行所消耗的內存也是可以控制的,需要通過一定時間的觀測後,配置最優結果

最近因項目存在內存泄漏，故進行大規模的JVM性能調優 ， 現把經驗做一記錄。

一、JVM內存模型及垃圾收集算法

1.根據Java虛擬機規範，JVM將內存劃分為：

  • New（年輕代）
  • Tenured（年老代）
  • 永久代（Perm）

其中New和Tenured屬於堆內存，堆內存會從JVM啟動參數（-Xmx:3G）指定的內存中分配，Perm不屬於堆內存，有虛擬機直接分配，但可以通過-XX:PermSize -XX:MaxPermSize 等參數調整其大小。

  • 年輕代（New）：年輕代用來存放JVM剛分配的Java對象
  • 年老代（Tenured)：年輕代中經過垃圾回收沒有回收掉的對象將被Copy到年老代
  • 永久代（Perm）：永久代存放Class、Method元信息，其大小跟項目的規模、類、方法的量有關，一般設置為128M就足夠，設置原則是預留30%的空間。

New又分為幾個部分：

  • Eden：Eden用來存放JVM剛分配的對象
  • Survivor1
  • Survivro2：兩個Survivor空間一樣大，當Eden中的對象經過垃圾回收沒有被回收掉時，會在兩個Survivor之間來回Copy，當滿足某個條件，比如Copy次數，就會被Copy到Tenured。顯然，Survivor只是增加了對象在年輕代中的逗留時間，增加了被垃圾回收的可能性。

2.垃圾回收算法

垃圾回收算法可以分為三類，都基於標記-清除（復制）算法：

  • Serial算法（單線程）
  • 並行算法
  • 並發算法

JVM會根據機器的硬件配置對每個內存代選擇適合的回收算法，比如，如果機器多於1個核，會對年輕代選擇並行算法，關於選擇細節請參考JVM調優文檔。

稍微解釋下的是，並行算法是用多線程進行垃圾回收，回收期間會暫停程序的執行，而並發算法，也是多線程回收，但期間不停止應用執行。所以，並發算法適用於交互性高的一些程序。經過觀察，並發算法會減少年輕代的大小，其實就是使用了一個大的年老代，這反過來跟並行算法相比吞吐量相對較低。

還有一個問題是，垃圾回收動作何時執行？

  • 當年輕代內存滿時，會引發一次普通GC，該GC僅回收年輕代。需要強調的時，年輕代滿是指Eden代滿，Survivor滿不會引發GC
  • 當年老代滿時會引發Full GC，Full GC將會同時回收年輕代、年老代
  • 當永久代滿時也會引發Full GC，會導致Class、Method元信息的卸載

另一個問題是，何時會拋出OutOfMemoryException，並不是內存被耗空的時候才拋出

  • JVM98%的時間都花費在內存回收
  • 每次回收的內存小於2%

滿足這兩個條件將觸發OutOfMemoryException，這將會留給系統一個微小的間隙以做一些Down之前的操作，比如手動打印Heap Dump。

二、內存泄漏及解決方法

1.系統崩潰前的一些現象：

  • 每次垃圾回收的時間越來越長，由之前的10ms延長到50ms左右，FullGC的時間也有之前的0.5s延長到4、5s
  • FullGC的次數越來越多，最頻繁時隔不到1分鐘就進行一次FullGC
  • 年老代的內存越來越大並且每次FullGC後年老代沒有內存被釋放

之後系統會無法響應新的請求，逐漸到達OutOfMemoryError的臨界值。

2.生成堆的dump文件

通過JMX的MBean生成當前的Heap信息，大小為一個3G（整個堆的大小）的hprof文件，如果沒有啟動JMX可以通過Java的jmap命令來生成該文件。

3.分析dump文件

下面要考慮的是如何打開這個3G的堆信息文件，顯然一般的Window系統沒有這麽大的內存，必須借助高配置的Linux。當然我們可以借助X-Window把Linux上的圖形導入到Window。我們考慮用下面幾種工具打開該文件：

  1. Visual VM
  2. IBM HeapAnalyzer
  3. JDK 自帶的Hprof工具

使用這些工具時為了確保加載速度，建議設置最大內存為6G。使用後發現，這些工具都無法直觀地觀察到內存泄漏，Visual VM雖能觀察到對象大小，但看不到調用堆棧；HeapAnalyzer雖然能看到調用堆棧，卻無法正確打開一個3G的文件。因此，我們又選用了Eclipse專門的靜態內存分析工具：Mat。

4.分析內存泄漏

通過Mat我們能清楚地看到，哪些對象被懷疑為內存泄漏，哪些對象占的空間最大及對象的調用關系。針對本案，在ThreadLocal中有很多的JbpmContext實例，經過調查是JBPM的Context沒有關閉所致。

另，通過Mat或JMX我們還可以分析線程狀態，可以觀察到線程被阻塞在哪個對象上，從而判斷系統的瓶頸。

5.回歸問題

Q：為什麽崩潰前垃圾回收的時間越來越長？

A:根據內存模型和垃圾回收算法，垃圾回收分兩部分：內存標記、清除（復制），標記部分只要內存大小固定時間是不變的，變的是復制部分，因為每次垃圾回收都有一些回收不掉的內存，所以增加了復制量，導致時間延長。所以，垃圾回收的時間也可以作為判斷內存泄漏的依據

Q：為什麽Full GC的次數越來越多？

A：因此內存的積累，逐漸耗盡了年老代的內存，導致新對象分配沒有更多的空間，從而導致頻繁的垃圾回收

Q:為什麽年老代占用的內存越來越大？

A:因為年輕代的內存無法被回收，越來越多地被Copy到年老代

三、性能調優

除了上述內存泄漏外，我們還發現CPU長期不足3%，系統吞吐量不夠，針對8core×16G、64bit的Linux服務器來說，是嚴重的資源浪費。

在CPU負載不足的同時，偶爾會有用戶反映請求的時間過長，我們意識到必須對程序及JVM進行調優。從以下幾個方面進行：

  • 線程池：解決用戶響應時間長的問題
  • 連接池
  • JVM啟動參數：調整各代的內存比例和垃圾回收算法，提高吞吐量
  • 程序算法：改進程序邏輯算法提高性能

1.Java線程池（java.util.concurrent.ThreadPoolExecutor）

大多數JVM6上的應用采用的線程池都是JDK自帶的線程池，之所以把成熟的Java線程池進行羅嗦說明，是因為該線程池的行為與我們想象的有點出入。Java線程池有幾個重要的配置參數：

  • corePoolSize：核心線程數（最新線程數）
  • maximumPoolSize：最大線程數，超過這個數量的任務會被拒絕，用戶可以通過RejectedExecutionHandler接口自定義處理方式
  • keepAliveTime：線程保持活動的時間
  • workQueue：工作隊列，存放執行的任務

Java線程池需要傳入一個Queue參數（workQueue）用來存放執行的任務，而對Queue的不同選擇，線程池有完全不同的行為：

  • SynchronousQueue： 一個無容量的等待隊列，一個線程的insert操作必須等待另一線程的remove操作，采用這個Queue線程池將會為每個任務分配一個新線程
  • LinkedBlockingQueue ： 無界隊列，采用該Queue，線程池將忽略 maximumPoolSize參數，僅用corePoolSize的線程處理所有的任務，未處理的任務便在LinkedBlockingQueue中排隊
  • ArrayBlockingQueue： 有界隊列，在有界隊列和 maximumPoolSize的作用下，程序將很難被調優：更大的Queue和小的maximumPoolSize將導致CPU的低負載；小的Queue和大的池，Queue就沒起動應有的作用。

其實我們的要求很簡單，希望線程池能跟連接池一樣，能設置最小線程數、最大線程數，當最小數<任務<最大數時，應該分配新的線程處理；當任務>最大數時，應該等待有空閑線程再處理該任務。

但線程池的設計思路是，任務應該放到Queue中，當Queue放不下時再考慮用新線程處理，如果Queue滿且無法派生新線程，就拒絕該任務。設計導致“先放等執行”、“放不下再執行”、“拒絕不等待”。所以，根據不同的Queue參數，要提高吞吐量不能一味地增大maximumPoolSize。

當然，要達到我們的目標，必須對線程池進行一定的封裝，幸運的是ThreadPoolExecutor中留了足夠的自定義接口以幫助我們達到目標。我們封裝的方式是：

  • 以SynchronousQueue作為參數，使maximumPoolSize發揮作用，以防止線程被無限制的分配，同時可以通過提高maximumPoolSize來提高系統吞吐量
  • 自定義一個RejectedExecutionHandler，當線程數超過maximumPoolSize時進行處理，處理方式為隔一段時間檢查線程池是否可以執行新Task，如果可以把拒絕的Task重新放入到線程池，檢查的時間依賴keepAliveTime的大小。

2.連接池（org.apache.commons.dbcp.BasicDataSource）

在使用org.apache.commons.dbcp.BasicDataSource的時候，因為之前采用了默認配置，所以當訪問量大時，通過JMX觀察到很多Tomcat線程都阻塞在BasicDataSource使用的Apache ObjectPool的鎖上，直接原因當時是因為BasicDataSource連接池的最大連接數設置的太小，默認的BasicDataSource配置，僅使用8個最大連接。

我還觀察到一個問題，當較長的時間不訪問系統，比如2天，DB上的Mysql會斷掉所以的連接，導致連接池中緩存的連接不能用。為了解決這些問題，我們充分研究了BasicDataSource，發現了一些優化的點：

  • Mysql默認支持100個鏈接，所以每個連接池的配置要根據集群中的機器數進行，如有2臺服務器，可每個設置為60
  • initialSize：參數是一直打開的連接數
  • minEvictableIdleTimeMillis：該參數設置每個連接的空閑時間，超過這個時間連接將被關閉
  • timeBetweenEvictionRunsMillis：後臺線程的運行周期，用來檢測過期連接
  • maxActive：最大能分配的連接數
  • maxIdle：最大空閑數，當連接使用完畢後發現連接數大於maxIdle，連接將被直接關閉。只有initialSize < x < maxIdle的連接將被定期檢測是否超期。這個參數主要用來在峰值訪問時提高吞吐量。
  • initialSize是如何保持的？經過研究代碼發現，BasicDataSource會關閉所有超期的連接，然後再打開initialSize數量的連接，這個特性與minEvictableIdleTimeMillis、timeBetweenEvictionRunsMillis一起保證了所有超期的initialSize連接都會被重新連接，從而避免了Mysql長時間無動作會斷掉連接的問題。

3.JVM參數

在JVM啟動參數中，可以設置跟內存、垃圾回收相關的一些參數設置，默認情況不做任何設置JVM會工作的很好，但對一些配置很好的Server和具體的應用必須仔細調優才能獲得最佳性能。通過設置我們希望達到一些目標：

  • GC的時間足夠的小
  • GC的次數足夠的少
  • 發生Full GC的周期足夠的長

前兩個目前是相悖的，要想GC時間小必須要一個更小的堆，要保證GC次數足夠少，必須保證一個更大的堆，我們只能取其平衡。

（1）針對JVM堆的設置一般，可以通過-Xms -Xmx限定其最小、最大值，為了防止垃圾收集器在最小、最大之間收縮堆而產生額外的時間，我們通常把最大、最小設置為相同的值
（2）年輕代和年老代將根據默認的比例（1：2）分配堆內存，可以通過調整二者之間的比率NewRadio來調整二者之間的大小，也可以針對回收代，比如年輕代，通過 -XX:newSize -XX:MaxNewSize來設置其絕對大小。同樣，為了防止年輕代的堆收縮，我們通常會把-XX:newSize -XX:MaxNewSize設置為同樣大小

（3）年輕代和年老代設置多大才算合理？這個我問題毫無疑問是沒有答案的，否則也就不會有調優。我們觀察一下二者大小變化有哪些影響

  • 更大的年輕代必然導致更小的年老代，大的年輕代會延長普通GC的周期，但會增加每次GC的時間；小的年老代會導致更頻繁的Full GC
  • 更小的年輕代必然導致更大年老代，小的年輕代會導致普通GC很頻繁，但每次的GC時間會更短；大的年老代會減少Full GC的頻率
  • 如何選擇應該依賴應用程序對象生命周期的分布情況：如果應用存在大量的臨時對象，應該選擇更大的年輕代；如果存在相對較多的持久對象，年老代應該適當增大。但很多應用都沒有這樣明顯的特性，在抉擇時應該根據以下兩點：（A）本著Full GC盡量少的原則，讓年老代盡量緩存常用對象，JVM的默認比例1：2也是這個道理 （B）通過觀察應用一段時間，看其他在峰值時年老代會占多少內存，在不影響Full GC的前提下，根據實際情況加大年輕代，比如可以把比例控制在1：1。但應該給年老代至少預留1/3的增長空間

（4）在配置較好的機器上（比如多核、大內存），可以為年老代選擇並行收集算法： -XX:+UseParallelOldGC ，默認為Serial收集

（5）線程堆棧的設置：每個線程默認會開啟1M的堆棧，用於存放棧幀、調用參數、局部變量等，對大多數應用而言這個默認值太了，一般256K就足用。理論上，在內存不變的情況下，減少每個線程的堆棧，可以產生更多的線程，但這實際上還受限於操作系統。

（4）可以通過下面的參數打Heap Dump信息

  • -XX:HeapDumpPath
  • -XX:+PrintGCDetails
  • -XX:+PrintGCTimeStamps
  • -Xloggc:/usr/aaa/dump/heap_trace.txt

通過下面參數可以控制OutOfMemoryError時打印堆的信息

  • -XX:+HeapDumpOnOutOfMemoryError

請看一下一個時間的Java參數配置：（服務器：Linux 64Bit，8Core×16G）

JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G"

經過觀察該配置非常穩定，每次普通GC的時間在10ms左右，Full GC基本不發生，或隔很長很長的時間才發生一次

通過分析dump文件可以發現，每個1小時都會發生一次Full GC，經過多方求證，只要在JVM中開啟了JMX服務，JMX將會1小時執行一次Full GC以清除引用，關於這點請參考附件文檔。

4.程序算法調優：本次不作為重點

參考鏈接：https://blog.csdn.net/chen77716/article/details/5695893

JVM內存調優

相關推薦

Java jvm內存調優（來自小強公開課）

jvmJava jvm內存調優 Jdk：java開發工具包Jre：java運行環境，運行你編寫的java程序Jvm：java虛擬機，.class文件在虛擬機上運行 如何選擇合適的java虛擬機》》》選擇穩定的jdk（慎用新出的，新特性的）》》》根據平臺和應用，選擇合適廠商的jdk。HP-UX只能選擇HP J

JVM內存調優

move tof 現象 AC sep 臨時 開啟 xmx per JVM性能調優有很多設置,這個參考JVM參數即可. 主要調優的目的: 控制GC的行為.GC是一個後臺處理,但是它也是會消耗系統性能的,因此經常會根據系統運行的程序的特性來更改GC行為 控

JVM實用參數（四）內存調優

cleanup 有趣的 ilo tro href 細節 工作 lin 最大值 JVM實用參數（四）內存調優 原文地址，譯文地址，作者：PATRICK PESCHLOW，譯者：鄭旭東 校對：梁海艦 理想的情況下，一個Java程序使用JVM的默認設置也可以運行得很好，

【Spark篇】---Spark調優之代碼調優，數據本地化調優，內存調優，SparkShuffle調優，Executor的堆外內存調優

左右 任務調度 combiner flight 觸發 年齡 ans minor 序列化機制 一、前述 Spark中調優大致分為以下幾種 ，代碼調優，數據本地化，內存調優，SparkShuffle調優，調節Executor的堆外內存。 二、具體 1、代碼調優 1、避免創

2019/05/13 JAVA虛擬機堆內存調優

信息 -xmx 因此 串行 是否 mman -xms com use -Xms4000m 堆內存初始值 * -Xmx4000m 堆內存最大值 * -XX:+PrintGCDetails 打印GC信息 * -XX:+UseSerialGC 使用串行GC *

深入理解Java虛擬機（jvm性能調優+內存模型+虛擬機原理）視頻教程

boot operate 小型 spa clas padding ali restful left 14套java精品高級架構課，緩存架構，深入Jvm虛擬機，全文檢索Elasticsearch，Dubbo分布式Restful 服務，並發原理編程，SpringBoot，Sp

深入理解Java虛擬機（jvm性能調優+內存模型+虛擬機原理）

Java 課程大綱:第1節說在前面的話 00:05:07分鐘第2節整個部分要講的內容說明 00:06:58分鐘第3節環境搭建以及jdk,jre,jvm的關系 00:20:48分鐘第4節jvm初體驗-內存溢出問題的分析與解決 00:17:59分鐘第5節jvm再體驗-jvm可視化監控工具 00

JVM性能調優 第七章 內存分配策略

作用域 直接 csdn art 分配 優先 每次 ret blog 理解了jvm內存分配策略不僅是程序性能調優的重要知識，還能夠給養成自己一種良好的代碼思路，一個程序的代碼差異往往都是在這裏體現出來的。 一、對象優先分配到Eden區域 　 一般來說，新創建的對象都會直接分

JVM性能調優-內存泄露問題

get mine 作用 內存泄漏 pools mpp out 導入 一個 轉https://www.cnblogs.com/baizhanshi/p/6590406.html 最近因項目存在內存泄漏，故進行大規模的JVM性能調優 ， 現把經驗做一記錄。 一、JVM內存

jvm內存模型、常見參數及調優

str 年齡 orm maxperm isp 9.png pac 虛擬機棧 vivo JVM內存結構： 主要分為：方法區、堆、虛擬機棧、本地方法棧、程序計數器，其中方法區和堆是線程共享的，其他的都是線程隔離的。 方法區： 主要存放類的信息、靜態變量、常量、編譯後的

JVM內存模型

執行時間 一次 參數設置 壓棧 loader 中間 定義 將不 泄露 JVM定義了若幹個程序執行期間使用的數據區域。這個區域裏的一些數據在JVM啟動的時候創建，在JVM退出的時候銷毀。而其他的數據依賴於每一個線程，在線程創建時創建，在線程退出時銷毀。 程序計數器 程序

myEclipse開發內存溢出解決辦法myEclipse調整jvm內存大小java.lang.OutOfMemoryError: PermGen space及其解決方法

try 配置 及其 windows logs 環境 ner log reference 摘要: tomcat部署多個項目後，啟動tomcat正常，訪問項目時卻會出現該錯誤在網上查了查又試了好幾次，才解決，將解決方法記錄下來，以方便以後查看或讓遇到同樣問題的朋友有個參考 P

jvm內存模型及分配參數

java pat 技術分享 下一條 ava 最大值 images overflow wsize jvm內存模型 程序計數器：是一塊很小的內存空間。當線程數量超過cpu數量時，線程之間根據時間片輪詢搶奪cpu資源。每一個線程都必須用一個獨立的程序計數器，用於記錄下一條要運行

【1】JVM-內存模型

也會 安全性 編譯器 結構 cati local 狀況 本地方法棧 處理 本篇其實就是一個讀書筆記，書是《深入理解JAVA虛擬機》，在網上搜索JAVA內存，說的比較好的其實很多都源自這本書，作為一個JAVA程序員，理解虛擬機是通向高級程序員的必經道路。本篇中的圖片源自當時網

JVM內存分配與回收策略

failure ret 虛擬機 收集器 字符 設置 足夠 java 選擇 對象優先在Eden分配 大多數情況下，對象在新生代Eden區中分配。 當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC。 Minor GC:新生代GC，指發生在新生代的垃圾收

JVM內存監視手段和內存溢出解決方案

max 什麽 detail pat ogg 最大堆 還需 .net 設置 引言 本文僅關註一些常見的虛擬機內存監視手段，以及JVM運行時數據區各個部分內存溢出的發生和對應的解決方案，總體來說屬於概括性總結，涉及相對不是很深入，目的是讓自己和其它初學者有一個框架性、概念性的了

JVM內存堆布局圖解分析

new 移動 art 文檔 rman 單個 線程 改變 完成 轉載原文出處：http://www.codeceo.com/article/jvm-memory-stack.html JAVA能夠實現跨平臺的一個根本原因，是定義了class文件的格式標準,凡是實現

JVM的基本結構和JVM內存結構

字符 函數 初始 修改 mach html 空間 使用 mage JVM的基本結構和JVM的內存結構 這裏介紹一下JVM在啟動後，作為操作系統的一個進程的基本結構，以及從操作系統角度看，JVM如何管理它從操作系統裏申請來的內存的，也就是JVM的內存結構或者叫JVM內存

JVM內存

blog mage 內存 bsp com man 垃圾 image 回收 JVM內存模型中分兩大塊，一塊是 NEW Generation, 另一塊是Old Generation. 在New Generation中，有一個叫Eden的空間，主要是用來存放新生的對象，還有兩個S

JVM內存—堆（heap）棧（stack）方法區（method） (轉)

定位 箭頭 環境 構造方法 做的 語言 .com jvm的內存 系列 JAVA的JVM的內存可分為3個區：堆(heap)、棧(stack)和方法區(method) 堆區:1.存儲的全部是對象，每個對象都包含一個與之對應的class的信息。(class的目的是得到操作指令)