国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

1. 收集和分析 verbose gc 輸出
   1. 在 java 命令行中添加“-verbosegc”標(biāo)志。這樣將會把 GC 活動信息打印到 stdout/stderr。將 stdout/stderr 重定向到一個(gè)文件。運(yùn)行應(yīng)用程序，直到該問題重現(xiàn)。
      • 確保 JVM 在拋出 java OOM 之前完成下列任務(wù)

        完整 GC 運(yùn)行：
        執(zhí)行一次完整 GC 運(yùn)行，并且刪除了所有不可及對象以及虛可及、弱可及、軟可及對象，并回收了那些空間。有關(guān)不同級別的對象可及性的詳細(xì)信息，可以在以下網(wǎng)址中可找到：http://java.sun.com/developer/technicalArticles/ALT/RefObj

        您可以檢查是否在發(fā)出 OOM 消息之前執(zhí)行了完整 GC 運(yùn)行。當(dāng)完成一次完整 GC 運(yùn)行時(shí)，將會打印類似如下消息（格式取決于 JVM － 請查看 JVM 幫助信息以了解有關(guān)格式）

        [memory ] 7.160: GC 131072K->130052K (131072K) in 1057.359 ms

        以上輸出的格式如下（備注：在此模式下將全部使用相同的格式）：

        [memory ] <start>: GC <before>K-><after>K (<heap>K), <total> ms
        [memory ] <start> - start time of collection (seconds since jvm start)
        [memory ] <before> - memory used by objects before collection (KB)
        [memory ] <after> - memory used by objects after collection (KB)
        [memory ] <heap> - size of heap after collection (KB)
        [memory ] <total> - total time of collection (milliseconds)

        但是，沒有辦法斷定是否使用 verbose 消息刪除了軟/弱/虛可及的對象。如果您懷疑在拋出 OOM 時(shí)這些對象仍然存在，請與 JVM 供應(yīng)商聯(lián)系。

        如果垃圾回收算法是一種按代回收算法（對于 Jrockit 為 gencopy 或 gencon，對于其它 JDK 則是缺省算法），您也將看到類似如下的 verbose 輸出：
        [memory ] 2.414: Nursery GC 31000K->20760K (75776K), 0.469 ms

        以上是 nursery GC（即 young GC）周期，它將把活動對象從 nursery（或 young 空間）提升到 old 空間。這個(gè)周期對我們的分析不重要。有關(guān)按代回收算法的詳細(xì)信息，可以在 JVM 文檔中找到。

        如果在 java OOM 之前未發(fā)生 GC 周期，那么這是一個(gè) JVM 錯(cuò)誤。

        完全壓縮：
        確保 JVM 執(zhí)行了適當(dāng)?shù)膲嚎s工作，并且內(nèi)存并未成碎片（否則會阻止分配大對象并觸發(fā) java OOM 錯(cuò)誤）。

        Java 對象要求內(nèi)存是連續(xù)的。如果可用空閑內(nèi)存是一些碎片，那么 JVM 將無法分配大對象，因?yàn)樗赡軣o法放入任何可用空閑內(nèi)存塊中。在這種情況下，JVM 將執(zhí)行一次完全壓縮，以便形成更多連續(xù)的空閑內(nèi)存來容納大對象。

   壓縮工作包括在 java 堆內(nèi)存中將對象從一個(gè)位置移動到另一個(gè)位置，以及更新對這些對象的引用以指向新位置。除非確有必要，否則 JVM 不會壓縮所有對象。這是為了減少 GC 周期的暫停時(shí)間。

   我們可以通過分析 verbose gc 消息來檢查 java OOM 是否由碎片引起。如果您看到類似如下的輸出（在此無論是否有可用的空閑 java 堆都會拋出 OOM），那么這就是由碎片引起的。

   [memory ] 8.162: GC 73043K->72989K (131072K) in 12.938 ms
   [memory ] 8.172: GC 72989K->72905K (131072K) in 12.000 ms
   [memory ] 8.182: GC 72905K->72580K (131072K) in 13.509 ms
   java.lang.OutOfMemoryError

   在上述情況中您可以看到，所指定的最大堆內(nèi)存是 128MB，并且當(dāng)實(shí)際內(nèi)存使用量僅為 72580K 時(shí)，JVM 拋出 OOM。堆使用量僅為 55%。因此在這種情況下，碎片影響是：即使還有 45％ 的空閑堆，內(nèi)存也會拋出 OOM。這是一個(gè) JVM 錯(cuò)誤或缺陷。您應(yīng)當(dāng)與 JVM 供應(yīng)商聯(lián)系。

2. 如果 JVM 一切都正常（上一步中提到的所有操作），那么此 java OOM 可能是應(yīng)用程序的問題。應(yīng)用程序可能在不斷泄漏一些 java 內(nèi)存，而這可能導(dǎo)致出現(xiàn)上述問題?；蛘撸瑧?yīng)用程序使用更多的活動對象，因此它需要更多 java 堆內(nèi)存。在應(yīng)用程序中可以檢查以下方面：

1.  
   • 應(yīng)用程序中的緩存功能 － 如果應(yīng)用程序在內(nèi)存中緩存 java 對象，則應(yīng)確保此緩存并沒有不斷增大。對緩存中的對象數(shù)應(yīng)有一個(gè)限值。我們可以嘗試減少此限值，來觀察其是否降低 java 堆使用量。
   • 長期活動對象 － 如果應(yīng)用程序中有長期活動對象，則可以嘗試盡可能減少這些對象的存在期。例如，調(diào)整 HTTP 會話超時(shí)值將有助于更快地回收空閑會話對象。
   • 內(nèi)存泄漏 － 內(nèi)存泄漏的一個(gè)例子是在應(yīng)用服務(wù)器中使用數(shù)據(jù)庫連接池。當(dāng)使用連接池時(shí)，必須在 finally 塊中顯式關(guān)閉 JDBC 語句和結(jié)果集對象。這是因?yàn)?，?dāng)從池中調(diào)用連接對象上的 close() 時(shí)，只是簡單地把連接返回池中以供重用，并沒有實(shí)際關(guān)閉連接和關(guān)聯(lián)的語句/結(jié)果集對象。
   • 增加 java 堆 － 如果可能的話，我們也可嘗試增加 java 堆，以觀察是否能解決問題。

   Java 軟引用也可用于數(shù)據(jù)緩存，當(dāng) JVM 用完 java 堆時(shí)，可以保證刪除軟可及對象。

   
   
2. 如果上述建議都不適用于該應(yīng)用程序，那么，我們需要使用一個(gè)基于 JVMPI（JVM 事件探查器接口）的事件探查器（如 Jprobe 或 OptimizeIt）來找出哪些對象正在占用 java 堆。事件探查器還提供 java 代碼中正在創(chuàng)建這些對象的位置的詳細(xì)信息。本文檔并不介紹每個(gè)事件探查器的詳細(xì)信息?？梢詤⒖际录讲槠魑臋n來了解如何用事件探查器設(shè)置和啟動應(yīng)用程序。一般而言，基于 JVMPI 的事件探查器需要較高的系統(tǒng)開銷，并會大大降低應(yīng)用程序的性能。因此，在生產(chǎn)環(huán)境中使用這些事件探查器并不可取。

對于本地 OOM 問題：