我寫了一個簡單的應用程序，可以使用數據庫。我的程序有一個表格來顯示數據庫中的數據。當我嘗試擴展框架時，程序失敗，出現OutOfMemory錯誤，但如果我不嘗試這樣做，則效果不錯。Java堆大小的使用
我用-Xmx4m參數開始我的程序。它是否真的需要超過4兆字節處於擴展狀態？
另一個問題：如果我運行java visualVM，我會看到我的程序的堆使用情況的鋸齒邊圖表，而其他使用java VM的程序（例如netbeans）具有更直線的圖表。爲什麼我的程序的堆使用如此不穩定（即使它什麼都不做）（只等待用戶按下按鈕）？
您可能想要嘗試設置此值以生成詳細的堆轉儲，以向您顯示發生了什麼。
-XX：+ HeapDumpOnOutOfMemoryError
在2011年一個典型的 「小」 Java桌面應用程序要與〜64-128MB運行。除非你有非常迫切的需求，否則我會首先將其設置爲默認值（即不設置）。
如果你正在嘗試做一些不同的事情（例如，在Android設備上運行），你將需要非常熟悉分析（並且你應該使用該標籤發佈）。
請記住，如果您要存儲字符數據（Java在內部使用UCS-16），您的100條記錄緩存（〜12個字節）可能（可能）是雙倍。
RE：「不穩定」，JVM正在爲您處理內存使用情況，並根據它選擇的任何算法執行垃圾回收（這些年來這些算法已經發生了巨大變化）。圖表可能只是工具和樣本週期的人爲因素。桌面應用程序的性能受到很多因素的影響。作爲一個例子，我們曾經有過一次巨大的內存「泄漏」，只在一次自動化測試中出現，但從未出現在正常的實際使用情況中。原來測試中，鼠標懸停在一個工具提示上，其中包含打開文件的名稱，而該文件又有一組引用返回到整個（巨大）項目。擺動鼠標幾個像素擺脫了工具提示，這意味着所有的參考清理和垃圾收集器拿出垃圾。
故事的道德？您需要在內存不足時捕獲確切的堆轉儲，並仔細檢查它。
爲什麼要將最大堆大小設置爲4兆字節？ Java通常是內存密集型的，因此將其設置在如此低的水平是一種災難。
它還取決於您的代碼正在創建和銷燬多少個對象，並且基礎Swing（我假設）組件使用組件繪製元素，以及每次組件如何創建和銷燬這些元素重繪。 看看CellRenderer的代碼，它會告訴你爲什麼經常創建和銷燬對象，以及爲什麼垃圾回收器做了這麼好的工作。
試着玩Xmx設置，看看圖表是如何變平的。我預計Xmx64m或Xmx128m將是合適的（儘管從數據庫中傳出的數據量顯然是一個重要的促成因素。）
如果您使用的是擴展屏幕，您可能需要超過4Mb的GUI雙緩衝區，這將產生多個UI圖像，這樣做可以在屏幕上快速顯示它們，通常這是在假設你有很多很多內存的情況下完成的
鋸齒內存分配是由於某些事情完成，然後垃圾回收，這可能在重繪操作或其他計時器上，您的代碼中是否有計時器來檢查某個進程或值是否發生更改，或者是否已將代碼添加到對象重繪或其他進程？
我認爲4mb對於除了一個簡單的程序之外的任何東西都太小了 - 例如很多GUI庫（包括Swing）都需要爲圖形分配臨時工作空間，而這些空間可能超過這個數量。
如果你想避免內存不足的錯誤，但也希望避免過度分配內存給JVM，我建議設置一個大最大堆大小和小的初始堆大小。
我使用100條記錄（每條記錄約12個字節）從數據庫中獲取數據，所以它始終使用恆定數量的內存來存儲數據庫中的數據 – maks 2011-04-05 18:04:55