java 没有垃圾收集的 JVM
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2980019/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JVM with no garbage collection
提问by H-H
I've read in many threads that it is impossible to turn off garbage collection on Sun's JVM. However, for the purpose of our research project we need this feature. Can anybody recommend a JVM implementation which does not have garbage collection or which allows turning it off? Thank you.
我在很多线程中都读到过在 Sun 的 JVM 上关闭垃圾收集是不可能的。但是，出于我们研究项目的目的，我们需要此功能。任何人都可以推荐一个没有垃圾收集或允许将其关闭的 JVM 实现吗？谢谢你。
采纳答案by Stephen C
I wanted to find a fast way to keep all objects in memory for a simple initial proof of concept.
我想找到一种将所有对象保存在内存中的快速方法，以进行简单的初始概念证明。
The simple way to do this is to run the JVM with a heap that is so large that the GC never needs to run. Set the -Xmxand-Xmsoptions to a large value, and turn on GC logging to confirm that the GC doesn't run for the duration of your test.
执行此操作的简单方法是使用大到 GC 永远不需要运行的堆运行 JVM。将-Xmx和-Xms选项设置为较大的值，并打开 GC 日志记录以确认 GC 不会在测试期间运行。
This will be quicker and more straightforward than modifying the JVM.
这将比修改 JVM 更快、更直接。
(In hindsight, this may not work. I vaguely recall seeing evidence that implied that the JVM does not alwaysrespect the -Xmssetting, especially if it was really big. Still, this approach is worth trying before trying some much more difficult approach ... like modifying the JVM.)
（事后看来，这可能行不通。我依稀记得看到暗示JVM并不总是尊重-Xms设置的证据，特别是如果它真的很大。不过，在尝试一些更困难的方法之前，这种方法值得尝试......比如修改JVM。）
Also, this whole thing strikes me as unnecessary (even counter-productive) for what you are actually trying to achieve. The GC won't throw away objects unless they are garbage. And if they are garbage, you won't be able to use them. And the performance of a system with GC disabled / negated is not going to indicative of how a realapplication will perform.
此外，这整件事让我觉得对于您实际想要实现的目标来说是不必要的（甚至适得其反）。GC 不会丢弃对象，除非它们是垃圾。如果它们是垃圾，您将无法使用它们。并且禁用/否定GC 的系统的性能不会指示实际应用程序的性能。
UPDATE- From Java 11 onwards, you have the much simpler option of using the Epsilon (no-op) garbage collector; see
更新- 从 Java 11 开始，您可以更简单地选择使用 Epsilon（无操作）垃圾收集器；看
You add the following options when you launch the JVM:
在启动 JVM 时添加以下选项：
-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC
When the heap is filled, no attempt is made to collect garbage. Instead, the Epsilon GC terminates the JVM.
当堆填满时，不会尝试收集垃圾。相反，Epsilon GC 会终止 JVM。
回答by aioobe
Depending on your needs this could perhaps work:
根据您的需要，这可能有效：
Using the -Xbootclasspath option you may specify your own implementation of API classes. You could then for instance override the implementation of Object, and add to the constructor, a globalList.add(this)to prevent the objects from being garbage collected. It's a hack for sure, but for simple case-study it's perhaps sufficient.
使用 -Xbootclasspath 选项，您可以指定您自己的 API 类实现。例如，您可以覆盖 Object 的实现，并在构造函数中添加 aglobalList.add(this)以防止对象被垃圾收集。这肯定是一个 hack，但对于简单的案例研究来说，这可能就足够了。
Another option is to take an open source jvm and comment out the parts that initiate garbage collection. I would guess it is not that complicated.
另一种选择是采用开源 jvm 并注释掉启动垃圾收集的部分。我想它并没有那么复杂。
回答by Yuval Adam
Sun's JVM has no such option. AFAIK, no other JVM has this option either.
Sun 的 JVM 没有这样的选项。AFAIK，没有其他 JVM 也有这个选项。
You did not state what it is that you are exactly trying to achieve but you have one of two options: either use a profiler and see exactly what the GC is doing, that way you can take its effects into consideration. The other is to compile one of the JVMs from source, and disable GC from there.
您没有说明您究竟想要实现什么，但您有以下两种选择之一：使用分析器并准确查看 GC 正在做什么，这样您就可以考虑其影响。另一种方法是从源代码编译其中一个 JVM，并从那里禁用 GC。
回答by Erwin Smout
Maybe you could try making your VM's available memory sufficient for GC never to be run.
也许您可以尝试使您的 VM 的可用内存足以让 GC 永远不会运行。
My (allbeit limited) experience leads me to suggest that the VM is, by default, extremely lazy and extremely reluctant to run GC.
我（尽管有限）的经验让我认为 VM 在默认情况下非常懒惰并且非常不愿意运行 GC。
giving -Xmx 16384M (or some such) and making sure that your research subject stays well below that limit, might give you the environment you wish to obtain, allthough even then it will obviously not be guaranteed.
给予 -Xmx 16384M（或类似的）并确保您的研究对象远低于该限制，可能会给您提供您希望获得的环境，尽管即使如此，显然也无法保证。
回答by djna
Can you get an open source JVM and disable its GC, for example Sun's Hotspot?
你能得到一个开源的 JVM 并禁用它的 GC，例如Sun 的 Hotspot吗？
If there was no Garbage Collection what would you expect to be the semantics of code like this?
如果没有垃圾收集，您希望这样的代码语义是什么？
public myClass {
public void aMethod() {
String text = new String("xyz");
}
}
In the absence of GC any item newed and with a stack scoped reference could never be reclaimed. Even if your own classes could decide not to use local variables like this, or to use only primitive types I don't see how you would safely use any standard Java library.
在没有 GC 的情况下，任何新项目和具有堆栈范围引用的项目都无法回收。即使您自己的类可以决定不使用这样的局部变量，或者只使用原始类型，我也不知道您将如何安全地使用任何标准 Java 库。
I'd be interested to hear more about your usage scenario.
我有兴趣了解更多有关您的使用场景的信息。
回答by Trevor Tippins
Take a look at Oracle's JRockit JVM. I've seen very good near-deterministic performance on Intel hardware with this JVM and you can prod and poke the runtime using the Mission Controlutility to see how well it's performing.
看看Oracle 的 JRockit JVM。我已经看到这个 JVM 在 Intel 硬件上具有非常好的近乎确定性的性能，您可以使用Mission Control实用程序来刺激和戳运行时，看看它的性能如何。
Though you can't turn GC off completely, I believe that you can use the -Xnoclassgcoption to disable the collection of classes. The GC can be tuned to minimize latencyat the expense of leaving memory consumption to grow. You may need a license to drop the latency as low as you need if you're going this route.
虽然您不能完全关闭 GC，但我相信您可以使用-Xnoclassgc选项来禁用类的集合。可以调整 GC 以最小化延迟，但代价是内存消耗会增加。如果您要走这条路线，您可能需要获得许可才能将延迟降至最低。
There is also a Realtime version of the JRockit JVM available but I don't think that there is a free-to-developers version of this available.
还有一个 JRockit JVM 的实时版本可用，但我认为没有免费的开发人员可用版本。
回答by Peter Lawrey
You can only turn off the GC if its not actually needed (otherwise your application would run out of memory) and if you didn't need to GC, it shouldn't run anyway.
您只能在实际上不需要时关闭 GC（否则您的应用程序会耗尽内存），如果您不需要 GC，则它无论如何都不应该运行。
The simplest option would be to not discard any objects, this will avoid GC being performed (And set the max memory very high so you don't run out).
最简单的选择是不丢弃任何对象，这将避免执行 GC（并将最大内存设置得非常高，这样您就不会用完）。
You may find that you get GCs on startup and you may consider a no-GC when running acceptable.
您可能会发现在启动时会遇到 GC，并且在运行可接受时您可能会考虑使用 no-GC。
回答by Yifei Teng
There actually exists a dirty hack to temporarily pause GC. First create a dummy array in Java. Then, in JNI, use GetPrimitiveArrayCritical function to get hold of the pointer to the array. The Sun JVM will disable GC to ensure that the array is never moved and the pointer stays valid. To re-enable GC, you can call the ReleasePrimitiveArrayCritical function on the pointer. But this is very implementation specific since other VM impl may pin the object instead of disabling GC entirely. (Tested to work on Oracle Jdk 7 & 8)
实际上存在一个临时暂停 GC 的脏黑客。首先在Java中创建一个虚拟数组。然后，在 JNI 中，使用 GetPrimitiveArrayCritical 函数获取指向数组的指针。Sun JVM 将禁用 GC 以确保永远不会移动数组并且指针保持有效。要重新启用 GC，您可以在指针上调用 ReleasePrimitiveArrayCritical 函数。但这是非常特定于实现的，因为其他 VM impl 可能会固定对象而不是完全禁用 GC。（经测试可在 Oracle Jdk 7 和 8 上运行）
回答by ludenus
the question is old but for those who might be interested, there is a proposal to
这个问题很老，但对于那些可能感兴趣的人，有一个建议
Develop a GC that only handles memory allocation, but does not implement any actual memory reclamation mechanism. Once available Java heap is exhausted, perform the orderly JVM shutdown.
开发一个只处理内存分配，但不实现任何实际内存回收机制的GC。一旦可用的 Java 堆耗尽，请执行有序的 JVM 关闭。
JEP draft: Epsilon GC: The Arbitrarily Low Overhead Garbage (Non-)Collector
回答by Norman Ramsey
If I had this problem I would get IBM's Jikes Research Virtual Machinebecause:
如果我遇到这个问题，我会得到 IBM 的Jikes Research Virtual Machine，因为：
- The run-time system is written in Java itself (with special extensions)
- The whole thing was designed as a research vehicle and is relatively easy to tweak.
- 运行时系统是用 Java 本身编写的（带有特殊的扩展）
- 整个事情被设计为一个研究工具，相对容易调整。
You can't turn off GC forever, because Java programs doallocate and eventually you'll run out of memory, but it's quite possible that you can delay GC for the duration of your experiment by telling the JVM not to start collecting until the heap gets really big. (That trick might work on other JVMs as well, but I wouldn't know where to find the knobs to start twirling.)
你不能永远关闭 GC，因为 Java 程序确实会分配内存，最终你会耗尽内存，但是很可能你可以通过告诉 JVM 在堆之前不要开始收集来在实验期间延迟 GC变得非常大。（这个技巧可能也适用于其他 JVM，但我不知道在哪里可以找到开始旋转的旋钮。）
