JVM exceeds maximum memory defined with -Xmx

前端 未结 3 1389
暗喜
暗喜 2021-02-19 04:24

We have a Java webapp that we upgraded from Java 1.5.0.19 to Java 1.6.0.21

/usr/java/jdk1.6.0_21/bin/java -server -Xms2000m -Xmx3000m -XX:MaxPermSize=256m -Djav         


        
相关标签:
3条回答
  • 2021-02-19 04:30

    http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html

    Note that the JVM uses more memory than just the heap. For example Java methods, thread stacks and native handles are allocated in memory separate from the heap, as well as JVM internal data structures.

    So if you have a lot of threads and a lot of native handles, the memory can exceed the heap limit. Are you sure this didn't happen before as well?

    Also check out this: Java using more memory than the allocated memory

    0 讨论(0)
  • 2021-02-19 04:40

    So how could a JVM with 3GB heap, 256MB permgen, and even some overhead consume 6.9GB?

    Possible explanations include:

    • lots and lots of thread stacks,
    • memory-mapped files that are not being closed when they should be,
    • some native code library using (possibly leaking) out-of-heap memory.

    I would be inclined to blame the application before blaming the JVM.

    0 讨论(0)
  • 2021-02-19 04:48

    So long story short, my initial reaction was correct it was a bug in the JVM. We were using 1.6.0_21 and it turns out that we were experiencing the exact same error as outlined in https://confluence.atlassian.com/pages/viewpage.action?pageId=219023686. Upgrading to 1.6.0_37 fixed the problem and we went from daily crashes to 2 weeks without a crash.

    So while the sentiment to not just blame the JVM is a good policy it seems that one should also be advised not to always assume the JVM is bug free, it like all software has the occasional bug. Plus, seems good policy to keep things up to date.

    Thanks for all the help on this one!

    0 讨论(0)
提交回复
热议问题