I was just contacted concerning this Java memory problem, here is how you can get rid of it.

The amount of Ram for an Java application is limited by the JVM. To provide more memory to a single application you can start your Java process with two more parameters, like:

This allows Java to use up to 1024 MB. Here -Xms specifies the initial heap size, while -Xmx determines the maximum size. For machines with much more mem you might use g instead of m to set the size in gig’s. So -Xmx10g limits the amount of RAM to 10 GB.

Of course it’s annoying to apply these parameters to all your Java runs, so to change this behavior user-wide, you may create an alias like:

or better: Tell it to the Java Plugin Control Panel! Using Xfce you can find this tool in your panel’s menu in the Settings section. Gnome users may look in System > Preferences. If you don’t want to move your mouse you can also run ControlPanel from your terminal. This opens a window, default parameters can be applied in the tab Java, click View… and add your parameters to the Runtime Parameters column. This tool afterwards writes something like the following line to \$HOME/.java/deployment/deployment.properties :

So advanced users craving for trouble may edit this file on it’s own :-P

You can actively support me!

It’s a very bad Idea setting Xms to 1024M or 10G. When you’re starting two or three java-programs, the system-memory is nearly done. Normal users don’t have more than 4 or 8 GB RAM. Unnormal users know how big java’instances of the used programs are at most and they know this parameters.

Something else: on Google’s Android up to 2.2 the Xmx parameter is fixed to 16 MB or 32 MB, when you’re using manufactors operatingsystem. If you have Cyanogen Mod or something else you can set it up to 64 MB at most.

PS: good Denglisch^^

OutOfMemory errors can be caused by several things:

Overcache, not well tuned JVM startup options, permgen out of memories, HttpSessions not purging or low frequency purge, or buggy code.

Usually buggy code is the most typical one (80 % of the time or more), which is called a memory leak. Basically it happens because in some part of your code someone is adding elements -typically to a static collection/map- and never removes it. This preventing the GC to free up memory.

It is important to notice that increasing Memory space, if this is the case is not fixing anything: just delaying the problem to appear, but degrading your performance as well because of major GC work (more memory to clean).

Often this is is shown after some hour of heavy load conditions, or after several days running and finishes with a java.lang.OutOfMemoryError, or server crash after several hours of really low performance, and heavy load CPU conditions (because GC cycles increase).

It is really hard to deal with these problems. My suggestion is to use one of the next mechanisms:

1) Downloading some sort of memory dumps, enable app server memory dumps, and wait for the OutOfMemory to appear one more time

2) Using some byte code instrumentation tool that can quickly identify potential leaks, even if you do not get the OutOfMemoryError. I have been using Antorcha Memory Plumber light, a free handy tool from Lucierna APM during this week with excellent results. http://ctoblog.lucierna.com/ultimate-weapon-lucierna-kill-memory-leaks/

Hope this can be useful for all the users.

OutOfMemoryError is a tricky one , by the way here is my way of solving 2 solution of java.lang.outofmemoryerror java heap space