Analyzing and Reproducing OutOfMemoryError Caused by MyBatis and DruidDataSource in a Java Backend Service

Preface

After a recent CPU alarm, the service started showing frequent OutOfMemoryError (OOM) messages in production logs, causing the service to become unavailable.

SkyWalking showed almost all traces in red, indicating a systemic failure. Operations restarted the service to restore B‑side product functionality while the root cause was investigated.

Reasons for OutOfMemoryError

The OOM originates from two main sources: insufficient heap space and insufficient metaspace.

Heap space shortage : Objects that remain strongly referenced cannot be garbage‑collected, eventually exceeding the -Xmx limit and triggering a heap OOM.

Metaspace : Introduced in Java 8 to replace the permanent generation. It resides outside the heap, storing class metadata via pointers, and can also run out of memory if not sized properly.

Common Scenarios Leading to Heap OOM

Loading excessively large result sets from the database into memory.

Infinite loops that keep large objects referenced.

Failure to release resources such as connection pools or I/O streams.

Static collections that retain references indefinitely.

These are typical cases, though real‑world issues can be more obscure.

Phenomenon Analysis

Log analysis revealed that MyBatis was the component throwing the OOM. MyBatis builds SQL strings and stores placeholders and parameters in a map; when the SQL becomes very large, the map grows dramatically and cannot be reclaimed, leading to heap exhaustion.

Because the Docker container lacked tools like jstack and jmap , and no heap dump was saved, detailed thread‑level analysis was impossible.

Online research provided clues that the issue stemmed from MyBatis’s handling of large SQL statements.

The original article "DruidDataSource and MyBatis Conspire, Causing OOM" was referenced for insight.

MyBatis keeps generated SQL placeholders and parameter objects in a Map . When many parameters produce a very long SQL, the map holds these entries for a long time, especially under concurrent queries, causing high memory consumption and OOM.

MyBatis Source Code Analysis

Inspecting the DynamicContext class shows it contains a ContextMap (a subclass of HashMap ) named bindings . The ForEachSqlNode invokes getBindings() , which puts SQL parameters and placeholders into this map. Because the map resides in heap memory, the entries cannot be garbage‑collected, and with many concurrent queries the memory usage spikes, leading to OOM.

Reproducing the Issue

To replicate the problem, the SQL concatenation was enlarged (IN clause with many parameters) and 50 threads were launched to execute it. The JVM was started with the following options:

-Xmx256m -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

The console logs showed frequent Full GC cycles, eventually leading to OOM.

Conclusion

After identifying the root cause, the next step is to optimize the SQL generation: avoid excessively large concatenated statements, limit the size of IN clauses, and consider using batch operations or prepared statements. Clean code practices and careful SQL design are essential to prevent unpredictable OOM risks.

References

[1] "DruidDataSource and MyBatis Conspire, Causing OOM": https://segmentfault.com/a/1190000021636834