我一直在分析我的应用程序的 x64 版本，因为内存使用率高得离谱，所有这些似乎都来自 JavaFX MediaPlayer，我正在正确地释放侦听器和事件处理程序。
这是鲜明的对比。
开始时的 x32 版本
现在开始是 x64 版本
x32 版本保持在 256mb 以下，而 x64 将拍摄演出；这是两个人都可以通过他们的播放列表播放的时候。
所有的代码都是一样的。
JDK：jdk1.8.0_20
JRE：jre1.8.0_20
两者都有虚拟机参数
-XX:MinHeapFreeRatio=40 -XX:MaxHeapFreeRatio=70 -Xms3670k -Xmx256m -Dsun.java2d.noddraw=true -XX:+UseParallelGC
同样的问题出现在另一个 x64 Java 应用程序上
这是一个错误还是我忽略了什么？
【问题讨论】：
标签： java memory-leaks javafx
您看到的是运行您的进程的整个 JVM 的内存使用情况。 -Xmx256m 设置仅限制应用程序可分配的最大堆空间（JVM 会强制执行）。在堆空间之外，JVM 可以将额外的内存用于许多其他目的（我相信我会在下面的列表中遗漏一些）：
PermGen，现在已被 Metaspace 取代。根据documentation，对此没有默认限制：
-XX:MaxMetaspaceSize=size
Sets the maximum amount of native memory that can be allocated for class metadata. By default, the size is not limited. The amount of metadata for an application depends on the application itself, other running applications, and the amount of memory available on the system.
堆栈空间（已用内存 =（线程数）* 堆栈大小。您可以使用 -Xss 参数来控制它
堆外空间（在您的代码中使用 ByteBuffers，或使用第三方库（如 EHCache）反过来使用堆外内存）
JNI 代码
GC（垃圾收集器需要自己的内存，这又不是堆的一部分，根据使用的收集器和应用程序内存使用情况可能会有很大差异）
在您的情况下，您看到内存使用“几乎翻了一番”，而且当您从 32 位 JVM 迁移到 64 位 JVM 时，元空间分配可能更加宽松。对于 64 位 JVM，使用 -XX:MaxMetaspaceSize=128m 可能会将内存使用量降至 512MB 以下。
【讨论】：
我不知道你的应用程序是如何实现的。
造成这种意外差异的一个可能原因是在执行垃圾回收之前可以使用多少内存。可以想象，64 位字的机器比 32 位字的机器分配的内存更多。垃圾收集器可以不那么频繁地运行，因此仍然会分配更多的垃圾内存，即使它并不是真正必要或无用的。
【讨论】：