java - -Xmx 小程序和独立 Java 进程之间的差异

Question

我有一个小程序，它需要更多或更少的内存，具体取决于客户端有多少数据。

我们通常建议使用 Java 1.6 最新版本，但我们实际上支持 Java 1.5+，因此我们在小程序中提供了保护，其中显示一个对话框，其中包含有关“内存不足”的警告以及如何增加内存的说明。内存。

但是，我真的很惊讶地发现 -Xmx 在小程序和独立进程中的工作方式不同，而且我实际上无法确定小程序是否有足够的内存。

这是如何完成的:

• 小程序接收以下参数:
  • param name="java_arguments"value="-Xmx153m"(当然这在 Java 1.6 update 10 中有效，否则在 Java 1.5 和 Java 1.6 之前的 update 10 中它将获得 64M)
  • 参数名称=“required.memory”值=“153”
• 在运行时，我们将 required.memory 与 Runtime.getRuntime().maxMemory() 进行比较
• 小程序中的限制为 153M，我们得到 143589376，但在独立应用程序中我们得到 155516928
• 153 * 1000 * 1000 = 153000000(我没有使用 1024 表示 1K，以防万一)这绝对超过 143589376。

如果我使用 0.9 的系数来避免 JVM 中的任何近似，似乎效果很好，但这是正确的值 - 0.9 吗？他们如何计算这个限制以及为什么它在独立应用程序和小程序中不同？

Answer 1

是时候深入探讨 Java 内存了。

首先，Java 中内存不足(即实际上得到 OutOfMemoryError )受到正在运行的 GC 特性的影响。

与名称所暗示的相反，您可能会得到 OutOfMemoryError，但实际上并没有耗尽内存；当运行时决定花费大量时间进行 GC 时，它也会抛出( source ，它埋在那里)。

此外，如果耗尽特定种类的内存，您可能会收到 OutOfMemoryError 错误。请记住，Java GC 是分代收集器，如果您碰巧耗尽了其中一代(我想说的是“终身”收集器，但我可能是错的)，您实际上也会耗尽内存。这意味着您可以在操作系统 View 中保留剩余的堆空间，但无法在 Java 堆上分配任何内容。

最后，与 GC 相关的一些实际开销可能会占用一些堆空间。

<小时/>

在您的情况下，更可能发生的是以下情况的一些变体:您的代码在独立上下文和小程序上下文中运行，每个上下文都有不同的安全管理器和不同的启动行为；这意味着涉及一组不同的类(它们被纳入永久代)，具有不同的依赖关系。我猜想小程序“堆栈”更厚，因为对其行为有更严格的限制，这可能解释了 maxMemory() 的大部分差异。

简而言之，可用内存的差异可能是由于 Java 运行时为其自身操作保留的内存发生了一些变化。这可能与 GC 相关、与安全策略相关，或者只是为 Applet 环境与独立环境加载的不同类。在确定返回内容时，Runtime.maxMemory() 还可能考虑上述任何“内存不足”条件。因此，0.9 值可能是一种实现副作用，将来可能会发生变化。