olze oli wrote:The method quits normaly when a directory is done, in my application i get a new dir and call this method again, just with another parameter, and so on. So its not one directory where the heap becomes a problem its a problem when i run this method in a loop.
What loop, specifically? Are you running the code above, or are you running something else? Because the code show above does have a loop, and a recursive call to getFilesFromDir().
That, fundamentally, is why you might well have a problem with memory usage here.
Consider a directory dirA, with a child directory dirB,...
have you tried increasing the heap memory allocation?
Using relative paths (e.g. getPath()) should do well enough, and it's shorter.
It may well be better to process each directory and each file as you go.
olze oli wrote:
Mike Simmons wrote:What loop, specifically? Are you running the code above, or are you running something else? Because the code show above does have a loop, and a recursive call to getFilesFromDir().
The loop outside this recursive function. I will post it later.
olze oli wrote:
Mike Simmons wrote:have you tried increasing the heap memory allocation?
No and i dont want to do that. The heap should be allocated by the garbage collector and i think 256MB must be enough for that simple application.
Rather than just giving us a petulant "I don't want to"
olze oli wrote:Would you give a hello world 50MB ram without analyze why its giving an OOME? And if it throws an OOME would you simply rise the heap? I wouldnt. Thats the reason why i ask what could lead to that behavior, because this is a function i (maybe) often need and so i want to know whats happening or if i have to pay attention to something.
and you've given no indication of how many files are
Come on, speak clearly.
have you heard of the enhanced for loop available since JDK 5?
i think this is more than enough. Why giving it more? I just dont get that
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |