员工体检费计入什么科目

java.lang.OutOfMemoryError: Java heap space indicates insufficient heap memory, and needs to check the processing of large objects, memory leaks and heap settings, and locate and optimize the code through the heap dump analysis tool; 2. Metaspace errors are common in dynamic class generation or hot deployment due to excessive class metadata, and MaxMetaspaceSize should be restricted and class loading should be optimized; 3. Unable to create new native thread Due to exhausting system thread resources, it is necessary to check the number of threads, use thread pools, and adjust the stack size; 4. GC overhead limit exceeded means that GC is frequent but has less recycling, and GC logs should be analyzed, the object life cycle should be optimized, and the G1GC and other recyclers should be replaced; 5. Requested array size exceeds VM limit is caused by array length overflow, and the length logic needs to be verified to avoid integer overflow, and large files are processed using streaming; Summary: Heap dump and GC log should be enabled, combined with analysis tool troubleshooting, and resource management problems should be solved from the code design level, rather than just increasing memory, so as to fundamentally solve the OOM problem.

Java OutOfMemoryError is a common critical error at runtime, usually indicating that the JVM cannot allocate objects because the heap memory or other memory areas are exhausted. Although the error message may seem simple, there are many reasons behind it. The following are several common OutOfMemoryError scenarios and their troubleshooting and solutions.

1. java.lang.OutOfMemoryError: Java heap space

This is the most common type, indicating that the heap memory is insufficient to allocate new objects.

Common reasons:

• The application loads a large amount of data (such as large files, caches full data).
• There is a memory leak (such as the constant addition of objects in static collections is not cleaned).
• The heap memory settings are too small to meet normal business needs.

Troubleshooting steps:

• View error log : Confirm whether it is triggered when processing large objects or batch data.
• Monitor using JVM parameters :

   -Xmx2g -Xms2g -XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps

  This generates a heap dump file (heap dump) when OOM.

  
• Analyze heap dump : Use tools such as Eclipse MAT or VisualVM to open the .hprof file to find the objects that consume the most memory and their reference chains.
• Check the code : Focus on:
  • Whether static Map and List grow infinitely.
  • Whether the cache lacks an expiration mechanism (it is recommended to use caches with obsolete strategies such as WeakHashMap or Caffeine ).
  • Whether to load large files or database full table data at one time.

Solution:

• Increase heap memory (temporary solution):

   -Xmx4g

• Fix memory leak code.
• Pagination processing of big data to avoid one-time loading.

2. java.lang.OutOfMemoryError: Metaspace

JDK 8 and later, PermGen is replaced by Metaspace to store metadata of classes.

Common reasons:

• The application dynamically generates a large number of classes (such as using CGLIB, ASM, dynamic proxy, Groovy scripts, etc.).
• Deploy a large number of WAR applications (such as Tomcat hot-deployed class loaders not cleaned).
• The metaspace size is not limited or is set too small.

Troubleshooting method:

• Add JVM parameters to observe Metaspace usage:

   -XX:MaxMetaspaceSize=512m -verbose:gc -XX: PrintGCDetails

• Use jstat -gc <pid> to view MCMN , MCMX , MC (Metaspace capacity) and other indicators.
• Generate and analyze the heap dump (although Metaspace is not in the heap, it can help judge the class loading situation).

Solution:

• Setting a reasonable MaxMetaspaceSize prevents unlimited growth.
• Check for frequent class loading/unloading, especially for hot deployment scenarios.
• Optimize GC behavior with -XX: UseG1GC and -XX:MetaspaceSize=256m .
• Avoid overuse of runtime bytecode generation.

3. java.lang.OutOfMemoryError: Unable to create new native thread

The JVM attempts to create a new thread, but the operating system cannot allocate native thread resources.

Common reasons:

• The number of threads exceeds the system limit ( ulimit -u user process limit).
• The system memory is insufficient, and each thread takes up 1MB of stack space by default ( -Xss ).
• The application has created too many threads (such as thread pool not being used, thread leakage).

Troubleshooting method:

• Check the current number of threads:

   ps -eLf | grep java | wc -l

• View system restrictions:

   ulimit -u # max user processes
  cat /proc/sys/kernel/threads-max

• Check the JVM thread dump:

   jstack <pid> > thread_dump.txt

  Check if there are a large number of similar threads or threads that are not ending.

Solution:

• Use a thread pool (such as ThreadPoolExecutor ) instead of manually creating threads.
• Resize thread stack (careful):

   -Xss256k # Reduce memory per thread stack

• Increase system restrictions (administrator permission required):

   ulimit -u 65535

• Check whether any thread is not closed correctly (such as executor.shutdown() not being called).

4. java.lang.OutOfMemoryError: GC overhead limit exceeded

The JVM spends a lot of time doing GC (more than 98%), but recycles very little memory (less than 2%), and this error is automatically thrown.

Common reasons:

• There are a large number of "slow death" objects in the heap, with frequent GCs but poor results.
• Out of memory or memory leaks lead to tight free space.

Troubleshooting method:

• Enable GC logging:

   -Xlog:gc*,gc heap=debug:file=gc.log:time

• Analyze the GC frequency and recovery volume in the log.
• Combined with heap dump to view object distribution.

Solution:

• Increase heap memory.
• Optimize the object life cycle and avoid holding useless objects for a long time.
• Use more efficient garbage collectors such as G1GC or ZGC instead:

   -XX: UseG1GC

• Check whether large objects are frequently created (such as large strings, large arrays).

5. java.lang.OutOfMemoryError: Requested array size exceeds VM limit

Try to create an array that exceeds the JVM limit (such as new int[Integer.MAX_VALUE] ).

Common reasons:

• The integer overflows when calculating the array size, resulting in a negative number or maximum value requested.
• Data processing logic is wrong, mistakenly treating the file size as the length of the array.

Example:

 int size = (int) file.length(); // When the file is larger than 2GB, it will be forced to negative byte[] data = new byte[size]; // OOM may be triggered

Solution:

• Use long to determine the data size and limit the maximum allocation.
• Use streaming large files to avoid loading at once.
• Check the array length calculation logic to prevent overflow.

Summary of suggestions

When encountering OutOfMemoryError , don't just turn the memory into the problem. Key steps include:

• ? Enable -XX: HeapDumpOnOutOfMemoryError
• ? Add GC logs and thread dump capabilities
• ? Use analysis tools (MAT, VisualVM, jstat, jstack)
• ? Review collections, caches, threads, IO processing logic in code

The essence of most OOM problems is improper code design or resource management, and only reasonable configuration and careful investigation can be solved.

Basically all is it, not complicated but it is easy to ignore details.

The above is the detailed content of Troubleshooting Common Java `OutOfMemoryError` Scenarios. For more information, please follow other related articles on the PHP Chinese website!