九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

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

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

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

        [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 時這些對象仍然存在，請與 JVM 供應商聯(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 空間。這個周期對我們的分析不重要。有關按代回收算法的詳細信息，可以在 JVM 文檔中找到。

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

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

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

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

   我們可以通過分析 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，并且當實際內(nèi)存使用量僅為 72580K 時，JVM 拋出 OOM。堆使用量僅為 55%。因此在這種情況下，碎片影響是：即使還有 45％ 的空閑堆，內(nèi)存也會拋出 OOM。這是一個 JVM 錯誤或缺陷。您應當與 JVM 供應商聯(lián)系。

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

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

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

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

對于本地 OOM 問題：