当 JVM 在运行时分配完 memory 时会发生什么？

Question

After thinking for a long time of a generic way to pose this question (and failing to find one) I'm just going to ask it as a concrete example:

Suppose I have a Linux machine which has 1 Gb of memory which it can allocate to processes (physical and swap totals 1 Gb).

I have a standard Oracle Hotspot JVM version 7 installed on the machine. If at a given moment, there are enough programs running such that only 400 Mb of that 1 Gb are free, and I start a Java program at that moment with the following JVM flags:

java -Xms256m -Xmx512m -jar myJar.jar

what happends? :

A. does the JVM fail to start right away because it will try to allocate all of the 512 Mb of memory and fail (due to the fact that there's not enough available memory at the moment)?

if the JVM starts:

if at some point the running Java process will need more than 400 Mb of memory (and there's still only 400 Mb of memory that's free other than what the current Java process has already used), what will happen:

B. will the Java process fail with an OutOfMemroyError?

C. will it fail with some other (standard) error?

D. is it undefined behavior?

Answer 1

-Xmx just defines the maximum size of the heap. It makes no guarantee on wether there is so much memory or not. It only ensures that the heap will never be bigger then the given value. That said, Option B.) will happen, an outOfMemoryError will be thrown.

Answer 2

Suppose I have a Linux machine which has 1 Gb of memory which it can allocate to processes (physical and swap totals 1 Gb).

My first response would be, unless you are talking about a phone, I would get more memory. You can buy 16 GB (b = bit, B = byte) for less than $100.

does the JVM fail to start right away because it will try to allocate all of the 512 Mb of memory and fail (due to the fact that there's not enough available memory at the moment)?

This can happen if your system does not have 512 MB (plus some overhead) as it allocates the continuous virtual memory used for the heap on startup.

Even if you have 550 MB free, the program could fail to start as it need to load more than just the heap.

will the Java process fail with an OutOfMemoryError?

This can happen if your program uses 512 MB while running, regardless of the amount of memory your machine has. This error will only occur after your JVM has started. You won't get this error if it cannot start.

will it fail with some other (standard) error?

This is possible if you run out of swap space after the program has started. It is rare and only happens on a severely overloaded machine. What I have seen is the JVM crashes due to a low level OS failure to allocate memory.

Java 6 Update 25 VM crash: insufficient memory

Answer 3

OutOfMemroyError will be "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector."

So, in essence, "B. The Java process fail with an OutOfMemroyError " .

Answer 4

If you have so much occupied memory that the free space cannot even sustain an idle JVM, you would get either some error saying the program has not enough memory, or the JVM would crash.

If you can run the JVM, you can specify the limit on heap space with -Xmx. That doesn't mean all the heap will be allocated by JVM on start - it is only an internal limit. If the JVM will want to increase the heap space, but there is not enough memory, or you need more heap than specified by -Xmx, you will get OutOfMemoryError in currently running Java programs.

In a very extreme condition, you can run out of free memory while the JVM is running, and at the same time the JVM requires more memory for its internal operation (not the heap space) - then the JVM tells you it needed more memory, but could not get any, and terminates, or it will crash outright.

Answer 5

The JVM process will run in virtual memory, so the question of allocation of other processes running is relevant, but not completely determinitive.

When the JVM cannot allocate more memory (for whatever reason), the process itself doesn't terminate, but rather starts throwing OutOfMemoryError within the JVM, but not external to the JVM. In other words, the JVM continues to run, but the programs running within the JVM will usually fail, because most don't handle low memory conditions adequately. In this fairly common case, when the program does not do anything to handle the error, the JVM will terminate the program and exit. Ultimately, this is from the memory allocation, but not directly so. It's possible for a piece of code to scale itself back under low memory condition and continue to run.

And others have pointed out, it happens sometimes that the JVM itself doesn't handle low memory well, but this is a pretty extreme condition.

Answer 6

Despite the question being 10 years old, i was also thinking about this just today and decided to actually try this out. :-)

• Linux version Linux version 5.10.0-0.bpo.9-amd64
• JVM version OpenJDK Runtime Environment (build 11.0.14+9-post-Debian-1deb10u1)

Using this small test program:

import java.util.*;

public class OOMTest {
    public static void main(String... atgs){
        var list = new ArrayList<String>();
        while(true){
            list.add(new String("abc"));
        }
    }
}

on a machine having 4G of RAM and 4G swap (this is just my NAS:-) ):

tomi@unyanas:~/workspace$ free -h
              total        used        free      shared  buff/cache   available
Mem:          3.7Gi       980Mi       2.4Gi        27Mi       355Mi       2.4Gi
Swap:         3.7Gi       2.2Gi       1.5Gi

• when running with 1G heap allowed, the process dies with an OOM:

tomi@unyanas:~/workspace$ java -Xmx1G OOMTest
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at OOMTest.main(OOMTest.java:9)

• when running with 10G heap allowed, then:
  • the process starts as stated above, despite not having that much RAM+swap in the machine at all
  • but the output is clearly not an OOM, the process is just being killed by the kernel:

tomi@unyanas:~/workspace$ java -Xmx10G OOMTest
Killed

So to summarize:

• getting an OOM when the host runs out of memoery is at least not guaranteed (i got this outcome 3 times out of 3 tries)
• "overcommiting" the machine capacity with -Xmx is allowed
• it really seems to be the case that getting an OOM is only guaranteed as long as the "cap" on the process is the -Xmx value (either the default or specified explicitely), but otherwise there would be more free memory (RAM+swap) left to the OS

For the above one can say that this situation was created by the fact that the test code would have infinit memory footprint, so i also wanted to try if a process with high generation rate, but otherwise finit memory footprint can be made fail by setting a too high -Xmx value. So if the GC can be fooled to believe that there is a lot more memory available than really is and in the end be killed, or if it will be notified by the kernel about failed OS level memory allocations and hence restrict the heap size. And the answer is that it can be fooled.

i've altered the above code like this:

import java.util.*;

public class OOMTest {
    public static void main(String... atgs){
        var list = new ArrayList<String>();
        while(true){
            list.add(new String("abc"));
            if (list.size() > 50000000){
                list.remove(list.size() - 1);
            }
        }
    }
}

When specifyint an -Xmx value that the machine can handle, the program could run any long (well i really let it run as long as i was having dinner, but you get the point:-) )

So this never exits (when enabling GC logging, once the 2G heap size is reached, a nice repeating pattern can be observed):

java -Xmx2G OOMTest

But when running with Xmx10G, the process is killed again, wihtout an OOM:

tomi@unyanas:~/workspace$ java -Xmx10G OOMTest
Killed

This suggests that the only "constructive feedback" the JVM gets when it attempts to allocate more memory than currently available on the host as RAM+swap is something like a kill -9. And hence by using too high -Xmx values a process that would otherwise function correctly can be made fail. This is by no means to say that this would happen on all OS-es, JVM implementations or even just GC algorithms (i was using the default G1), but this was definitely the case with the above set up.