java.lang.OutOfMemoryError: Out of swap space?
Java applications are given limited amount of memory during the startup. This limit is specified via -Xmx and other similar parameters. In situations where the total memory requested by the JVM is larger than the available physical memory, operating system starts swapping out the content from memory to hard drive.
The java.lang.OutOfMemoryError: Out of swap space? error indicates that the swap space is also exhausted and the new allocation is failing due to the lack of both physical memory and swap space.
Cause of java.lang.OutOfMemoryError
The java.lang.OutOfmemoryError: request
The problem occurs on situations where your Java processes have started swapping, which, recalling that Java is a garbage collected language is not a good situation per se. Modern GC algorithms do a good job, but when facing with latency issues caused by swapping, the GC pauses tend to increase to levels not tolerable by most applications.
java.lang.OutOfMemoryError: Out of swap space? is often caused by the operation system level issues, such as:
- The operating system is configured with insufficient swap space.
- Another process on the system is consuming all memory resources.
It is also possible that the application failed due to a native leak, for example, if application or library code is continuously allocating memory but is not releasing it to the operating system.
Solution of java.lang.OutOfMemoryError
To overcome this issue, you have several possibilities. First and often the easiest workaround is to increase swap space. Means for this are platform specific, for example in Linux you can achieve it similar to the following example, which creates and attaches a new swapfile sized at 640MB:
swapoff -a dd if=/dev/zero of=swapfile bs=1024 count=655360 mkswap swapfile swapon swapfile
Now, you should recall that due to garbage collection sweeping the content of memory, the swapping for Java processes is undesirable in general. Running garbage collection algorithms on swapped allocations can increase the length of GC pauses in several orders of magnitude, so you should think twice before jumping to the easy solution bandwagon.
If your application is deployed next to a “noisy neighbour” with whom the JVM needs to compete for resources, you should isolate the services to separate (virtual) machines.
And in many cases, your only truly viable alternative is to either upgrade the machine to contain more memory or optimize the application to reduce the memory footprint. When you turn to the optimization path, good way to start is via memory dump analyzers revealing the content of your memory to detect large allocations.