| OOM這個(gè)縮寫(xiě)就是Java程序開(kāi)發(fā)過(guò)程中讓人最頭痛的問(wèn)題：Out of Memory。在很多開(kāi)發(fā)人員的開(kāi)發(fā)過(guò)程中，或多或少的都會(huì )遇到這類(lèi)問(wèn)題，這類(lèi)問(wèn)題定位比較困難，往往需要根據經(jīng)驗來(lái)判斷可能出現問(wèn)題的代碼。原因主要是 兩個(gè)：對象沒(méi)有被釋放（多種情況引起，往往是比較隱蔽的引用導致被Hold而無(wú)法被回收）。另一種就是真的Memory不夠用了，需要增加JVM的 Heap來(lái)滿(mǎn)足應用程序的需求。最近有同事發(fā)的關(guān)于解決OOM的問(wèn)題，讓我了解了原來(lái)OOM除了在JVM Heap不夠時(shí)會(huì )發(fā)生，在Native Heap不夠的時(shí)候也會(huì )發(fā)生，同時(shí)JVM Heap和Native Heap存在著(zhù)相互影響和平衡的關(guān)系，因此就仔細的去看了關(guān)于OOM和JVM配置優(yōu)化的內容。 OOM 在 其他語(yǔ)言類(lèi)似于C,Delphi等等由于內存都是由自己分配和管理，因此內存泄露的問(wèn)題比較常見(jiàn)，同時(shí)也是很頭痛的一件事情。而Java的對象生命周期管 理都是JVM來(lái)做的，簡(jiǎn)化了開(kāi)發(fā)人員的非業(yè)務(wù)邏輯的處理，但是這種自動(dòng)管理回收機制也是基于一些規則的，而違背了這些規則的時(shí)候，就會(huì )造成所謂的 “Memory Leak”。 OOM(Java Heap) 錯誤提示：java.lang.OutOfMemoryError。 這 類(lèi)OOM是由于JVM分配的給應用的Heap Memory已經(jīng)被耗盡，可能是因為應用在高負荷的情況下的卻需要很大的內存，因此可以通過(guò)修改JVM參數來(lái)增加Java Heap Memory（不過(guò)也不能無(wú)限制增加，后面那種OOM有可能就是因為這個(gè)原因而產(chǎn)生）。另一種情況是因為應用程序使用對象或者資源沒(méi)有釋放，導致內存消耗 持續增加，最后出現OOM，這類(lèi)問(wèn)題引起的原因往往是應用已不需要的對象還被其他有效對象所引用，那么就無(wú)法釋放，可能是業(yè)務(wù)代碼邏輯造成的（異常處理不 夠例如IO等資源），也可能是對于第三方開(kāi)源項目中資源釋放了解不夠導致使用以后資源沒(méi)有釋放（例如JDBC的ResultSet等）。 幾個(gè)容易出現問(wèn)題的場(chǎng)景： 1．應用的緩存或者Collection：如果應用要緩存Java對象或者是在一個(gè)Collection中保存對象，那么就要確定是否會(huì )有大量的對象存入，要做保護，以防止在大數據量下大量?jì)却姹幌?，同時(shí)要保證Cache的大小不會(huì )無(wú)限制增加。 2．生命周期較長(cháng)的對象：盡量簡(jiǎn)短對象的生命周期，現在采用對象的創(chuàng )建釋放代價(jià)已經(jīng)很低，同時(shí)作了很好的優(yōu)化，要比創(chuàng )建一個(gè)對象長(cháng)期反復使用要好。如果能夠設置超時(shí)的情景下，盡量設置超時(shí)。 3．類(lèi)似于JDBC的Connection Pool，在使用Pool中的對象以后需要釋放并返回，不然就會(huì )造成Pool的不斷增大，在其他Pool中使用也是一樣。同樣ResultSet，IO這類(lèi)資源的釋放都需要注意。 解決的方法就是查找錯誤或者是增加Java Heap Memory。對于此類(lèi)問(wèn)題檢測工具相當多，這里就不做介紹了。 OOM(Native Heap) 錯誤提示：requested XXXX bytes for ChunkPool::allocate. Out of swap space。 Native Heap Memory是JVM 內部使用的Memory，這部分的Memory可以通過(guò)JDK提供的JNI的方式去訪(fǎng)問(wèn)，這部分Memory效率很高，但是管理需要自己去做，如果沒(méi)有把 握最好不要使用，以防出現內存泄露問(wèn)題。JVM 使用Native Heap Memory用來(lái)優(yōu)化代碼載入（JTI代碼生成），臨時(shí)對象空間申請，以及JVM內部的一些操作。這次同事在壓力測試中遇到的問(wèn)題就是這類(lèi)OOM，也就是 這類(lèi)Memory耗盡。同樣這類(lèi)OOM產(chǎn)生的問(wèn)題也是分成正常使用耗盡和無(wú)釋放資源耗盡兩類(lèi)。無(wú)釋放資源耗盡很多時(shí)候不是程序員自身的原因，可能是引用的 第三方包的缺陷，例如很多人遇到的Oracle 9 JDBC驅動(dòng)在低版本中有內存泄露的問(wèn)題。要確定這類(lèi)問(wèn)題，就需要去觀(guān)察Native Heap Memory的增長(cháng)和使用情況，在服務(wù)器應用起來(lái)以后，運行一段時(shí)間后JVM對于Native Heap Memory的使用會(huì )達到一個(gè)穩定的階段，此時(shí)可以看看什么操作對于Native Heap Memory操作頻繁，而且使得Native Heap Memory增長(cháng)，對于Native Heap Memory的情況我還沒(méi)有找到辦法去檢測，現在能夠看到的就是為JVM啟動(dòng)時(shí)候增加-verbose:jni參數來(lái)觀(guān)察對于Native Heap Memory的操作。另一種情況就是正常消耗Native Heap Memory，對于Native Heap Memory的使用主要取決于JVM代碼生成，線(xiàn)程創(chuàng )建，用于優(yōu)化的臨時(shí)代碼和對象產(chǎn)生。當正常耗盡Native Heap Memory時(shí)，那么就需要增加Native Heap Memory，此時(shí)就會(huì )和我們前面提到增加java Heap Memory的情況出現矛盾。 應用內存組合 對 于應用來(lái)說(shuō)，可分配的內存受到OS的限制，不同的OS對進(jìn)程所能訪(fǎng)問(wèn)虛擬內存地址區間直接影響對于應用內存的分配，32位的操作系統通常最大支持4G的內 存尋址，而Linux一般為3G，Windows為2G。然而這些大小的內存并不會(huì )全部給JVM的Java Heap使用，它主要會(huì )分成三部分：Java Heap，Native Heap，載入資源和類(lèi)庫等所占用的內存。那么由此可見(jiàn)，Native Heap和 Java Heap大小配置是相互制約的，哪一部分分配多了都可能會(huì )影響到另外一部分的正常工作，因此如果通過(guò)命令行去配置，那么需要確切的了解應用使用情況，否則 采用默認配置自動(dòng)監測會(huì )更好的優(yōu)化應用使用情況。 同樣要注意的就是進(jìn)程的虛擬內存和機器的實(shí)際內存還是有區別的，對于機器來(lái)說(shuō)實(shí)際內存以及硬盤(pán)提供的虛擬內存都是提供給機器上所有進(jìn)程使用的，因此在設置JVM參數時(shí)，它的虛擬內存絕對不應該超過(guò)實(shí)際內存的大小。 《二》 這 里首先要說(shuō)明的是這里提到的JVM是Sun的HotSpot JVM 5和以上的版本。性能優(yōu)化在應用方面可以有很多手段，包括Cache，多線(xiàn)程，各種算法等等。通常情況下是不建議在沒(méi)有任何統計和分析的情況下去手動(dòng)配置 JVM的參數來(lái)調整性能，因為在JVM 5以上已經(jīng)作了根據機器和OS的情況自動(dòng)配置合適參數的算法，基本能夠滿(mǎn)足大部分的情況，當然這種自動(dòng)適配只是一種通用的方式，如果說(shuō)真的要達到最優(yōu)，那 么還是需要根據實(shí)際的使用情況來(lái)手動(dòng)的配置各種參數設置，提高性能。 JVM能夠對性能產(chǎn)生影響的最大部分就是對于內存的管理。從jdk 1.5以后內存管理和分配有了很多的改善和提高。 內存分配以及管理的幾個(gè)基本概念和參數說(shuō)明： Java Hotspot Mode： server 和 client兩種模式，如果不配置，JVM會(huì )根據應用服務(wù)器硬件配置自動(dòng)選擇模式，server模式啟動(dòng)比較慢，但是運行期速度得到了優(yōu)化，client啟動(dòng)比較快，但是運行期響應沒(méi)有server模式的優(yōu)化，適合于個(gè)人PC的服務(wù)開(kāi)發(fā)和測試。 Garbage Collector Policy： 在Jdk 1.5的時(shí)候已經(jīng)提供了三種GC，除了原來(lái)提供的串行GC（SerialGC）以外，還提供了兩種新的GC：ParallelGC和 ConcMarkSweepGC。ParallelGC采用了多線(xiàn)程并行管理和回收垃圾對象，提高了回收效率，提高了服務(wù)器的吞吐量，適合于多處理器的服 務(wù)器。ConcMarkSweepGC采用的是并發(fā)方式來(lái)管理和回收垃圾對象，降低垃圾回收產(chǎn)生的響應暫停時(shí)間。這里說(shuō)一下并發(fā)和并行的區別，并發(fā)指的是 多個(gè)進(jìn)程并行執行垃圾回收，那么可以很好的利用多處理器，而并行指的是應用程序不需要暫?？梢院屠厥站€(xiàn)程并發(fā)工作。串行GC適合小型應用和單處理器系 統（無(wú)需多線(xiàn)程交互，效率比較高），后兩者適合大型系統。 使用方式就是在參數配置中增加-XX:+UseParallelGC等方式來(lái)設置。 對于這部分的配置在網(wǎng)上有很多的實(shí)例可以參考，不過(guò)最終采用哪一種GC還是要根據具體的情況來(lái)分析和選擇。 Heap： OOM的 各種經(jīng)歷已經(jīng)讓每一個(gè)架構師開(kāi)發(fā)人員看到了了解Heap的重要性。OOM已經(jīng)是Heap的臨界點(diǎn)，不得不引起注意，然而Heap對于性能的潛在影響并未被 引起重視，不過(guò)和GC配置一樣，在沒(méi)有對使用情況作仔細分析和研究的情況下，貿然的去修改Heap配置，可能適得其反，這里就來(lái)看一下Heap的一些概念 和對于性能的影響。 我們的應用所能夠得到的最大的Heap受三部分因素的制約：數據處理 模型（32位或者64位操作系統），系統地虛擬內存總數和系統的物理內存總數。首先Heap的大小不能超過(guò)不同操作系統的進(jìn)程尋址范圍，當前大部分系統最 高限度是4G，Windows通常是2G，Linux通常是3G。系統的虛擬內存也是分配的依據，首先是不能超過(guò)，然后由于操作系統支持硬盤(pán)來(lái)做部分的虛 擬內存，如果設置過(guò)大，那么對于應用響應來(lái)說(shuō)勢必有影響。再則就是要考慮同一臺服務(wù)器上運行多個(gè)Java虛擬機所消耗的資源總合也不能超過(guò)可用資源。就和 前面OOM分析中的一樣，其實(shí)由于OS的數據處理模型的限制，機器本身的硬件內存資源和虛擬內存資源并不一定會(huì )匹配，那么在有限的資源下如何調整好資源分 配，對于應用來(lái)說(shuō)尤為重要。 關(guān)于Heap的幾個(gè)參數設置： 說(shuō)了Heap的有限資源問(wèn)題以后，就來(lái)看看如何通過(guò)配置去改變JVM對于Heap的分配。下面所說(shuō)的主要是對于Java Heap的分配，那么在申請了Java Heap以后，剩下的可用資源就會(huì )被使用到Native Heap。 Xms: java heap初始化時(shí)的大小。默認情況是機器物理內存的1/64。這個(gè)主要是根據應用啟動(dòng)時(shí)消耗的資源決定，分配少了申請起來(lái)會(huì )降低啟動(dòng)速度，分配多了也浪費。 Xmx:java heap的 最大值，默認是機器物理內存的1/4，最大也就到1G。這個(gè)值決定了最多可用的Java Heap Memory，分配過(guò)少就會(huì )在應用需要大量?jì)却孀骶彺婊蛘吡銜r(shí)對象時(shí)出現OOM的問(wèn)題，如果分配過(guò)大，那么就會(huì )產(chǎn)生上文提到的第二類(lèi)OOM。所以如何配置 還是根據運行過(guò)程中的分析和計算來(lái)確定，如果不能確定還是采用默認的配置。 Xmn:java heap新 生代的空間大小。在GC模型中，根據對象的生命周期的長(cháng)短，產(chǎn)生了內存分代的設計：青年代（內部也分成三部分，類(lèi)似于整體劃分的作用，可以通過(guò)配置來(lái)設置 比例），老年代，持久代。每一代的管理和回收策略都不相同，最為活躍的就是青年代，同時(shí)這部分的內存分配和管理效率也是最高。通常情況下，對于內存的申請 優(yōu)先在新生代中申請，當內存不夠時(shí)會(huì )整理新生代，當整理以后還是不能滿(mǎn)足申請的內存，就會(huì )向老年代移動(dòng)一些生命周期較長(cháng)的對象。這種整理和移動(dòng)會(huì )消耗資 源，同時(shí)降低系統運行響應能力，因此如果青年代設置的過(guò)小，就會(huì )頻繁的整理和移動(dòng)，對性能造成影響。那是否把年青代設置的越大越好，其實(shí)不然，年青代采用 的是復制搜集算法，這種算法必須停止所有應用程序線(xiàn)程，服務(wù)器線(xiàn)程切換時(shí)間就會(huì )成為應用響應的瓶頸（當然永遠不用收集那么就不存在這個(gè)問(wèn)題）。老年代采用 的是串行標記收集的方式，并發(fā)收集可以減少對于應用的影響。 Xss:線(xiàn)程堆棧最大值。允許更多的虛擬內存空間地址被Java Heap使用。 以下是sun公司的性能優(yōu)化白皮書(shū)中提到的幾個(gè)例子： 1．對于吞吐量的調優(yōu)。機器配置：4G的內存，32個(gè)線(xiàn)程并發(fā)能力。 java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20-Xmx3800m -Xms3800m 配置了最大Java Heap來(lái)充分利用系統內存。-Xmn2g 創(chuàng )建足夠大的青年代（可以并行被回收）充分利用系統內存，防止將短期對象復制到老年代。 -Xss128 減少默認最大的線(xiàn)程棧大小，提供更多的處理虛擬內存地址空間被進(jìn)程使用。 -XX:+UseParallelGC 采用并行垃圾收集器對年青代的內存進(jìn)行收集，提高效率。 -XX:ParallelGCThreads=20 減少垃圾收集線(xiàn)程，默認是和服務(wù)器可支持的線(xiàn)程最大并發(fā)數相同，往往不需要配置到最大值。2．嘗試采用對老年代并行收集java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC-Xmx3550m -Xms3550m 內存分配被減小，因為ParallelOldGC會(huì )增加對于Native Heap的需求，因此需要減小Java Heap來(lái)滿(mǎn)足需求。-XX:+UseParallelOldGC 采用對于老年代并發(fā)收集的策略，可以提高收集效率。3．提高吞吐量，減少應用停頓時(shí)間java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 選擇了并發(fā)標記交換收集器，它可以并發(fā)執行收集操作，降低應用停止時(shí)間，同時(shí)它也是并行處理模式，可以有效地利用多處理器的系統的多進(jìn)程處理。-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=31 表示在青年代中Eden和Survivor比例，設置增加了Survivor的大小，越大的survivor空間可以允許短期對象盡量在年青代消亡。-XX:TargetSurvivorRatio=90 允許90%的空間被占用，超過(guò)默認的50%，提高對于survivor的使用率。類(lèi)似的例子網(wǎng)上很多，這兒就不在列下來(lái)了，最終是否采取自己配置來(lái)替換默認配置還是要根據虛擬機的使用情況來(lái)分析和配置。 |
聯(lián)系客服
