2. 程式人生 > >Java效能優化系列二（jvm記憶體調優）

Java效能優化系列二（jvm記憶體調優）

阿新 • • 發佈：2019-01-02

首先需要注意的是在對JVM記憶體調優的時候不能只看作業系統級別Java程序所佔用的記憶體，這個數值不能準確的反應堆記憶體的真實佔用情況，因為GC過後這個值是不會變化的，因此記憶體調優的時候要更多地使用JDK提供的記憶體檢視工具，比如JConsole和Java VisualVM(jvisualvm)。

對JVM記憶體的系統級的調優主要的目的是減少GC的頻率和Full GC的次數，過多的GC和Full GC是會佔用很多的系統資源（主要是CPU），影響系統的吞吐量。特別要關注Full GC，因為它會對整個堆進行整理，導致Full GC一般由於以下幾種情況：

  • 1. 舊生代空間不足
    調優時儘量讓物件在新生代GC時被回收、讓物件在新生代多存活一段時間和不要建立過大的物件及陣列避免直接在舊生代建立物件 
  • 2. Pemanet Generation空間不足
    增大Perm Gen空間，避免太多靜態物件 
  • 統計得到的GC後晉升到舊生代的平均大小大於舊生代剩餘空間
    控制好新生代和舊生代的比例 
  • 3. System.gc()被顯示呼叫
    垃圾回收不要手動觸發，儘量依靠JVM自身的機制 

調優手段主要是通過控制堆記憶體的各個部分的比例和GC策略來實現，下面來看看各部分比例不良設定會導致什麼後果

1）新生代設定過小

一是新生代GC次數非常頻繁，增大系統消耗；二是導致大物件直接進入舊生代，佔據了舊生代剩餘空間，誘發Full GC

2）新生代設定過大

一是新生代設定過大會導致舊生代過小（堆總量一定），從而誘發Full GC；二是新生代GC耗時大幅度增加

一般說來新生代佔整個堆1/3比較合適

3）Survivor設定過小

導致物件從eden直接到達舊生代，降低了在新生代的存活時間

4）Survivor設定過大

導致eden過小，增加了GC頻率

另外，通過-XX:MaxTenuringThreshold=n來控制新生代存活時間，儘量讓物件在新生代被回收

JVM提供兩種較為簡單的GC策略的設定方式

1）吞吐量優先

JVM以吞吐量為指標，自行選擇相應的GC策略及控制新生代與舊生代的大小比例，來達到吞吐量指標。這個值可由-XX:GCTimeRatio=n來設定

2）暫停時間優先

JVM以暫停時間為指標，自行選擇相應的GC策略及控制新生代與舊生代的大小比例，儘量保證每次GC造成的應用停止時間都在指定的數值範圍內完成。這個值可由-XX:MaxGCPauseRatio=n來設定

 

 

JVM引數設定、分析

不管是YGC還是Full GC,GC過程中都會對導致程式執行中中斷,正確的選擇不同的GC策略,調整JVM、GC的引數，可以極大的減少由於GC工作，而導致的程式執行中斷方面的問題，進而適當的提高Java程式的工作效率。但是調整GC是一個極為複雜的過程，由於各個程式具備不同的特點，如：web和GUI程式就有很大區別（Web可以適當的停頓，但GUI停頓是客戶無法接受的），而且由於跑在各個機器上的配置不同（主要cup個數，記憶體不同），所以使用的GC種類也會不同(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要引數的設定來提高系統的效能。

JVM引數的含義 例項見例項分析

引數名稱 含義 預設值  
-Xms 初始堆大小 實體記憶體的1/64(<1GB) 預設(MinHeapFreeRatio引數可以調整)空餘堆記憶體小於40%時，JVM就會增大堆直到-Xmx的最大限制.
-Xmx 最大堆大小 實體記憶體的1/4(<1GB) 預設(MaxHeapFreeRatio引數可以調整)空餘堆記憶體大於70%時，JVM會減少堆直到 -Xms的最小限制
-Xmn 年輕代大小(1.4or lator)   注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的。
整個堆大小=年輕代大小 + 年老代大小 + 持久代大小.
增大年輕代後,將會減小年老代大小.此值對系統性能影響較大,Sun官方推薦配置為整個堆的3/8
-XX:NewSize 設定年輕代大小(for 1.3/1.4)    
-XX:MaxNewSize 年輕代最大值(for 1.3/1.4)    
-XX:PermSize 設定持久代(perm gen)初始值 實體記憶體的1/64  
-XX:MaxPermSize 設定持久代最大值 實體記憶體的1/4  
-Xss 每個執行緒的堆疊大小   JDK5.0以後每個執行緒堆疊大小為1M,以前每個執行緒堆疊大小為256K.更具應用的執行緒所需記憶體大小進行 調整.在相同實體記憶體下,減小這個值能生成更多的執行緒.但是作業系統對一個程序內的執行緒數還是有限制的,不能無限生成,經驗值在3000~5000左右
一般小的應用， 如果棧不是很深， 應該是128k夠用的 大的應用建議使用256k。這個選項對效能影響比較大，需要嚴格的測試。（校長）
和threadstacksize選項解釋很類似,官方文件似乎沒有解釋,在論壇中有這樣一句話:"”
-Xss is translated in a VM flag named ThreadStackSize”
一般設定這個值就可以了。
-XX:ThreadStackSize Thread Stack Size   (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:NewRatio 年輕代(包括Eden和兩個Survivor區)與年老代的比值(除去持久代)   -XX:NewRatio=4表示年輕代與年老代所佔比值為1:4,年輕代佔整個堆疊的1/5
Xms=Xmx並且設定了Xmn的情況下，該引數不需要進行設定。
-XX:SurvivorRatio Eden區與Survivor區的大小比值   設定為8,則兩個Survivor區與一個Eden區的比值為2:8,一個Survivor區佔整個年輕代的1/10
-XX:LargePageSizeInBytes 記憶體頁的大小不可設定過大， 會影響Perm的大小   =128m
-XX:+UseFastAccessorMethods 原始型別的快速優化    
-XX:+DisableExplicitGC 關閉System.gc()   這個引數需要嚴格的測試
-XX:MaxTenuringThreshold 垃圾最大年齡   如果設定為0的話,則年輕代物件不經過Survivor區,直接進入年老代. 對於年老代比較多的應用,可以提高效率.如果將此值設定為一個較大值,則年輕代物件會在Survivor區進行多次複製,這樣可以增加物件再年輕代的存活 時間,增加在年輕代即被回收的概率
該引數只有在序列GC時才有效.
-XX:+AggressiveOpts 加快編譯    
-XX:+UseBiasedLocking 鎖機制的效能改善    
-Xnoclassgc 禁用垃圾回收    
-XX:SoftRefLRUPolicyMSPerMB 每兆堆空閒空間中SoftReference的存活時間 1s softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap
-XX:PretenureSizeThreshold 物件超過多大是直接在舊生代分配 0 單位位元組 新生代採用Parallel Scavenge GC時無效
另一種直接在舊生代分配的情況是大的陣列物件,且陣列中無外部引用物件.
-XX:TLABWasteTargetPercent TLAB佔eden區的百分比 1%  
-XX:+CollectGen0First FullGC時是否先YGC false  

並行收集器相關引數

-XX:+UseParallelGC Full GC採用parallel MSC
(此項待驗證)		  

選擇垃圾收集器為並行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用併發收集,而年老代仍舊使用序列收集.(此項待驗證)
-XX:+UseParNewGC 設定年輕代為並行收集   可與CMS收集同時使用
JDK5.0以上,JVM會根據系統配置自行設定,所以無需再設定此值
-XX:ParallelGCThreads 並行收集器的執行緒數   此值最好配置與處理器數目相等 同樣適用於CMS
-XX:+UseParallelOldGC 年老代垃圾收集方式為並行收集(Parallel Compacting)   這個是JAVA 6出現的引數選項
-XX:MaxGCPauseMillis 每次年輕代垃圾回收的最長時間(最大暫停時間)   如果無法滿足此時間,JVM會自動調整年輕代大小,以滿足此值.
-XX:+UseAdaptiveSizePolicy 自動選擇年輕代區大小和相應的Survivor區比例   設定此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直開啟.
-XX:GCTimeRatio 設定垃圾回收時間佔程式執行時間的百分比   公式為1/(1+n)
-XX:+ScavengeBeforeFullGC Full GC前呼叫YGC true Do young generation GC prior to a full GC. (Introduced in 1.4.1.)

CMS相關引數

-XX:+UseConcMarkSweepGC 使用CMS記憶體收集   測試中配置這個以後,-XX:NewRatio=4的配置失效了,原因不明.所以,此時年輕代大小最好用-Xmn設定.???
-XX:+AggressiveHeap     試圖是使用大量的實體記憶體
長時間大記憶體使用的優化，能檢查計算資源（記憶體， 處理器數量）
至少需要256MB記憶體
大量的CPU／記憶體， （在1.4.1在4CPU的機器上已經顯示有提升）
-XX:CMSFullGCsBeforeCompaction 多少次後進行記憶體壓縮   由於併發收集器不對記憶體空間進行壓縮,整理,所以執行一段時間以後會產生"碎片",使得執行效率降低.此值設定執行多少次GC以後對記憶體空間進行壓縮,整理.
-XX:+CMSParallelRemarkEnabled 降低標記停頓    
-XX+UseCMSCompactAtFullCollection 在FULL GC的時候， 對年老代的壓縮   CMS是不會移動記憶體的， 因此， 這個非常容易產生碎片， 導致記憶體不夠用， 因此， 記憶體的壓縮這個時候就會被啟用。 增加這個引數是個好習慣。
可能會影響效能,但是可以消除碎片
-XX:+UseCMSInitiatingOccupancyOnly 使用手動定義初始化定義開始CMS收集   禁止hostspot自行觸發CMS GC
-XX:CMSInitiatingOccupancyFraction=70 使用cms作為垃圾回收
使用70％後開始CMS收集		 92 為了保證不出現promotion failed(見下面介紹)錯誤,該值的設定需要滿足以下公式CMSInitiatingOccupancyFraction計算公式
-XX:CMSInitiatingPermOccupancyFraction 設定Perm Gen使用到達多少比率時觸發 92  
-XX:+CMSIncrementalMode 設定為增量模式   用於單CPU情況
-XX:+CMSClassUnloadingEnabled      

輔助資訊

-XX:+PrintGC    

輸出形式:

[GC 118250K->113543K(130112K), 0.0094143 secs]
[Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails    

輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps      
-XX:+PrintGC:PrintGCTimeStamps     可與-XX:+PrintGC -XX:+PrintGCDetails混合使用
輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
-XX:+PrintGCApplicationStoppedTime 列印垃圾回收期間程式暫停的時間.可與上面混合使用   輸出形式:Total time for which application threads were stopped: 0.0468229 seconds
-XX:+PrintGCApplicationConcurrentTime 列印每次垃圾回收前,程式未中斷的執行時間.可與上面混合使用   輸出形式:Application time: 0.5291524 seconds
-XX:+PrintHeapAtGC 列印GC前後的詳細堆疊資訊    
-Xloggc:filename 把相關日誌資訊記錄到檔案以便分析.
與上面幾個配合使用		    

-XX:+PrintClassHistogram

 garbage collects before printing the histogram.    
-XX:+PrintTLAB 檢視TLAB空間的使用情況    
XX:+PrintTenuringDistribution 檢視每次minor GC後新的存活週期的閾值  

Desired survivor size 1048576 bytes, new threshold 7 (max 15)
new threshold 7即標識新的存活週期的閾值為7。

GC效能方面的考慮

       對於GC的效能主要有2個方面的指標：吞吐量throughput（工作時間不算gc的時間佔總的時間比）和暫停pause（gc發生時app對外顯示的無法響應）。

1. Total Heap

       預設情況下，vm會增加/減少heap大小以維持free space在整個vm中佔的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。

一般而言，server端的app會有以下規則：

  • 對vm分配儘可能多的memory；
  • 將Xms和Xmx設為一樣的值。如果虛擬機器啟動時設定使用的記憶體比較小，這個時候又需要初始化很多物件，虛擬機器就必須重複地增加記憶體。
  • 處理器核數增加，記憶體也跟著增大。

2. The Young Generation

       另外一個對於app流暢性執行影響的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情況下，更大的young generation就意味著小的tenured generation，就意味著更多的major collection(major collection會引發minor collection)。

       NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設為一樣就固定了young generation的大小（同Xms和Xmx設為一樣）。

       如果希望，SurvivorRatio也可以優化survivor的大小，不過這對於效能的影響不是很大。SurvivorRatio是eden和survior大小比例。

一般而言，server端的app會有以下規則：

  • 首先決定能分配給vm的最大的heap size，然後設定最佳的young generation的大小；
  • 如果heap size固定後，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時候夠大，能夠容納所有live的data（留10%-20%的空餘）。

經驗&&規則

  1. 年輕代大小選擇
    • 響應時間優先的應用:儘可能設大,直到接近系統的最低響應時間限制(根據實際情況選擇).在此種情況下,年輕代收集發生的頻率也是最小的.同時,減少到達年老代的物件.
    • 吞吐量優先的應用:儘可能的設定大,可能到達Gbit的程度.因為對響應時間沒有要求,垃圾收集可以並行進行,一般適合8CPU以上的應用.
    • 避免設定過小.當新生代設定過小時會導致:1.YGC次數更加頻繁 2.可能導致YGC物件直接進入舊生代,如果此時舊生代滿了,會觸發FGC.
  2. 年老代大小選擇
    1. 響應時間優先的應用:年老代使用併發收集器,所以其大小需要小心設定,一般要考慮併發會話率和會話持續時間等一些引數.如果堆設定小了,可以會造成記憶體碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間.最優化的方案,一般需要參考以下資料獲得:
      併發垃圾收集資訊、持久代併發收集次數、傳統GC資訊、花在年輕代和年老代回收上的時間比例。
    2. 吞吐量優先的應用:一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以儘可能回收掉大部分短期物件,減少中期的物件,而年老代僅存放長期存活物件.
  3. 較小堆引起的碎片問題
    因為年老代的併發收集器使用標記,清除演算法,所以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合併,這樣可以分配給較大的物件.但是,當堆空間較小時,執行一段時間以後,就會出現"碎片",如果併發收集器找不到足夠的空間,那麼併發收集器將會停止,然後使用傳統的標記,清除方式進行回收.如果出現"碎片",可能需要進行如下配置:
    -XX:+UseCMSCompactAtFullCollection:使用併發收集器時,開啟對年老代的壓縮.
    -XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這裡設定多少次Full GC後,對年老代進行壓縮
  4. 用64位作業系統，Linux下64位的jdk比32位jdk要慢一些，但是吃得記憶體更多，吞吐量更大
  5. XMX和XMS設定一樣大，MaxPermSize和MinPermSize設定一樣大，這樣可以減輕伸縮堆大小帶來的壓力
  6. 使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的記憶體， 大約20－80ms的應用程式停頓時間
  7. 系統停頓的時候可能是GC的問題也可能是程式的問題，多用jmap(堆記憶體情況)和jstack(棧記憶體情況)檢視，或者killall -3 java，然後檢視java控制檯日誌，能看出很多問題。(相關工具的使用方法將在後面介紹)
  8. 仔細瞭解自己的應用，如果用了快取，那麼年老代應該大一些，快取的HashMap不應該無限制長，建議採用LRU演算法的Map做快取，LRUMap的最大長度也要根據實際情況設定。
  9. 採用併發回收時，年輕代小一點，年老代要大，因為年老大用的是併發回收，即使時間長點也不會影響其他程式繼續執行，網站不會停頓
  10. JVM引數的設定(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio  -XX:MaxTenuringThreshold等引數的設定沒有一個固定的公式，需要根據PV old區實際資料 YGC次數等多方面來衡量。為了避免promotion faild可能會導致xmn設定偏小，也意味著YGC的次數會增多，處理併發訪問的能力下降等問題。每個引數的調整都需要經過詳細的效能測試，才能找到特定應用的最佳配置。

promotion failed:

垃圾回收時promotion failed是個很頭痛的問題，一般可能是兩種原因產生，第一個原因是救助空間不夠，救助空間裡的物件還不應該被移動到年老代，但年輕代又有很多物件需要放入救助空間；第二個原因是年老代沒有足夠的空間接納來自年輕代的物件；這兩種情況都會轉向Full GC，網站停頓時間較長。

解決方方案一：

第一個原因我的最終解決辦法是去掉救助空間，設定-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個原因我的解決辦法是設定CMSInitiatingOccupancyFraction為某個值（假設70），這樣年老代空間到70%時就開始執行CMS，年老代有足夠的空間接納來自年輕代的物件。

解決方案一的改進方案：

又有改進了，上面方法不太好，因為沒有用到救助空間，所以年老代容易滿，CMS執行會比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會有promotion failed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統似乎只要配置MaxTenuringThreshold引數，CMS還是有暫停。為了解決暫停問題和promotion failed問題，最後我設定-XX:SurvivorRatio=1 ，並把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因為好多物件到不了年老代就被回收了），所以CMS執行頻率非常低，好幾個小時才執行一次，這樣，伺服器都不用重啟了。

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

 

CMSInitiatingOccupancyFraction值與Xmn的關係公式

上面介紹了promontion faild產生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活物件存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區記憶體也不夠的情況下產生了promontion faild從而導致full gc.那可以推斷出：eden+from survivor < old gen區剩餘記憶體時，不會出現promontion faild的情況，即：
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2))  進而推斷出：

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

例如：

當xmx=128 xmn=36 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913

當xmx=128 xmn=24 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…

當xmx=3000 xmn=600 SurvivorRatior=1時  CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33

CMSInitiatingOccupancyFraction低於70% 需要調整xmn或SurvivorRatior值。

令：

網上一童鞋推斷出的公式是：:(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 這個公式個人認為不是很嚴謹，在記憶體小的時候會影響xmn的計算。

相關推薦

Java效能優化系列二（jvm記憶體調優）

首先需要注意的是在對JVM記憶體調優的時候不能只看作業系統級別Java程序所佔用的記憶體，這個數值不能準確的反應堆記憶體的真實佔用情況，因為GC過後這個值是不會變化的，因此記憶體調優的時候要更多地使用JDK提供的記憶體檢視工具，比如JConsole和Java VisualVM(jvisua

jvm系列四：jvm記憶體調優

JVM引數的含義 例項見例項分析 引數名稱 含義 預設值 -Xms 初始堆大小 實體記憶體的1/64(<1GB) 預設(MinHeapFreeRatio引數可以調整)空餘堆記憶體小於40%時，JVM就會增大堆直到-Xmx的最大限制. -Xmx 最大堆大小 實體記憶體的1/4(&

java併發系列二（深入!!!理解synchronized,volatile）

一，synchronized詳解 這個關鍵字大家想必是相當熟悉了，它是一個比較重量級的鎖，主要有兩層含義，一個是互斥性，一個是可見性。三種用法：1，修飾普通方法2，修飾靜態方法3，修飾程式碼塊 這裡有一點需要注意，普通方法要拿到當前例項的鎖，靜態方法要拿到當前class物件的鎖。 重點來

Java效能優化系列集錦

Java效能問題一直困擾著廣大程式設計師，由於平臺複雜性，要定位問題，找出其根源確實很難。隨著10多年Java平臺的改進以及新出現的多核多處理器，Java軟體的效能和擴充套件性已經今非昔比了。現代JVM持續演進，內建了更為成熟的優化技術、執行時技術和垃圾收集器。與此同時，底層

JAVA效能優化調查結果（第二部分）

原文地址 原作者：Nikita Salnikov Tarnovski  譯者 嚴亮 校對：方騰飛（清英） 這是我們在2014年10月做的效能調優調查結果系列的第2部分，如果您還沒讀過第1部分。我推薦先讀第1部分。第2部分我們關注Java應用效能的監控問題。我們特別要嘗試弄清楚下面幾個問題：

筆記二（自動記憶體管理機制）-Java記憶體區域與記憶體溢位異常

1 執行時資料區域      Java虛擬機器在執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域都有各自的用途，以及建立和銷燬的時間，有的區域隨著虛擬機器程序的啟動而存在，有些區域則是依賴使用者執行緒的啟動和結束而建立和銷燬。1.1 程式計數器

JVM記憶體調優相關的一些筆記（雜）

Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss] MaxPerm/MetaSize + MaxDirectMemorySize + Xmx（執行緒棧一般只有幾十M，可以忽略）這差不多就是JVM可以佔用的最大記憶體了 整個

Android效能優化之路（五年之癢）

記得在上學的時候，就聽說在某個方面堅持學習一年，也就入門了。很慶幸，工作五年了，一直都在做Android效能優化。一般來說，工作三年左右會是工作的一個門檻，五年左右會是另外一個門檻，所以最近非常的低落、迷茫。昨晚外面下著漂泊大雨，輾轉反側的我，在想自己這從業五年

手牽手，從零學習Vue原始碼 系列二（變化偵測篇）

系列文章： 手牽手，從零學習Vue原始碼 系列一（前言-目錄篇) 手牽手，從零學習Vue原始碼 系列二（變化偵測篇） 陸續更新中... 預計八月中旬更新完畢。 1 概述 Vue最大的特點之一就是資料驅動檢視，那麼什麼是資料驅動檢視呢？ 其實，我們可以把資料理解為狀態，而檢視就是使用者可直觀看到頁面。頁面不可

SQL Server調優系列進階篇（如何索引調優）

.cn 技術 spa 磁盤 clear 高頻 思路 ltp 覆蓋範圍 前言 上一篇我們分析了數據庫中的統計信息的作用，我們已經了解了數據庫如何通過統計信息來掌控數據庫中各個表的內容分布。不清楚的童鞋可以點擊參考。 作為調優系列的文章，數據庫的索引肯定

JVM記憶體調優 - 淺析 20181121

一.引言 JVM在整個jdk中處於最底層,負責於作業系統的互動，用來遮蔽作業系統環境，提供一個完整的Java執行環境，因此也叫虛擬計算機。作業系統執行JVM是通過jdk中Java.exe來完成的。 每個使用Java的開發者都知道Java位元組碼是在JRE中執行(JRE: J

jvm記憶體調優處理機制

1.棧和堆 棧是執行時的單位，解決程式如何執行，代表處理邏輯 堆是儲存單位，解決資料儲存問題，代表資料 2. 分配記憶體按照8的整數倍 物件的引用： 強引用(宣告物件時虛擬機器生成的引用，不會被回收)， 軟引用（快取，剩餘記憶體不足時被回收） 弱引用(一定被回收) 4.垃圾回

jvm記憶體調優工具

jvm記憶體調優工具 1、jps 2、jstat 3、jinfo 4、jmap 5、jstack 參考文獻 1、jps 全名：Java Virtual Machine Process Status Tool 與linu

Spark效能優化篇三：資料傾斜調優

方案實現思路：這個方案的核心實現思路就是進行兩階段聚合。第一次是區域性聚合，先給每個key都打上一個隨機數，比如10以內的隨機數，此時原先一樣的key就變成不一樣的了，比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)，就會變成(1_hello, 1) (1_hello

TOMCAT連線調優和JVM記憶體調優

開啟tomcat的server.xml檔案，要調整Tomcat的預設最大連線數，可以增加這兩個屬性的值，並且使acceptCount大於等於maxThreads， <Connector port="8080" redirectPort="8443"   connect

MySQL慢查詢優化（線上案例調優）

## 文章說明 這篇文章主要是記錄自己最近在真實工作中遇到的慢查詢的案例，然後進行調優分析的過程，歡迎大家一起討論調優經驗。（以下出現的表名，列名都是化名，實際資料也進行過一點微調。） PS:最近做了一個面試題精選精答的開源專案，如果想要了解更多MySQL相關的技術總結，可以看一看，如果對大家有幫助，希望大家

Spark Performance Tuning （性能調優）

() man inter ber index data- key 兩種 跟蹤 在集群上的 Spark Streaming application 中獲得最佳性能需要一些調整.本節介紹了可調整的多個 parameters （參數）和 configurations （配置）提高

Java效能優化之JVM記憶體模型

JVM記憶體模型 首先介紹下Java程式具體執行的過程: Java原始碼檔案(.java字尾)會被Java編譯器編譯為位元組碼檔案(.class字尾)； 由JVM中的類載入器載入各個類的位元組碼檔案，載入完畢之後，交由JVM執行引擎執行 在整個程式執行過程中，JVM會用==一段空間==來儲存程式執

Java效能系一（JVM、垃圾回收、記憶體調優、常見引數）

一、什麼是JVM     JVM是Java Virtual Machine（Java虛擬機器）的縮寫，JVM是一種用於計算裝置的規範，它是一個虛構出來的計算機，是通過在實際的計算機上模擬模擬各種計算機功能來實現的。     Java語言的一個非常重要的

Java架構學習（十二）java記憶體結構&新生代&老年代&JVM引數調優&堆記憶體引數配置&解決堆疊溢位

JVM引數調優與垃圾回收機制 一、java記憶體結構 Java記憶體模型：是多執行緒裡面的，jmm與執行緒可見性有關 Java記憶體結構：是JVM虛擬機器儲存空間。 Java記憶體結構圖 Java記憶體機構分為：方法區、java堆、棧、本地