Tutorials : Java Threads Revisited: Classic vs. New :

Java Threads Revisited: Classic vs. New

While the JDK1.5 threading framework provided several new features and fine-grained control -- which made writing multithreaded Java applications easier than using the classic pre-JDK1.5 framework -- the process remains challenging and error prone. When building multithreaded enterprise applications, these are some of the major issues the Java developer has to face:

Deciding how to run several threads in parallel
Synchronizing access to some data
Executing a block of code synchronously so that only one thread at a time executes a particular block of code

When the developer turns to the Web for answers, he or she will find plenty of articles on Java threads. Most start with a brief introduction to threads and then go into details about the various features Java provides for building multithreaded applications. Invariably the classic pre-JDK1.5 threading framework is criticized for its performance issues and deadlocks, for not being feature rich, and for being hard to use, while the newer JDK1.5 framework's features are touted for making it easier to write multithreaded applications. This is usually followed by a detailed code-level discussion of these features and the reader gets lost in the details. A critical analysis of the classic and new frameworks is usually missing.

In this article, I use a different approach: explaining and comparing all of the old and new threading-related classes in Java. I start with an overview of the challenges involved with building multithreaded enterprise applications in Java. Then I explain the challenges of using the older pre-JDK1.5 Java thread framework to address these challenges. Next, I explore the features provided by the new JDK1.5+ thread framework and then compare the classic and new frameworks.

The article contains very little code, as you can look up how to use the classes from the API docs. The emphasis is not on code-level explanations. However, you can execute the attached Java code for a demonstration of the points raised in the article. The zip file contains a code sample as an Eclipse project. See the README.txt file in the details.

Issues with Java Classic Thread Framework

First, let's examine the drawbacks of the Java classic thread framework as a tool for building multithreaded enterprise applications:

The classic Java thread framework in JDK <1.2 was not mature and had performance issues, which were subsequently fixed. However, even a poorly designed threading model in an enterprise application is not likely to be the bottleneck. The bottleneck is usually the I/O (network or disk I/O), but a poor threading model can lead to deadlocks and other problems.
Developing good multithreaded applications was hard and required skilled developers. Multithreaded application projects were beyond what most average developers could do as part of their daily jobs.
The emergence of newer programming languages like Erlang, which can handle thousands of threads easily, makes the Java thread model look crude.

Apart from these drawbacks, Java threads got the blame for these common application glitches:

The application simply freezes for 10-15 seconds once or twice a day. Developers assume that maybe the threads have been deadlocked/livelocked. The cause usually turns out to be garbage collection freezing up the JVM. When deadlocked, threads will not recover on their own. So, if the application recovers quickly, deadlocks are unlikely to be the problem. To diagnose the problem, enable logging of garbage collection. The JVM will lock just before a full garbage collection.
The application is slow. Developers assume that the cause could be threads waiting to access locks so they can read/modify a single resource. Accompanying tests show that it takes 90ms for every thread out of 100 classic threads to update a single data source protected by a Java object monitor (sync method). So the use of "synchronized" is unlikely to be the performance bottleneck on its own.

If possible, the developer should search for a higher-level API/framework so he or she doesn't have to deal with the underlying details of managing concurrency. As an example, if you wish to build a multithreaded server to consume messages, then you can use the products below:

UDP messages - use Apache Mina
TCP messages - use QuickServer
HTTP messages - use a Web server (e.g. Tomcat)

The classic thread framework still has its uses, however. As Brian Goetz wrote, "synchronization works just fine, works on all JVMs, is understood by a wider range of developers, and is less error-prone".

Home / Articles / Java Threads Revisited: Classic vs. New/ 1

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.