Stack overflow (virtual machine stack and local method stack)
The reasons causing
- In HotSpot, this can only be set by the -xSS parameter. There is no distinction between virtual machine stacks and local method stacks in HotSpot.
- There are two types of exceptions that occur when a stack overflow occurs: StackOverflowError and OutOfMemoryError.
- StackOverflowError because the stack depth of the thread request is greater than the maximum depth allowed by the virtual machine.
- OutOfMemoryError occurs when the virtual stack memory allows for dynamic expansion, and sufficient memory cannot be allocated to the extended stack.
- Because HotSpot does not support extensibility, outofMemoryErrors are generated only when memory cannot be allocated during thread creation, and stackOverflowErrors are generated.
- Conclusion: Allocating more memory to each thread’s stack is not always better. For example, if the total memory is 2 gigabytes, if one thread takes up 1.5 gigabytes, then…
solution
- When a StackOverflowError exception occurs, you have a clear error stack to analyze, making it relatively easy to locate the problem.
- If you use the Hotspot VIRTUAL machine default, the stack depth of 1000~2000 is not a problem in most cases. For normal method calls (including recursive calls that cannot be recursively optimized), That should be enough depth. However, if the memory is overloaded due to the establishment of multiple threads, without reducing the number of threads or replacing the 64-bit VIRTUAL machine, you can only exchange for more threads by reducing the maximum heap and stack size.
Stack overflow
The reasons causing
- Overflow occurs when the total capacity hits the maximum heap capacity as objects are constantly created and garbage collection is avoided.
- Run code: set vm parameters -xMS10m -XMx10m
public class HeapTest { static class OOMObj{ } /** * vm arg -Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError */ public static void main(String[] args) { List<OOMObj> oomObjList = new ArrayList<OOMObj>(); while (true){ oomObjList.add(new OOMObj()); }}}Copy the code
- Results:
solution
- First, the memory image analysis tool is used to confirm whether there is a memory leak or a memory overflow.
- If there is a memory leak, the object causing OOM is not necessary. Further check the GC Roots reference chain with the tool. General can be more accurate positioning.
- If it is out of memory and the object must survive, check the vm heap parameters -xMS and -xmx Settings and compare the machine memory to see if there is room to increase. Then from the code to check the object life cycle, holding state time, storage structure is not reasonable design and so on.
Method area and runtime constant pool overflow
The reasons causing
- The conditions for a class to be collected by the garbage collector are more stringent. This should be of particular concern in application scenarios where large numbers of dynamic classes are generated at runtime.
solution
- HotSpot in JDK8 already uses meta-space entirely instead of permanent strips. Hotspot provides a number of parameters for meta-space defense measures, including:
- XX:MaxMetaspacesize: Sets the maximum value of the metasize space. The default value is -1, that is, the local memory size is not limited.
- -xx :Metaspacesize: Specifies the initial size of the meta-space, in bytes. If this value is reached, garbage collection will be triggered for type offloading. The collector will adjust this value. If very little space is freed, increase this value appropriately, up to -xx :MaxMetaspaceSize (if set).
- -xx :MinMetaspace Free Ratio: Controls the percentage of remaining metaspace capacity after garbage collection, reducing the frequency of garbage collection due to insufficient metaspace capacity. Similarly, -xx: max-metaspacefreeratio, which controls the percentage of the maximum remaining capacity of a meta-space.
Native direct memory overflow
The reasons causing
- A similar problem occurs when ByteBuffer’s allocateDirect method is used directly or indirectly, rather than when clear is used. The obvious feature is that you don’t see significant exceptions in Heap Dump files.
solution
- Setting parameters: -xx :MaxDirectMemorySize