Java 堆大小使用情况
我编写了一个与数据库一起使用的简单应用程序。我的程序有一个表来显示数据库中的数据。当我尝试扩展框架时，程序因 OutOfMemory 错误而失败，但如果我不尝试这样做，它会正常工作。
我使用 -Xmx4m 参数启动我的程序。它真的需要超过 4 MB 才能处于扩展状态吗？
另一个问题：如果我运行 java VisualVM，我会看到程序的堆使用情况的锯齿形图表，而使用 java VM 的其他程序（例如 netbeans）则有更多的直线图表。为什么我的程序的堆使用如此不稳定，即使它什么都不做（只等待用户按下按钮）？
I've written a simple application that works with database. My program have a table to show data from database. When I try to expand frame the program fails with OutOfMemory error, but if i don't try to do this, it works well.
I start my program with -Xmx4m parametre. Does it really need more than 4 megabytes to be in expanded state?
Another question: if I run the java visualVM I see the saw-edged chart of the heap usage of my program while other programs which is using java VM(such as netbeans) have more rectilinear charts. Why is heap usage of my program so unstable even if it does nothing(only waiting for user to push a button)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能想尝试设置此值来生成详细的堆转储，以准确地显示正在发生的情况。
-XX:+HeapDumpOnOutOfMemoryError
2011 年典型的“小型”Java 桌面应用程序的运行内存约为 64-128MB。除非您确实有迫切的需要，否则我会首先将其设置为默认值（即无设置）。
如果您尝试做一些不同的事情（例如在 Android 设备上运行它），您将需要非常熟悉分析（并且您可能应该使用该标签进行发布）。
请记住，如果您存储字符数据（Java 在内部使用 UCS-16），您的 100 条记录缓存（约 12 字节）可能（可能）是两倍。
RE：“不稳定”，JVM 将为您处理内存使用情况，并将根据它选择的任何算法执行垃圾收集（这些年来这些算法已经发生了巨大的变化）。图表可能只是工具和采样周期的产物。桌面应用程序的性能受到许多因素的影响。
举个例子，我们曾经遇到过一次巨大的内存“泄漏”，该泄漏仅出现在一次自动化测试中，但从未出现在正常的现实世界使用中。结果测试表明，鼠标悬停在工具提示上，其中包含打开文件的名称，而该文件又包含一组对整个（巨大）项目的引用。将鼠标摆动几个像素就可以消除工具提示，这意味着引用全部被清除，垃圾收集器也清除了垃圾。
这个故事的寓意是什么？您需要在内存不足时捕获准确的堆转储并非常仔细地检查它。
You may want to try setting this value to generate a detailed heap dump to show you exactly what is going on.
-XX:+HeapDumpOnOutOfMemoryError
A typical "small" Java desktop application in 2011 is going to run with ~64-128MB. Unless you have a really pressing need, I would start by leaving it set to the default (i.e. no setting).
If you are trying to do something different (e.g. run this on an Android device), you are going to need to get very comfortable with profiling (and you should probably post with that tag).
Keep in mind that your 100 record cache (~12 bytes) may (probably) is double that if you are storing character data (Java uses UCS-16 internally).
RE: the "unstability", the JVM is going handling memory usage for you, and will perform garbage collection according to whatever algos it chooses (these have changed dramatically over the years). The graphing may just be an artifact of the tool and the sample period. The performance in a desktop app is affected by a huge number of factors.
As an example, we once had a huge memory "leak" that only showed up in one automated test but never showed up in normal real world usage. Turned out the test left the mouse hovering over a tool tip which included the name of the open file, which in turn had a set of references back to the entire (huge) project. Wiggling the mouse a few pixels got rid of the tooltip, which meant that the references all cleared up and the garbage collector took out the trash.
Moral of the story? You need to capture the exact heap dump at time of the out-of-memory and review it very carefully.
为什么要将最大堆大小设置为 4 MB？ Java 通常是内存密集型的，因此将其设置在如此低的水平可能会导致灾难。
它还取决于您的代码创建和销毁了多少对象，以及底层 Swing（我假设）组件使用组件来绘制元素，以及每次重绘组件时如何创建和销毁这些元素。
查看 CellRenderer 代码，这将向您展示为什么对象经常被创建和销毁，以及为什么垃圾收集器做得如此出色。
尝试使用 Xmx 设置并查看图表如何变平。我预计 Xmx64m 或 Xmx128m 会合适（尽管来自数据库的数据量显然是一个重要的影响因素。
Why would you set your maximum heap size to 4 megabytes? Java is often memory intensive, so setting it at such a ridiculously low level is a recipe for disaster.
It also depends on how many objects are being created and destroyed by your code, and the underlying Swing (I am assuming) components use components to draw the elements, and how these elements are created and destroyed each time a components is redrawn.
Look at the CellRenderer code and this will show you why objects are being created and destroyed often, and why the garbage collector does such a wonderful job.
Try playing with the Xmx setting and see how the charts flatten out. I would expect Xmx64m or Xmx128m would be suitable (although the amount of data coming out of your database will obviously be an important contributing factor.
如果您使用双缓冲区，则具有扩展屏幕的 GUI 可能需要超过 4Mb。这将生成 UI 的多个图像。这样做是为了在屏幕上快速显示它们。通常这是在假设您有大量内存的情况下完成的。
锯齿内存分配是由于正在执行某些操作，然后进行垃圾收集。这可能是在重绘操作或其他计时器上。您的代码中是否有计时器来检查某些进程或正在更改的值。或者您是否已将代码添加到对象重绘或其他过程中？
You may need more than 4Mb for a GUI with an expanded screen if you are using a double buffer. This will generate multiple image of the UI. It does this to show them quickly on the screen. Usually this is done assuming you have lots and lots of memory.
The Sawtooth memory allocation is due to something being done, then garbage collected. This may be on a repaint operation or other timer. Is there a timer in your code to check some process or value being changed. Or have you added code to a object repaint or other process?
我认为 4mb 对于除了一个简单的程序之外的任何东西来说都太小了 - 例如，许多 GUI 库（包括 Swing）将需要为图形分配临时工作空间，而单独的图形工作空间可能会超过该数量。
如果您想避免内存不足错误，但也想避免向 JVM 过度分配内存，我建议设置较大的最大堆大小和较小的初始堆大小。
通常会很大，例如 256mb
小得多，4mb 就可以了 -
但请记住，如果应用程序需要更多
除此之外会有一个临时的表演
调整大小时点击
I think 4mb is too small for anything except a trivial program - for example lots of GUI libraries (Swing included) will need to allocate temporary working space for graphics that alone may exceed that amount.
If you want to avoid out of memory errors but also want to avoid over-allocating memory to the JVM, I'd recommend setting a large maximum heap size and a small initial heap size.
generally be quite large, e.g. 256mb
much smaller, 4mb should work -
though remember that if the application needs more
than this there will be a temporary performance
hit while it is resized