Question

With trial and error, i learned that 11_451_104 is the magic number, which causes my machine to throw the OOM error.

Using 11_451_103, i am packing with as much data as it can hold.

private static void init() {
    int i = 0;
    try {
        while (++i < 11451104) {
            list.add("a");
        }
    } catch (OutOfMemoryError e) {
        System.out.println("oh no, not again :("); // <-- Not getting here
    }
}

If on the next line i do

    String x = "some new string";

I would expect an exception to occur, as heap can’t allocate space for 1 more string. And yet, it does not.

If i try to add this new string to the list,

    String x = "some new string"; // <-- expect OOM Error to happen here
    list.add(x);

Program does abort with OOM. Why did not this happen upon string allocation?

How to best protect oneself knowing that OOM is a possibility, as unknown (possibly very big) amount of data may need to be held? Is serialization and persistence to disk a way to go to handle this?

Answer 1

Why did not this happen upon string allocation?

The list.add(...) method may also be allocating memory. If the list is an LinkedList then each add call creates a new list node. If it is an ArrayList, then add may cause the backing array to be reallocated.

(UPDATE – and I just noticed that you are not even creating new string objects. You are continually adding the same literal string "a" to the list, and that guarantees that the OOME won’t occur in string allocation!)

How to best protect oneself knowing that OOM is a possibility …

It is tempting to try to catch and recover from an OOME, but it can be risky. The problem is that you never know for sure what your application (e.g. some library method called by your application code) was actually trying to allocate, and whether or not the Error occurred at an inconvenient time and has left some important data structure in a partial or inconsistent state. Your application may therefore not be in a fit state to attempt to recover.

In general, the safest thing to do when you get an OOME is to cause the application to exit immediately. Don’t try to commit transactions, etc. Let the database’s automatic rollback clean up any uncommitted transactions when your application’s database connection socket/pipe/whatever gets closed by the OS.

In fact, the “don’t attempt to recover” advice applies to all Error exceptions. It is just that OOME’s are a case where developers are inclined to ignore the advice ‘cos they think they know better …

---

In terms of “protecting oneself”, the general solution is to keep a copy of important state safely on non-volatile storage; e.g. by writing it to a database, serializing to a flat file and so on. The specifics (e.g. which technology is best) will depend on the data, how your application uses it, and how you would make your application restartable.

The problem / situation is not qualitatively different to the problem of dealing with possible application crashes, OS reboots, power failures and so on.