Java Platform, Enterprise Edition

Java EE Journal

Subscribe to Java EE Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Java EE Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

J2EE Journal Authors: Stackify Blog, Sumith Kumar Puri, Javier Paniza, Yakov Fain, Ken Fogel

Related Topics: Java Developer Magazine

Java Developer : Article

Java Basics: Introduction to Java Threads, Part 2

Internet Portals Like Yahoo, CNN, or Your Bank's Web Site Use Them

In the previous lesson I've explained the basics of Java threads. This time we'll talk about using threads for creating a little more advanced programs.

I'm sure each of you have visited some of the major Internet portals like Yahoo, CNN or your bank's Web site. These portals usually display different types of information like News, Weather, Stock Market quotes, etc. Each of these info pieces appears on the screen instantaneously even though it's coming to the portal from different servers, i.e. the News server may be located in Washington and the stock market data come from New York (see Figure 1 below).

Let's say it takes 4 seconds to receive the news and 3 seconds to get the stock prices. If your program will do it in a sequence, it'll take you 7 seconds total, but why not do this in parallel and reduce the total time to 4 seconds? After all these servers have their own processors that can work in independently from each other! We are not going to discuss Web technologies here, but I'll show you how to spawn parallel processing using multi-threading, collect the returned data and display the results to the user in one shot.

Our program will consist of the following classes:

  • MyPortal that will spawn the threads and collect their returns in an ArrayList of strings. It'll print entire content of this array when all threads complete.
  • NewsServer that will run for 4 seconds and return a message "We have good and bad news";
  • StockServer that will run for 3 seconds and return a message "The stock market is on the rise!".
These threads do not contain any code that actually gets some news or market data. My goal is to show you how threads can communicate with other classes, and after this part works, it wont be difficult to replace the line that prints a static message with a method call that actually connects to the Internet and gets the data as it was explained in the lesson on getting data from the Internet:.

The class in Listing 1 creates and starts two threads (news and stocks) and goes to sleep for 10 seconds just to keep the program alive for a while. Please note that the class MyPortal also passes to each thread a reference to its instance so the threads know were to return the results. After each thread completes, it returns the result to MyPortal by calling its method submitResult(). Each of the resulting strings is being added to the ArrayList dataToDisplay, and when its size grows to two elements MyPortal prints the content of content the collection dataToDisplay. A little later I'll explain why such use of an ArrayList may not be the best solution for this example.

Listing 1. The source code of the class MyPortal

import java.util.ArrayList;
public class MyPortal {
	ArrayList dataToDisplay = new ArrayList();
    public static void main(String args[]){
    	MyPortal mp =new MyPortal();
    	// Spawn the threads and pass them the referennce
    	// to the instance of MyPortal
    	NewsServer myNews = new NewsServer(mp);
    	Thread newsThread = new Thread(myNews);

    	StockServer myStocks = new StockServer(mp);
    	Thread stockThread = new Thread(myStocks);

    	//Start the threads

    	try {
    		System.out.println("MyPortal is sleeping...!");
			Thread.sleep(10000); // wait for 10 sec 
		} catch (InterruptedException e) {

		System.out.println("Good bye!");

    // Add the data returned by a thread to collection
    public void submitResult(String data){

    	// Print the data if both threads have submitted the data
    	// (a buggy version)
    	if (dataToDisplay.size()==2){

The output of this program looks as follows:

MyPortal is sleeping...
[The stock market is on the rise!, We have good and bad news]
Good bye!

The first line will be printed almost immediately, the second line in 4 seconds and the third one in 10 seconds.

Listing 2. The source code of the class StockServer

public class StockServer implements Runnable {
    MyPortal papa;
    // Constructor
    StockServer(MyPortal parent){

    public void run() {
	// Sleep for 3 seconds to emulate some processing
	// and return a string with the market data to the parent
 	try {
		papa.submitResult("The stock market is on the rise!");
	} catch (InterruptedException e) {

Listing 3. The source code of the class NewsServer

public class NewsServer implements Runnable {
    MyPortal papa;

    // Constructor
    NewsServer(MyPortal parent){

	public void run() {
	// Sleep for 4 seconds to emulate some processing
	// and return a string with the news to the parent

		try {
			papa.submitResult("We have  good and bad news");
		} catch (InterruptedException e) {

The thread classes from Listing 2 and Listing 3 store the references to the parent class MyPortal in the variable papa. Each of the threads just sleeps for a specified number of seconds, wakes up and passes an appropriate text to papa.

Please note, that even on a single processor's machine the total execution time of our example is just a little more than 4 seconds. The reason is that our threads where "sleeping in parallel" and did not compete for the processor's time. But if you replace the sleeping part with a loop that performs some calculations, the timing will be different on a single processor machine: the program will run about 7 seconds. If you have a dual processor machine, you'll cut the processing time to 4 seconds again.

Thread Synchronization. A Race Condition.

When you write a multithreaded application you should consider possibility of a so-called race condition. This is a situation when you may get unpredictable results because multiple threads access a resource (i.e. a variable) at the same time. In our example two threads are calling the same method submitResult() which in turn accesses the variable dataToDisplay to add some data to it and check the size of this collection. Imagine that two or more threads finish their work at the same time. Let's look at a possible sequence of events:

  1. The NewsServer calls the method submitResult(). The size of dataToDisplay is 0.
  2. The StockServer calls the method submitResult() a split second later. The size of dataToDisplay is 0.
  3. The NewsServer grabs a zero-element dataToDisplay and starts adding its string there as a first element.
  4. The StockServer grabs a zero-element dataToDisplay (because the NewsServer has not finished adding its first the element yet) and starts adding its string there as a first element.
  5. After both threads are done, the dataToDisplay may wind up with having one element because the first thread's string has been overwritten by the second one. In this is the case, the size of the dataToDisplay will remain one and MyPortal will never print the news and stock data.
Since the probability of this situation is really small, your program may work properly for years and all of a sudden produce unexpected results. Bugs like this one are not easy to discover.

To avoid race conditions, the code that needs to access a "sensitive" variable must be locked (become unavailable for other threads) for the time when one thread works with it. When the first thread completes, the lock is released and another thread can get a hold of this variable/resource. You can arrange such locking either by using a Java keyword synchronized, or by using Java objects that are internally synchronized.

In our portal example, you can simply use the class Vector instead of ArrayList:

Vector dataToDisplay = new Vector();

Vector objects are internally synchronized in Java, and the second thread won't be able to add a string to the dataToDisplay collection until the first thread is done. Obviously, there is a price to pay for this convenience: synchronized objects are a little bit slower than non-synchronized ones.

The other solution is to put an explicit lock for a piece of code that must be completed without any interruption by other threads. For example, if you'll add the keyword synchronized to the signature of the method submitResult(), the second thread will not be able to call this method, if the first one is still executing it:

public synchronized void submitResult(String data){?}

You can also say that a lock is placed on the entire method submitResult().

You should try to minimize the locking time to avoid slowing down your programs. Java allows you to synchronize just a small portion of the code, which is more preferable than synchronizing an entire method.:

    public void submitResult(String data){
    	synchronized (this){

    	if (dataToDisplay.size()==2){

When a synchronized block is executed, the object in parenthesis is locked and cannot be used by any other thread until the lock is released.

Each Java thread has its own memory and the JVM copies there variables from the main program memory. The keyword synchronize means to synch up the content of the main and thread's portions of memory. This ensures that each thread works with the most current value of the resource (in our case its dataToDisplay).

If you spot a group of Java programmers in a bar, after a couple of beers they may start using some mysterious words: monitor and mutex.

A monitor is just a piece of a synchronized code. We can say that one of our threads can enter a monitor and safely modify the variable dataToDisplay. While the first thread is working, another thread(s) may start waiting for this monitor.

Mutex means mutually exclusive, and this term also refers to the fact that threads may take turns accessing some program variable(s).

In this lesson you've learned one of the ways of treating more than one thread as a group, but this is not the only way. Java has a class java.lang.ThreadGroup that allows you to create and start a group of threads, control the threads within the group and check which threads are still active. You may also consider the method join() of the class Thread if one thread needs to wait for completion of another.

Threads can communicate with other Java objects using special methods wait(), notify() and notifyAll(), but this is going to be a topic of another lesson. Meanwhile, you can read more about threads in the Java Tutorial over here:

More Stories By Yakov Fain

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs ( and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Slava Pestov 02/18/05 07:57:05 PM EST

Yakov, your last threads example has a race condition.

Consider this:

thread 1 executes: synchronized (this){ dataToDisplay.add(data); }.

then thread 2 executes: synchronized (this){ dataToDisplay.add(data); }.

then thread 1 executes: if (dataToDisplay.size()==2){ System.out.println(dataToDisplay); }

then thread 2 executes: if (dataToDisplay.size()==2){ System.out.println(dataToDisplay); }

That last System.out.println(dataToDisplay); executes twice, which is not what you intended.

Yakov Fain 02/04/05 11:41:26 AM EST

Yes, J2EE spec does not recommend it, but if you do it right everything works fine. Here's how this could be done

To control threads in a J2EE container use a thread pool (it's a singleton) and get threads from there. If you use J2SE 5.0, use the package java.util.concurrent (in particular, ThreadPoolExecutor). In J2SE 1.4 and below use an excellent concurrent package created by Doug Lea.

Disclaimer: It's just my personal opinion based on my prior experience with a pretty serious financial application. But I do not recommend you to violate J2EE spec.

Feldhacker 02/04/05 08:35:41 AM EST

Is a J2EE version of this example available? Since J2EE forbids explicit thread management, how would this be done on a web server?