Java Out Of Memory Error
java.lang.OutOfMemoryError: Java heap space
This common error indicates that an object creation failed because there was no available heap space for it. It will never be thrown unless the JVM tries a full garbage collection first, including removal of softly/weakly referenced objects.
When the stack trace is present for this particular OOME, it is usually irrelevant – the specific allocation that could not be satisfied gives us no clue regarding previous allocations that probably caused the problem. Same with the thread where the error occured - It may occur in any thread, since they all share the same heap.
java.lang.OutOfMemoryError: PermGen space
When the permanent generation becomes full, this error occurs, regardless of the available space in the object allocation area (young + old generations).
This kind of OOME occurs in practice:
Applications which load classes dynamically, such as web servers and application containers
A class loader with a memory leak
Applications that make use of string interning, in order to improve performance or reduce heap usage
java.lang.OutOfMemoryError: unable to create new native thread
Whenever we start a a thread in Java, the JVM allocates space in native memory, designated for the thread’s call stack. This space is freed only after the thread is terminated. In case that there is not enough native memory for the stack space, we get this error.
This error is common in applications that try to manage too many live threads, For example, an application that creates a thread per connection has a scalability problem in its design. - Try to use NIO to reduce dramatically the number of threads.
When OOM occurs, usually we should check our code to detect memory leak, or reconsider application design.
We can generate java heap dump, then use IBM Heap Analyzer or Eclipse Memory Analyzer to analyze the generated heap dump.
Useful JVM flags
Use -Xms and -Xmx to set the initial and maximal heap size
-XX:+HeapDumpOnOutOfMemoryError
Output details about garbage collection
-verbose:gc and -XX:+PrintGCDetails
Track the loading/unloading of classes
-XX:+TraceClassLoading(or -verbose:class)
and -XX:+TraceClassUnloading
-Xnoclassgc would prevent GC on classes, and can easily cause this OOME in applications that keep loading classes dynamically.
Increase the maximal size of the permanent generation
-XX:MaxPermSize=512m
Modify the size of memory allocated per stack using -Xss (e.g. -Xss512k).
Other cool articles about OOM
How are Java Strings stored?
When allocating a new string, the char array contains exactly the string content. Offset is set to 0, and count is set to the char array length. Then, when calling the method substring(..) upon it, the new string being returned contains a reference to the same char array, but its offset and count members are modified, reflecting the requested subsequence of chars. The sharing of the same char array by multiple String instances is possible, since strings are immutable. There are two benefits of this implementation approach in comparison to a substring implementation based on copying:
1) Memory usage is usually reduced, especially in cases where many substrings of the same string are taken, or if the substrings are long
2) substring(..) runs in constant time, instead of linear time
Whenever we know that the original string we take the substring from has a shorter life span than the substring itself, we should consider using the copy constructor to avoid sharing of the underlying char array.
Error reported: JVMCI015:OutOfMemoryError, cannot create anymore threads due to memory or resource constraints.
The message is what is known as a native out of memeory. This is when you have hit the limits of the address space for your an application under the OS.
First Question:- How many threads are you trying to create?
Second Question:- Do you have a high rate of thread burn (do you create a lot of short lived threads)?
Common causes of this kind of OOME:
* Java heap size is set too large which robs the system of memory
* Many short lived threads are created. Each of these will take up native heap space due to the space required for their stack.
* The system itself is just running out of space due to other programs which will prevent the
JVM from having enough space to expand the native heap (used for JIT compilation, JNI malloc and creating threads).
The JVM maintains two memory areas, the Java heap and the native (or system) heap. These two heaps have different purposes and are maintained by different mechanisms.
The Java heap contains the instances of Java objects and is maintained by Garbage Collection.
The maximum size of the Java heap is preallocated during JVM startup as one contiguous area.
The native, or system heap, is allocated by using the underlying malloc and free mechanisms of the operating system, and is used for the underlying implementation of particular Java objects; for example:
* Motif objects required by AWT and Swing
* Buffers for data compression routines, which are the memory space that the Java Class Libraries require to read or write compressed data like .zip or .jar files.
* Malloc allocations by application JNI code
* Compiled code generated by the Just In Time (JIT) Compiler
* Threads to map to Java threads
Resources:
