這些年來，我們一直密切關注以OutOfMemoryError消息的不同形式打包的問題。 通過專門的服務（例如Google警報），每天就特定關鍵字的新問題進行摘要，使我們對應用程序因日志中的java.lang.OutOfMemoryError失敗而出現的情況有了一個很好的了解。

面臨問題的人們往往會陷入細分市場，因此我決定對一些更有趣的角色進行一些描述。

自學成才的外科醫生 。 這些家伙現在真正具有創造力，我絕對必須為此贊揚他們。 當遇到意外的錯誤消息時，他們提出了很多解釋為什么可能發生此特定錯誤。 并立即解決該問題。

我已經多次看到以下所有內容，以至于我什至失去了計數。 我只能保證這些例子既真實又可怕：

• “即使我購買了16G的額外RAM，我仍然收到OutOfMemoryError錯誤”。 好吧，與其增加-Xmx，對于許多人來說，最明顯的解決方案似乎是轉向瘋狂購物。
• “我的日志中遇到一個OutOfMemoryError，我發現一個.class文件的長度超過1500行。 擺脫掉消息，我的類文件必須有多小”。 如何獲得類文件中的行數與堆空間用盡之間的相關性，這超出了我的范圍，但是我想這種瘋狂的做法是可行的。
• “我從使用java.util.Vectors切換到java.util.ArrayList，花了一個月的時間來重構我的應用程序，但仍然出現OutOfMemoryError”。 好吧，對您有好處，Vectors如此1999年。但同樣，如果您不知道是什么導致疾病的原因，為什么要治愈患者？

這個名單可能永遠持續下去。 令我感到好奇的是-當軟件開發人員的行為舉止如此時-我下次還要去看醫生時是否還應該格外小心？

配置H2x0rz 。 如果JVM配置中有一個參數，則必須對其進行調整。 這似乎是該特定人群的唯一真理。 確實，Oracle JVM工程師推薦的默認值有任何意義的機會是什么。 結果？ 應用程序啟動時的最小堆太大，線程優先級混亂，使用期限極低的使用區域或不合適的和/或實驗性的GC算法。

不要誤會我的意思，如果您知道自己在做什么，并且正在根據實際測量結果進行微調，那就繼續吧。 通常，這些類型的用戶從某個地方繼承了“正確的配置選項集”，并且現在將相同的-XX參數集應用于那里看到的每個JVM。 求你了 您上次面對的具有高度事務性的Web應用程序與您現在唾手可得的數據繁忙的批處理作業完全不同。

數據激增的受害者 。 這些家伙多年來一直在構建和運行業務應用程序而沒有重大性能問題。 然后，雷電擊中該應用程序在日志文件中出現OutOfMemoryErrors的情況下死在地面上。 通過執行一次將太多數據一次加載到內存中的操作，某些用戶突然能夠將整個應用程序運行到地面。

無論是由于業務良好而引起的，還是客戶數量剛剛增長超過一定的魔點，還是公司收購并合并了一個使數據量增加一倍的競爭對手，效果都是一樣的。

可以通過應用許多眾所周知的工具和技術來解決這樣的情況，當它們被識別時。 您可以推遲數據加載，小批量處理操作或更改負責存儲此數據的數據結構-由您決定。 這些解決方案中的許多解決方案都非常合適。

但是，在這種情況下，我們看到的是將問題隱藏在增大的堆大小下。 通過增加配置中的-Xmx確實可以逃脫OutOfMemoryError，但是您仍然經常對用戶造成傷害。 大型操作仍需要很長時間才能完成，因此，由于增加的延遲而使用戶煩惱。 更糟糕的是，增加堆時，通常會導致GC暫停跨越到無法忍受的長度。

我的世界 如果我必須選擇一個負責內存泄漏的應用程序，那就是Minecraft。 多年來，我很可能看到成千上萬沮喪的9歲兒童被迫處理堆配置。

快速搜索可以發現問題的嚴重性，對于那些考慮發布基于Java的桌面軟件的人來說，我想這是一個很好的案例研究。

如果您不覺得自己屬于所列的任何組，那就好。 您是務實的工程師之一，他們在通過總結得出結論之前，通過仔細研究因果關系來為自己的Craft.io感到自豪。

參考： OutOfMemoryError：來自JCG合作伙伴 IvoM?gi的Pantibr Blog博客上的解決方案反模式 。

翻譯自: https://www.javacodegeeks.com/2014/02/outofmemoryerror-solution-antipatterns.html

總結

以上是生活随笔為你收集整理的OutOfMemoryError：解决方案反模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。