ExecutorService memory leak on exception

I am having a hard time tracking this down since the profiler keeps crashing (hotspot error). Before I go too deep into figuring it out I'd like to know if I really have a problem or not :-)

I have a few thread pools created via: Executors.newFixedThreadPoo开发者_JAVA技巧l(10); The threads connect to different web sites and, on occasion, I get connection refused and wind up throwing an exception.

When I later on call Future.get() to get the result it will then catch the ExecutionException that wraps the exception that was thrown when the connection could not be made.

The program uses a fairly constant amount of memory up until the point in time that the exceptions get thrown (they tend to happen in batches when a particular site is overloaded). After that point the memory again remains constant but at a higher level.

So my question is along the lines of is the memory behaviour (reported by "top" on Unix) expected because the exceptions just triggered something or do I probably have an actual leak that I'll need to track down? Additionally when Future.get() throws an exception is there anything else I need to do besides catch the exception (such as call Future.cancel() on it)?

EDIT: so I did tale a look with a couple of tools and from the Java point of view there is nothing going on memory leak wise. I'll play around with some other code that lives for a long time and throws an exception after a while and see if the memory reported by "top" also increases. Seems like it may just be some sort of oddity.

Does your Java process ever actually exit with the exception java.lang.OutOfMemoryError ? If not, its unlikely that you have a leak. Of course, you can always attach to the Java process with JConsole, capture a heap dump, and open it in a free tool like HPjmeter to find out really quickly.

JVM will start with Xms amout of heap, then grab more from the system up to Xmx. Even if GC frees heap in the JVM, the java process keeps holding on the heap it has grabbed from the OS (so in top, it never appears to shrink) (Experience with Sun JVM (Java1.5/6) on Redhat Linux).

It is well possible that heap is freed and is available, but it is not released to the OS and in top java appears to be using a lot of heap.

You can use visualvm, a tool that comes with JDK. Just run your app. for an extended time, connect the tool and take a look at the heap telemetry. If it keeps gradually growing, it might be a memory leak.. You can also take a heap dump with this tool and see what objects are accumulating.