Java - 在运行时检测内存交换答案

【问题标题】：Java - detecting memory swapping at runtimeJava - 在运行时检测内存交换
【发布时间】：2017-04-14 13:21:17
【问题描述】：

我有一个程序并且强烈怀疑正在发生内存交换。我相信这种情况的原因是程序不时挂起。当我开始记录时，事情变得更加混乱，因为程序开始挂在不同的地方，执行不同的方法。
目前，我正在使用 32 位 IBM Java 和 2gb 专用于该程序，所以我在内存方面处于优势地位。可以更改为 x64，但在此之前：
问题 1：我可以在运行时以编程方式检测内存交换吗？或者我怎么能至少给我自己一些提示（通过日志）交换正在发生。
截至目前，我没有可用的内存使用日志，但是，如果 xx 是 2Gigs，那只是 RAM，如果发生内存交换，是否会显示我没有足够的内存？
问题2：我现在想，我可以记录垃圾收集的开始吗？我可以在运行时检测到它吗？
编辑： 说程序从数据库中导出大量数据。
EDIT2： 我可以通过编程方式禁止为给定 JVM 进行内存交换吗？

【问题讨论】：

那是操作系统的东西，不是 java 的东西
/proc/swaps 记录了此类信息。您可以通过监视文件来检测交换行为。如前所述，内存交换是由操作系统而不是应用程序决定的。
我希望你知道交换和垃圾回收是两个完全不同的东西。操作系统会在物理内存用完时进行交换，因此切换到 64 位 JVM 不会改变实际物理内存的任何内容。由于 64 位 JVM 能够使用更多内存，它甚至可能增加耗尽物理内存的机会。
我知道其中的区别，我提到 64 位 java 只是为了避免像“你需要更多内存”这样的答案。现在我的程序挂起而没有 throwig 和错误或任何失败迹象. 内存交换出现在我的脑海中，因为性能低下的 HDD 可能是导致这些挂断的原因
挂起（或非常慢）而不抛出可能表明在 GC 中花费了太多时间，总是设法在不得不再次收集之前回收少量内存，因此 GC 会考虑其操作成功，而性能却是不切实际的。此行为取决于实际的 GC 算法，例如如果 CMS 收集器检测到它在收集上花费了太多时间（> 98% iirc），它最终会抛出一个 OOME。所以Java SE HotSpot VM Garbage Collection Tuning Guide 可能会有所帮助……

标签： java memory garbage-collection jvm

【解决方案1】：

我可以在运行时以编程方式检测内存交换吗？

您可以在操作系统中监控正在使用多少交换或正在向交换分区写入多少。你如何做到这一点取决于你的操作系统>

如果发生内存交换，是否会显得我没有足够的内存？

如果您有足够的内存，就不会发生交换。注意：即使没有发生交换，更多的内存也无济于事。很可能您需要的不仅仅是应用程序内存，例如磁盘缓存也很重要。

我可以记录垃圾收集的开始吗？

您可以在另一个进程中运行，但是在停止世界操作发生时您不能运行任何东西。

可以更改为 x64，但在此之前：

Java 5.0 是我认为 32 位最好的最后一个版本。那是十年前的事了。

程序从数据库中导出大量数据。

如今，1 GB 的成本低于一杯咖啡的成本。即使是几十 GB 也不用担心。数百 GB 越来越大，如果你有几个 TB，你就会遇到一个有趣的问题。我的一些客户有 3 TB 的机器，他们有非常大量的数据，例如100 TB。

我把一台多年没用的旧电脑给了我的大女儿，她又给了我 8 岁的女儿。它有 24 GB 的内存，她主要用它来观看 youtube 视频。

我可以通过编程方式禁止 givem JVM 的内存交换吗？

您可以使用 JNI 将其锁定到内存中，但是当机器交换您的堆空间时，您的机器无论如何都处于死亡边缘。

【讨论】：