Java.lang.OutOfMemory is a subclass of Java.lang.VirtualMachineError that is thrown when a Java virtual machine breaks or exceeds the available resources. Obviously, OutOfMemory is thrown when the object cannot be allocated when the Java Virtual machine resource is exhausted. Unfortunately, the Java documentation does not further elaborate on the exception.
A Java Virtual machine consists of six different runtime data regions (memory regions):
1. Procedure counter (program Counter Register)
2. Java Virtual machine stack (Java VM stack)
3. Java Heap
4. Method Zone (Java VM method area)
5. Chang (Runtime Constant Pool)
6. Local methods Stack (Native method Stacks)
The program counter, also known as the PC register, is the address of the Java bytecode operation instruction that is currently being executed. (Note here: For a running Java program, each of these threads has its own PC (program counter) register, which is created when the thread starts.) The size of the PC register is a word length, so it can hold a local pointer and be able to hold a return Address.)
The Java Virtual machine stack is made up of stack frames, which are used to store the parameters, return values, and intermediate results of the thread during execution. If there is not enough memory for the Java VM Stack, or if there is not enough memory to generate a new thread, the Java virtual machine will throw outofmemoryerror.
The heap is used to store instances or arrays of Java classes. When there is not enough memory for the new instance or array, the Java virtual machine throws OutOfMemoryError.
The method area is used to store type-related information, such as constant pool, field, or method information for that type. OutOfMemoryError also occurs when there is not enough memory in the method area. (Here are some notes: Class (Static) variables in a type are also stored in the method area, a reference to ClassLoader, a reference to the class)
The run constant pool includes field references and constants. A OutOfMemoryError exception is also thrown when Chang does not have enough memory available.
The local method area is a method written by a few C + + methods that gives the JVM some method support. Similarly, OutOfMemoryError exceptions are thrown when there is no memory available.
You may see an exception that is completely different from OutOfMemoryError: Stackoverflowerror. The exception is thrown when the local memory stack or the Java Virtual machine stack exceeds the configured size. In most IBM Java virtual machines, the-XMSO command parameter controls the operating system stack thread and the local thread stack size, and the-XSS parameter controls the thread stack size of the Javs virtual machine. In some JVM vendors, such as Sun Hotspot, Java methods share stack frames through a C + + local instruction. –XSS can configure the maximum memory for a thread, the default value of the value and the platform, and the implementation vendor of the specific JVM, but generally the size of the 256k-1024k. Please refer to your JVM documentation. In another article we'll cover more about Stackoverflowerror.
Now that we know what areas of memory are causing java.lang.OutOfMemory, let's take a look at the actual error message, which is like which of the following, and how do we deal with them?
Java code
- Java.lang.OutOfMemoryError:Requested array size exceeds VM limit
[Java]View Plaincopy
- Java.lang.OutOfMemoryError:Requested array size exceeds VM limit
The exception indicates that an array requests a memory value that exceeds the size of the VM's pre-allocated memory. What should we do if we encounter this kind of exception? We need to check out the source code to make sure that there is really no dynamic or static creation of such a large array. But fortunately, the last version of the VM generally does not have this limitation.
Java code
- Java.lang.OutOfMemoryError:PermGen Space
[Java]View Plaincopy
- Java.lang.OutOfMemoryError:PermGen Space
When the perm memory area in the Java Heap is full, the JVM throws the same exception as above.
In some Java virtual machines, such as Sun's hotspot Java Virtual machine, a piece of proprietary memory for a storage class object or method object is called a permanent generation (also known as a permanent region). We can imagine how the Java GC of IBM Modeling and analysis tools is used in the perm area.
In the figure, we see that the "Max Perm" and "Used tenured" buttons show how the Perm area is used and its maximum length. We can see that the total memory used in the perm area has reached its maximum limit, which is why we get the exception of Java.lang.OutOfMemoryError:PermGen Space. If there is no memory leak, we can increase the maximum maximum value of the perm area by adjusting the-xx:maxpermsize parameter options. such as this:
-xx:maxpermsize=128m
The above option sets the maximum value of the perm area to 128Mbytes.
Okay, we have now seen the Java.lang.OutOfMemoryError exception thrown by exhausting the memory in the Java heap or the perm area of the Java heap. More surprisingly, however, when the Java virtual machine is in local memory and cannot find more available memory, it can still throw a java.langoutofmemory exception in the Java heap. So in this case, how do we determine if the exception was raised from Java heap or local memory?
In the following exception, there is no information to specify whether the OutOfMemoryError exception is thrown from Java heap or local memory:
Java code
- Jvmdump013i processed Dump Event "Systhrow", Detail "java/lang/outofmemoryerror".
[Java]View Plaincopy
- Jvmdump013i processed Dump Event "Systhrow", Detail "java/lang/outofmemoryerror".
The following exception, the Java virtual machine very friendly tells us enough information to say that the local memory is exhausted, in which the JVM describes the "Allocatedmemory failed", which indicates that the local memory allocation failed:
Java.lang.OutOfMemoryError:JVMCI026:allocatedMemory failed
The following exception, there seems to be no clue whether it is local memory or Java heap thrown exception, but fortunately we have a line number, 20, there is a source file name, Heapexhaustionsimulator.java, as if it is related to the heap, uh:
Java code
- Jvmdg274:dump Handler has processed OutOfMemory.
- Exception in thread "main" Java.lang.OutOfMemoryError
- At Heapexhaustionsimulator.main (Heapexhaustionsimulator.java:)
[Java]View Plaincopy
- Jvmdg274:dump Handler has processed OutOfMemory.
- Exception in thread "main" Java.lang.OutOfMemoryError
- At Heapexhaustionsimulator.main (Heapexhaustionsimulator.java:)
Following exceptions, it seems that there is still no clue as to whether the local memory or Java heap is thrown. However, "Sun.misc.Unsafe.allocatedMemory (Native Method)" indicates that it appears to be local memory-related.
Java code
- Exception in thread "main" Java.lang.OutOfMemoryError
- At Sun.misc.Unsafe.allocateMemory (Native Method)
- At Java.nio.directbytebuffer.<init> (Directbytebuffer.java: £©)
- At Java.nio.ByteBuffer.allocateDirect (Bytebuffer.java:288)
- At Nativememorysimulator.main (Nativememorysimulator.java: one)
[Java]View Plaincopy
- Exception in thread "main" Java.lang.OutOfMemoryError
- At Sun.misc.Unsafe.allocateMemory (Native Method)
- At Java.nio.directbytebuffer.<init> (Directbytebuffer.java: £©)
- At Java.nio.ByteBuffer.allocateDirect (Bytebuffer.java:288)
- At Nativememorysimulator.main (Nativememorysimulator.java: one)
The following exception, Java Virtual machine specified in Java Heap, throws Java.lang.OutOfMemoryError.
Java code
- Java.lang.OutOfMemoryError:Java Heap Space
- Dumping heap to java_pid6280.hprof ...
- Heap dump file created [50549348 bytes in 1.444 secs]
[Java]View Plaincopy
- Java.lang.OutOfMemoryError:Java Heap Space
- Dumping heap to java_pid6280.hprof ...
- Heap dump file created [50549348 bytes in 1.444 secs]
You've probably seen an exception like this before:
Java code
- java.lang.OutOfMemoryError:requested NNN bytes for MMMM. Out of swap space?
[Java]View Plaincopy
- java.lang.OutOfMemoryError:requested NNN bytes for MMMM. Out of swap space?
Literally, you might check the configuration size of the swap for the operating system, but the JVM does not seem to be sure if swap space is the main reason. We can check to see if the JVM is already using a lot of local memory, and we need to make sure that there is enough memory available to the JVM, and that no other process is running out of memory resources. Finally, it is necessary to try to find some mmmm related bugs.
Java code
- Java.lang.OutOfMemoryError:unable to create native thread
[Java]View Plaincopy
- Java.lang.OutOfMemoryError:unable to create native thread
The exception is to say that if you have a large number of threads, or if local memory is exhausted, new threads are thrown when they attempt to create.
What is Java Heap Dump?
We know that Java Heap is a runtime data area allocated by all class instances and array objects, in which all Java VM threads share data from the Heap during execution. Then a Java heap dump is equivalent to a snapshot generated at a particular point in time, it's like giving a busy data warehouse a photo at a given time, and we can identify which components are available at that point in time by this snapshot.
Since the Java documentation does not refer to Java heap dump, there are various descriptions of Java heap dumps in various JVM vendors. The Java heap dump of the IBM JVM, for example, provides information as large as the Java heap.
The information provided by Sun is basically a JVM Stack, running a constant pool and Java heap.
how do I generate Java Heap dumps?
Java heap dumps is typically generated automatically by the JVM, but you can also force Java heap dumps to be generated. On most IBM JVMs. Java heap dumps is generated automatically before the Java heap is exhausted. On most sun company JVMs, you need to configure on the JVM to generate Java Heap dumps. If you want to generate when Java.lang.OutOfMemory appears, you need to configure the –xx:+heapdumponoutofmemoryerror parameter option on some of the Sun's distribution's JVMs. You also need to configure the –agentlib:phrof=heap=dump option to use Hprof. If the JVM provides, you can use the Jmap tool, for example: Jmap–dump 1234 will generate Java heap dump from process number 1234. You can use Jconsole to monitor memory by calling Hotspotdiagnostic Mbean and dumpheap.
If you want to crash the JVM on IBM JVMs or generate Java heap dumps for user signals, you can configure the environment variables Ibm_heapdump and ibm_heap_dump to True. such as: A sigquit signal can be sent to the IBM JVM
See your JVM documentation for more information, because the options vary depending on the platform and the vendor.
Where can I find the Java Heap dumps?
You can find the Java heap dumps under the current working directory of the JVM process, unless you specify a different directory location.
You can specify directory locations on IBM JVMS through environment variables: Ibm_heapdumpdir and _cee_deptarg.
If there is not enough space for the specified directory, or if the JVM does not obtain write permissions under the specified directory, Java Heap dumps will be generated in the operating system's temporary directory. Refer to your operating system manual for the default temporary directory location and configuration information for the operating system.
What is Java.lang.OutOfMemoryError?