Showing posts with label concurrency. Show all posts
Showing posts with label concurrency. Show all posts

Thursday, November 20, 2008

Time's Up

I'm certainly not the first person to say this, but it bears repeating, using Timer in the post Java 5 world is not a good idea. I got bitten by Timer's lack of exception handling again recently. If you must use a Timer and are relying on it to be long-lived, make sure the run() methods on your tasks can't throw any unchecked exceptions, because if any exceptions manage to leak out of the run() method, the timer thread will terminate and no more tasks will run. I used to use Timer in situations where I wanted to be able to cancel tasks, since TimerTask exposes a cancel() method. What I failed to realize was that you can do the exact same thing using ScheduledExecutorService using the ScheduledFuture object that is returned when one of the schedule methods is invoked. It's a bit more cumbersome to cancel tasks this way since you may have to keep references to both the task object and the future object, but it wouldn't be too difficult to create a custom class to manage this.

Saturday, September 27, 2008

Can't Hardly Wait

I ran into a wait leak issue recently and it made me wonder if there was anything I could to do prevent this issue from happening again. I found this article from a few years back written by Java performance gurus Jack Shirazi and Kirk Pepperdine. The article mainly discusses tactics for detecting wait leaks. When it comes to preventing them from happening in the first place, there's no silver bullet. Something that I thought of that wasn't mention in the article is preferring the timed wait() method instead of the no-arg version in order to prevent wait leaks. Obviously, it's not always possible to specify a wait timeout, but in situations where it is possible, it can help an application recover gracefully from a wait leak.