Java is not able to collect garbages in time

Question

I have such problem that jvm is not able to perform gc in time and application freezes. "Solution" for that is to connect to application using jconsole and suggest jvm to make garbage collections. I do not have to say that it is very poor behavior of application. Are there some option for jvm to suggest to it to perform gc sooner/more often? Maybe there are some other real solution to this problem?

The problem appears not to be not enough of memory but that gc is not able to do collection in time before new data is send to application. It is so because gc appears to start to collect data to late. If is is suggested early enough by System.gc() button of jconsole then problem does not occur.

Young generation is collected by 'PS Scavenge' which is parallel collector. Old generation is collected by 'PS MarkSweep' which is parallel mark and sweep collector.

you can tune GC - [Link 1](http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html) — Subhrajyoti Majumder, Sep 10 '13 at 11:28
You should tell more about your environment. What is the heap size?, what is expected load?. The problem may be in your code or it may be in your environment. — Manish, Sep 10 '13 at 11:30
Have you tried running your code with `-verbose:gc` to monitor garbage collections? — assylias, Sep 10 '13 at 14:01
@assylias I am afraid I can not interfere that much with production environment :( — Trismegistos, Sep 10 '13 at 14:04
@Trismegistos: then you'll have to reproduce the problems in a test environment and enable that switch there. — Joachim Sauer, Sep 10 '13 at 14:15

Theodoros Chatzigiannakis · Answer 1 · 2013-09-10T13:54:08.567

2

There is System.gc() that does exactly what you described: It suggests to the JVM that a garbage collection should take place. (There are also command-line arguments for the JVM that can serve as directives for the memory manager.)

However, if you're running out of memory during an allocation, it typically means that the JVM did attempt a garbage collection first and it failed to release the necessary memory. In that case, you probably have memory leaks (in the sense of keeping unnecessary references) and you should get a memory profiler to check that. This is important because if you have memory leaks, then more frequent garbage collections will not solve your problem - except that maybe they will postpone its manifestation, giving you a false sense of security.

From the Java specification:

OutOfMemoryError: The Java Virtual Machine implementation has run out of either virtual or physical memory, and the automatic storage manager was unable to reclaim enough memory to satisfy an object creation request.

edited Sep 10 '13 at 13:54

answered Sep 10 '13 at 11:31

Theodoros Chatzigiannakis

28,773
8
68
104

2

Calling `System.gc()` is almost always a non-solution. Indeed, it will typically make your application less responsive while not helping at all with the OOMEs. – Stephen C Sep 10 '13 at 11:50
In fact I believe many JVM implimentations simply ignore System.gc() calls – Richard Tingle Sep 10 '13 at 13:02
The problem appears not to be not enough of memory but that gc is not able to do collection in time before new data is send to application. It is so because gc appears to start to collect data to late. If is is suggested early enough by System.gc() button of jconsole then problem does not occur. – Trismegistos Sep 10 '13 at 13:16
2

@Trismegistos Please see my edit. A GC cycle definitely occurs before the resorts to throwing the OOME, *unless your JVM isn't compliant to the Java specification* (which is unlikely). From your description, it looks like you haven't actually verified that the collection does *not*, in fact, happen - so verify that first. – Theodoros Chatzigiannakis Sep 10 '13 at 13:57

score 2 · Answer 2 · answered Sep 10 '13 at 11:34

2

You should check for memory leaks. I'm pretty sure you won't get OutOfMemoryException unless there's no memory to be released and no more available memory.

answered Sep 10 '13 at 11:34

strikerbs

21
2

By memory leaks I assume you mean hanging on to references for longer than you need them. A real memory leak is near to impossible in java – Richard Tingle Sep 10 '13 at 11:38
1

Yes, of course, I don't mean classic memory leaks. An example of a memory leak in java would be adding objects in a collection and not having code to remove them (e.g. storing events of a particular type). Such collections can grow infinitely and take up all your heap. – strikerbs Sep 10 '13 at 11:40
@strikerbs The web application that I've inherited has terrible software aging problems. Everything runs behind a framework, so figuring out where it might be happening is a nightmare. – Cruncher Sep 11 '13 at 19:23

score 1 · Answer 3 · answered Sep 10 '13 at 11:33

1

You can deploy java melody on your server and add your application on it, it will give you detailed report of your memory leaks and memory usage. With this you will be able to optimize your system and code correctly.

answered Sep 10 '13 at 11:33

Jhanvi

5,069
8
32
41

score 1 · Answer 4 · edited May 23 '17 at 11:56

1

I guess, either your application requires more memory to run efficiently, try tuning your JVM by setting parameters like -Xms512M -Xmx1024M. Or, There is memory leak which is exhausting the memory.

You should check the memory consumption pattern of your application. e.g. what memory it is occupying when it is processing more vs remain idle.

If you observe a constant surge in memory peaks, it could suggest towards a possible memory leak. One of the best thread on memory leak issue is How to find a Java Memory Leak

Another good one is http://www.ibm.com/developerworks/library/j-leaks/

edited May 23 '17 at 11:56

Community

1
1

answered Sep 10 '13 at 11:38

Gyanendra Dwivedi

5,511
2
27
53

The problem appears not to be not enough of memory but that gc is not able to do collection in time before new data is send to application. It is so because gc appears to start to collect data to late. If is is suggested early enough by System.gc() button of jconsole then problem does not occur. – Trismegistos Sep 10 '13 at 13:18
The JVM attempt to re-claim all sort of memory before it fails. So, it should not fail unless you have a bug in JVM implementation. Here, I believe you are using one of the standard JVM implementation or server tool. If it is so, there could be only issue with application code. Do one thing, increase the heap space parameter and watch for the OOM error. It would not occur soon, but if it occurs after a later time, it indicates towards a possible memory leak. – Gyanendra Dwivedi Sep 10 '13 at 13:40
If it was problem with memory leak or to less of memory System.gc() wouldnt help because it wouldn't be able to collect any memory. System.gc() helps though which shows that there is memory available. – Trismegistos Sep 10 '13 at 14:00
Ok.. then do one thing increase the heap size (I hope the error is not OOM - Perm Gen issue) to sufficiently large and see if your problem resolves at least temporarily. Because if it is not an issue with memory leak, the application should be running fine with a big enough memory. And must observe if the app is running fine for a longer time ; then gradually reduce the memory to see the threshold till it start having OOM issue. – Gyanendra Dwivedi Sep 10 '13 at 14:18

score 1 · Answer 5 · edited May 23 '17 at 10:25

Additionally,

you may receive an OOME if you're loading a lot of classes (let's say, all classes present in your rt.jar). Since loaded classes reside in PermGen rather than heap memory, you may also want to increase your PermGen size using -XX:MaxPermSize switch.

And, of course, you're free to choose a garbage collector – ParallelGC, ConcMarkSweepGC (CMS) or G1GC (G1).

Please be aware that there're APIs in Java that may cause memory leaks by themselves (w/o any programmer's error) -- e. g. java.lang.String#substring() (see here)

score 1 · Answer 6 · answered Sep 12 '13 at 12:37

If your application freezes, but gets unfrozen by a forced GC, then your problem is very probably not the memory, but some other resource leak, which is alleviated by running finalizers on dead objects. Properly written code must never rely on finalizers to do the cleanup, so try to find any unclosed resources in your application.

score 0 · Answer 7 · answered Sep 10 '13 at 11:32

0

You can start the jvm with more memory

java -Xms512M -Xmx1024M

will start the jvm with 512Mb of memory, allowing it to grow to a gigabyte.

answered Sep 10 '13 at 11:32

Bex

2,905
2
33
36

There is enough memory but gc starts to collect to late. – Trismegistos Sep 10 '13 at 13:17

score 0 · Answer 8 · answered Sep 10 '13 at 11:36

You can use System.gc() to suggest to the VM to run the garbage collector. There is no guarantee that it will run immediately.

I doubt if that will help, but it might work. Another thing you could look at is increasing the maximum memory size of the JVM. You can do this by giving the command line argument -Xmx512m. This would give 512 megabytes of heap size instead of the default 128.

You can use JConsole to view the memory usage of your application. This can help to see how the memory usage develops which is useful in detecting memory leaks.

Java is not able to collect garbages in time

8 Answers8