Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Modern threading: A Java concurrency primer

Understanding Java threads in a post-JDK 1.4 world

By Cameron Laird, JavaWorld.com, 06/26/12

  • Print
  • Feedback
.

Page 3 of 7

Something else to notice in Listing 1 is that Thread is an abstract class, designed to be subclassed. Its default run() method does nothing, so must be overridden in the subclass definition to accomplish anything useful.

 

This is all about speed, right?

So by now you can see a little bit of what makes programming with threads complex. But the main point of enduring all these difficulties isn't to gain speed.

Multithreaded programs do not, in general, complete faster than single-threaded ones -- in fact they can be significantly slower in pathologic cases. The fundamental added value of multithreaded programs is responsiveness. When multiple processing cores are available to the JVM, or when the program spends significant time waiting on multiple external resources such as network responses, then multithreading can help the program complete faster.

Think of a GUI application: if it still responds to end-user points and clicks while searching "in the background" for a matching fingerprint or re-calculating the calendar for next year's tennis tournament, then it was built with concurrency in mind. A typical concurrent application architecture puts recognition and response to user actions in a thread separate from the computational thread assigned to handle the big back-end load. (See "Swing threading and the event-dispatch thread" for further illustration of these principles.)

In your own programming, then, you're most likely to consider using Threads in one of these circumstances:

  1. An existing application has correct functionality but is unresponsive at times. These "blocks" often have to do with external resources outside your control: time-consuming database queries, complicated calculations, multimedia playback, or networked responses with uncontrollable latency.
  2. A computationally-intense application could make better use of multicore hosts. This might be the case for someone rendering complex graphics or simulating an involved scientific model.
  3. Thread naturally expresses the application's required programming model. Suppose, for instance, that you were modeling the behavior of rush-hour automobile drivers or bees in a hive. To implement each driver or bee as a Thread-related object might be convenient from a programming standpoint, apart from any considerations of speed or responsiveness.

 

Challenges of Java concurrency

Experienced programmer Ned Batchelder recently quipped

Some people, when confronted with a problem, think, "I know, I'll use threads," and then two they hav erpoblesms.

That's funny because it so well models the problem with concurrency. As I already mentioned, multithreaded programs are likely to give different results in terms of the exact sequence or timing of thread execution. That's troubling to programmers, who are trained to think in terms of reproducible results, strict determinacy, and invariant sequence.

It gets worse. Different threads might not only produce results in different orders, but they can contend at more essential levels for results. It's easy for a newcomer to multithreading to close() a file handle in one Thread before a different Thread has finished everything it needs to write.

  • Print
  • Feedback

Resources

Threads programming

Thread synchronization

Locks and monitors

Testing and debugging threads

Threads & alternatives