jvm free memory space is getting smaller

Question

I use zabbix to monitor jvm's free memory space. His space is constantly decreasing. What could be caused by this? I suspect that it is a memory overflow. Is there any way to check it out? Can someone help me?

update

After I restarted jvm, I executed the command jmap -histo:live. Is there a problem with initialization here?

num     #instances         #bytes  class name
----------------------------------------------
   1:        192100       28118472  [C
   2:         10757       10132704  [B
   3:        101676        8947488  java.lang.reflect.Method
   4:        165148        5284736  java.util.concurrent.ConcurrentHashMap$Node
   5:        187677        4504248  java.lang.String
   6:         19509        3519904  [I
   7:         62802        3014496  org.aspectj.weaver.reflect.ShadowMatchImpl
   8:         57683        2307320  java.util.LinkedHashMap$Entry
   9:         18410        2044672  java.lang.Class
  10:         40274        2016656  [Ljava.lang.Object;
  11:         62801        2009632  org.aspectj.weaver.patterns.ExposedState
  12:         59849        1915168  java.lang.ref.WeakReference
  13:          1342        1774328  [Ljava.util.concurrent.ConcurrentHashMap$Node;
  14:         22572        1753560  [Ljava.util.HashMap$Node;
  15:           920        1576512  [Ljava.nio.ByteBuffer;
  16:         47884        1532288  java.util.HashMap$Node
  17:         26167        1465352  java.util.LinkedHashMap
  18:         10874        1391872  org.aspectj.weaver.reflect.ReflectionBasedResolvedMemberImpl
  19:         49720        1085320  [Ljava.lang.Class;
  20:         45193        1084632  java.util.ArrayList
  21:         13421         966312  java.lang.reflect.Field
  22:         54885         878160  java.lang.Object
  23:         16797         806256  java.util.HashMap
  24:         19297         771880  java.lang.ref.SoftReference
  25:         23315         559560  java.beans.MethodRef
  26:         17695         530192  [Ljava.lang.String;
  27:          6508         520640  java.lang.reflect.Constructor
  28:          8305         465080  java.beans.MethodDescriptor
  29:         23607         459008  [Lorg.aspectj.weaver.ResolvedType;
  30:         17430         418320  org.springframework.core.MethodClassKey

Memory leak. Take a heap dump and check what's eating your memory. — Robby Cornelissen, Sep 28 '18 at 08:32
Take a look here: https://stackoverflow.com/questions/10108942/how-to-memory-profile-in-java — Nigel Nop, Sep 28 '18 at 08:32
That spike at 09-25 10:00 indicates that this was when garbage collection happend. If you have a look at a greater period do you see a saw tooth pattern? If so that could just be normal garbage collection. — Thomas, Sep 28 '18 at 08:37
If you're new to this then use a tool such as Memory Analyser Tool (MAT) for Eclipse to analyse a heapdump taken after the memory has run low. — Andy Brown, Sep 28 '18 at 08:40
As @Thomas mentioned, you should look at a longer period of data, although the flat pattern at the beginning of the graph is suspicious - garbage collection should have kicked in sooner. — Richlv, Sep 28 '18 at 09:48
You should look at the amount used after a full GC **only**. Anything more than this is likely to be garbage which hasn't been collected yet. — Peter Lawrey, Oct 01 '18 at 19:02

score 1 · Answer 1 · answered Sep 28 '18 at 16:37

This looks like a very normal memory usage graph for a Java application. As one of the comments points out, at 09:00 the JVM ran the garbage collector and that resulted in a lot of memory being freed. You don't provide the parameters you used to start your JVM so it's not clear what size your heap is (at a guess I would say 2Gb). Getting the free space back to 1.5Gb after a GC is fine. The subsequent slow decrease in free space afterwards is your application allocating objects to do whatever it needs to do. My guess would also be that if you showed the graph of the application running for longer you would get another spike when the GC runs again.

So short answer is this is what the JVM is supposed to do. If the application continues to run (i.e., you don't get an OutOfMemoryError) then everything is fine.

jvm free memory space is getting smaller

1 Answers1