Memory Leaks with addShutDownHook

In our web-app we are using Launcher to call some command line functions (not my idea) and see the result. This is more or less what we do:

ClassWorld classWorld = new ClassWorld("plexus.core", Thread.currentThread().getContextClassLoader());
Launcher launch = new Launcher();
launch.setWorld(classWorld);
result = launch.mainWithExitCode(sArguments);

Well, I recently learned that since mainWithExitCode is a static function it probably doesn't do what I thought it did. So next version is probably going to be just:

Launcher launch = new Launcher();
result = launch.mainWithExitCode(sArguments);

So, we have been testing our app and it seems it leaks due to a lot of stuff I don’t really understand completely. So one senior from here (but not from our project) told us that it’s probably due to CommandLineUtils using addShoutDownHook that ‘transfers’ (that is probably not the best word for it) the object to java.lang.ApplicationShutdownHooks and it doesn’t destroy the object while the server is up (mostly all the time). So every command line that our web-app throws out of the blue it sticks in memory in he server, never cleaning.

So, I have been told that I should look for my process in the waitFor and quit it from the ShutdownHook. Seeing my code it does seem complicated at last to do that, since I don’t call the CommandLineUtils directly (I suppose it is called inside the launch method).

Does anybody have any clue on where I can find the info to develop this? I am not asking you to post some code that solves the problem (although it would be great), but to point me to some page or manual were I can find the info to solve th开发者_StackOverflow中文版is. Time is not yet a big issue (I have probably a week or so to find out and solve this), so I can spend some time reading manuals and such (and learn how to do it for the next time).

Any help would be appreciated. Thanks!

Yes addShutdownHook leaks hard, very hard. You have to use removeShutdownHook and even then the ThreadGroup might leak due to a bug.

Actually web-apps should not touch threads at all unless: you are well settled w/ the server and have enough skills to make thread spawning, joining and killing it properly.

That implies you do have plenty of skills to write middleware yourself and most likely you'd deploy the needed Threading code separately as JMX or JCA.

My recommendation is: extract the service out of the web-app and deal it accordingly. Writing middleware w/o leaks takes quite a bit of skill and patience.