ShannonE
asked on
How is memory leak possible in Java with auto gc?
I have to profile a Java application and I need to know how it's possible for a memory leak in Java when Java has automatic garbage collection.
Thanks,
-Shannon
Thanks,
-Shannon
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Much simpler guys,
when you ask for memory and never give it back, you got a memory leak.
To solve the problem is dependent on your application.
The garbage collector must not touch the objects you have in use,
GOOD GRIEVE, IF IT DID!!!!!
;JOOP!
when you ask for memory and never give it back, you got a memory leak.
To solve the problem is dependent on your application.
The garbage collector must not touch the objects you have in use,
GOOD GRIEVE, IF IT DID!!!!!
;JOOP!
>>when you ask for memory and never give it back, you got a memory leak.
Simple and Good answer
Regards
Sudha
Simple and Good answer
Regards
Sudha
At your service.
True bit it doesn't declare why you get memory leaks in Java. When you exit an iteration of a loop all of the memory that you have allocated within that block is automatically dereferenced.
I personally have found that it can happen that the GC cannot get cpu time when you do some intense processing. This is due to the GC being a set of Daemon threads that can only execute when no other threads are busy. Ppl tend to forget that they still need to have wait or yield calls within a thread in order for it to acutally give something else time to process. If you forget about these calls or they are not placed in the correct strategic places you could hog the CPU and thus hinder the GC from ever executing. This situation is especially true in batch processing.
Hope it helps you a bit.
I personally have found that it can happen that the GC cannot get cpu time when you do some intense processing. This is due to the GC being a set of Daemon threads that can only execute when no other threads are busy. Ppl tend to forget that they still need to have wait or yield calls within a thread in order for it to acutally give something else time to process. If you forget about these calls or they are not placed in the correct strategic places you could hog the CPU and thus hinder the GC from ever executing. This situation is especially true in batch processing.
Hope it helps you a bit.
I disagree, whenever you say "new" a check is done if there's enough pool memory.
If the answer is no, the gc-thread is propelled.
Counterquestion: was the initial question asked out of interest or does an application 'blow-up'.
If the first case prevails, well there's enough answer to be content with.
In the latter case, do not blame the gc! It simply can not free memory that you keep in use.
Just a tip: did you practice "addEventListener()" or the sort with an object that has heavy strains
of objects linked? Than you must undo the "add" by a "remove" when the event is no longer of concern.
This is a problem that can eat Gb's without a flaw of JAVA itself.
;JOOP!
If the answer is no, the gc-thread is propelled.
Counterquestion: was the initial question asked out of interest or does an application 'blow-up'.
If the first case prevails, well there's enough answer to be content with.
In the latter case, do not blame the gc! It simply can not free memory that you keep in use.
Just a tip: did you practice "addEventListener()" or the sort with an object that has heavy strains
of objects linked? Than you must undo the "add" by a "remove" when the event is no longer of concern.
This is a problem that can eat Gb's without a flaw of JAVA itself.
;JOOP!
RuadRauFlessa,
> This is due to the GC being a set of Daemon threads that can only
Yes indeed
> execute when no other threads are busy.
True for all threads on a single processor system, not merely for the GC thread. However, the GC thread will execute when there is a need for it, something which is determined by an algorithm which is NOT guided by if there are any other threads running or not.
> Ppl tend to forget that they still need to have wait or yield calls
> within a thread in order for it to acutally give something else time to process.
Only true if you change the priority of the threads you're running, and/or the underlying
operating system does not provide support for pre-emptive multi-tasking.
> If you forget about these calls or they are not placed in the correct
> strategic places you could hog the CPU and thus hinder the GC from ever executing.
Nope. If this was true, programming in Java would become a guessing game.
\t
> This is due to the GC being a set of Daemon threads that can only
Yes indeed
> execute when no other threads are busy.
True for all threads on a single processor system, not merely for the GC thread. However, the GC thread will execute when there is a need for it, something which is determined by an algorithm which is NOT guided by if there are any other threads running or not.
> Ppl tend to forget that they still need to have wait or yield calls
> within a thread in order for it to acutally give something else time to process.
Only true if you change the priority of the threads you're running, and/or the underlying
operating system does not provide support for pre-emptive multi-tasking.
> If you forget about these calls or they are not placed in the correct
> strategic places you could hog the CPU and thus hinder the GC from ever executing.
Nope. If this was true, programming in Java would become a guessing game.
\t
orangehead911,
>True for all threads on a single processor system
Not necessarily - depends also on the implementation of the JVM, and whether or not it makes use of OS threadding, etc.
Its worth noting that even when you are 100% confident in your own application code, it is still very likely that memory leaks can occur, due to the nature of the number of openly available libraries that get used in many applications. There are also other points of leaks in the JVM itself (listed above). Generally its reasonably important to bounce a long running (i.e. 24/7) Java application regularily to "fix" these.
>True for all threads on a single processor system
Not necessarily - depends also on the implementation of the JVM, and whether or not it makes use of OS threadding, etc.
Its worth noting that even when you are 100% confident in your own application code, it is still very likely that memory leaks can occur, due to the nature of the number of openly available libraries that get used in many applications. There are also other points of leaks in the JVM itself (listed above). Generally its reasonably important to bounce a long running (i.e. 24/7) Java application regularily to "fix" these.
> Generally its reasonably important to bounce a long running (i.e. 24/7) Java application regularily to "fix" these.
I had a multi-threaded knowledge based web application running on tomcat under Windows 2000 for almost a year and a half without the need for a reboot, so this *really* depends on what you are doing and why... Saying that the only way to "fix" java memory leaks is to restart the java application regularly is (imho) misleading...
I had a multi-threaded knowledge based web application running on tomcat under Windows 2000 for almost a year and a half without the need for a reboot, so this *really* depends on what you are doing and why... Saying that the only way to "fix" java memory leaks is to restart the java application regularly is (imho) misleading...
Nonsense, I run 1Gb applications for days.
The cause of most so called memory leaks is that the programmer is not aware
that he/she may abandon an object, but the object is still referenced by an event handler
as I described above.
Need an explanation?
;JOOP!
The cause of most so called memory leaks is that the programmer is not aware
that he/she may abandon an object, but the object is still referenced by an event handler
as I described above.
Need an explanation?
;JOOP!
Tim, the "nonsense" refers the same comment as yours, not YOU of course.
Stupid browser.....
;JOOP!
Stupid browser.....
;JOOP!
:-)
Hehehe...we had the same thought upon reading cjjcliffords comment :-)
I agree with you too, event handlers are the biggest leaks of memory... look after them and you are 50% of the way to fixing any memory leaks :-)
I agree with you too, event handlers are the biggest leaks of memory... look after them and you are 50% of the way to fixing any memory leaks :-)
ShannonE, where are you? The answer is given!
;JOOP!
;JOOP!
TimYates, ok, fair cop, but what I was trying to say was if you are using 3rd party libraries that have leaks, which you don't have the ability to change (or fix yourself) then there's not much that can be done.
What volume of traffic would be going through that tomcat application?
sciuiware, I'm not refering to GUI based systems here.... our application processes many GB of ASCII files a day, every day, and also performs quite a lot of complex operations on the resulting data - the system can be seen to grow, slowly but steadily over the course of several days - yes, it doesn't get OutOfMemory very often, even after a week, but our application can take a short amount of downtime (at night when there's noone using the system) without losing data, so we take advantage of this to bounce the JVM, better to be safe than OutOfMemory...
What volume of traffic would be going through that tomcat application?
sciuiware, I'm not refering to GUI based systems here.... our application processes many GB of ASCII files a day, every day, and also performs quite a lot of complex operations on the resulting data - the system can be seen to grow, slowly but steadily over the course of several days - yes, it doesn't get OutOfMemory very often, even after a week, but our application can take a short amount of downtime (at night when there's noone using the system) without losing data, so we take advantage of this to bounce the JVM, better to be safe than OutOfMemory...
> What volume of traffic would be going through that tomcat application?
It was an online benefit calculator for the whole of the city... So the throughput was fairly high. I didn't have any problems with 3rd party libraries leaking memory, but as I tend to only use the larger libraries (tomcat, xalan, xerces, etc), and any leaks I do find, I report as a bug through the usual methods (bugtraq, mailing list, etc), with a fix if I can find one...
I can't think what it is that is causing your application to go OOM... My first guess would be you have some sort of cache on the data which is not time or size dependant, or some form of cyclic dependancy so that you are getting "rings" of un-gc-able data...
It was an online benefit calculator for the whole of the city... So the throughput was fairly high. I didn't have any problems with 3rd party libraries leaking memory, but as I tend to only use the larger libraries (tomcat, xalan, xerces, etc), and any leaks I do find, I report as a bug through the usual methods (bugtraq, mailing list, etc), with a fix if I can find one...
I can't think what it is that is causing your application to go OOM... My first guess would be you have some sort of cache on the data which is not time or size dependant, or some form of cyclic dependancy so that you are getting "rings" of un-gc-able data...
a far lot of work has been put into getting rid of the leaks here, and by-and-large they are mostly gone, the application only grows slowly - the "bounce" is really there to-be-sure-to-be-sure...
I don't think ShannonE can do much with such a complex answer; his question was BASIC!
;JOOP!
;JOOP!
calm down sciuiware... the question was about how memory leaks occur, it didn't say anything about limiting it to a basic level of information...
The question was "I thought it was impossible"
... something like: "I was told that the Titanic couldn't sink .....
We must be aware that a programming language for Dummies doesnot exist.
;JOOP!
... something like: "I was told that the Titanic couldn't sink .....
We must be aware that a programming language for Dummies doesnot exist.
;JOOP!
>a programming language for Dummies doesnot exist
Indeed it does not, and even if it did, sure, a more powerful dummy would be invented :-)
Indeed it does not, and even if it did, sure, a more powerful dummy would be invented :-)
Agreed, back to business ...
;JOOP!
;JOOP!
=-)
Cheers,
C.