Looking back at BidBlazer

BidBlazer was developed and marketed by AD2001 Computer Services (which later became Infoblazer LLC) from 1999 through 2001. BidBlazer was one of the first in a new breed of online auction search tools and was the first client based tool in this niche. At it’s peak, BidBlazer searched eight online auction sites, including Ebay, Yahoo, Amazon, and MSN

During this time period, Ebay greatly consolidated it’s share of the online market. Therefore, other auction sites were left with few listings and most were eventually phases out. Due to the overwhelming market share of Ebay, cross auction searches became less useful. Developers moved to building tools targeted towareds Ebay specifically, such as sniping and submission utilities. In addition, development of online searching during that time period was very prone to changes in online auction formats. Since there was generally no published API or XML communication tools, such as later popularized by Amazon and Google, keeping up to date with auction site changes was a constant process.Therefore, BidBlazer was phased out in mid 2001.

For posterity, here are some screen captures from the software and a review of the product from Rocketdownload.com

Pigs Don’t Fly

A few posts back, I discussed my new project, an online quiz application, and the initial choice of GWT and GXT as the framework. The article was entitled “Pigs are Flying”, due to my previous convictions and statements that were not always kind to so called Rich Internet Applications.

Well it turns out after all that pigs do not fly and GWT/GXT does not fly.

A few caveats here. I use GWT daily in my consulting gig, so I have some experience in the area. I just remain a firm believer in applying Ajax judiciously. GWT (and certainly GXT) is full blown Ajax, almost HTML-less Ajax, if that is possible.

I still stand by the heuristic that an RIA will take twice as long to develop as the comparably functional Ajax-enhanced HTML application. Does this type of application have a place? Most definitely. Just be certain you requirements dictate such a tool and you have the funding and or time for its implement. In my situation, I just did not have such a luxury, particularly to wait around for applications to reload changes and to search out documentation on a less than fully documented third party framework.

Nuff said on that issue.

Since I’ve always been a user of Spring, and I initially started prototyping the quiz app in Spring MVC, I returned to SpringSource technologies, but not Spring but Grails.

I may have a little to say about Grails in the future (and I don’t like to repeat what is already said out there) but Grails is truly excellent.

While pigs are not flying anymore (although they are trying to take off, since I’ve also had some less than kind things to say about dynamic languages) there is still much to get used to in a language like Groovy. I specifically mean the lack of static type checking. However, IntelliJ does a decent job with things like code completion. Plus the dynamic application reloading is great. It’s nice not to hit the restart button after every code change.

That’s it for the status update. I’ll return to discussing performance issues in future articles. I find it hard not to get sidetracked when the topic of framework selection and evaluation arises.


HttpSession and GWT

Most anyone who has done Java server programming has dealt with the Session object, as well as its siblings (and I use that term in essence, not in fact) objects: ServletContext, HttpRequest and HttpResponse. Of course, if you are using a newfangled “Component” framework that tries to “shield” you from the intricacies of HTTP, you may not be familiar with these babies.

GWT is somewhat of a mélange of both Component frameworks and Request/Response frameworks. It is certainly on the component side of the spectrum, in that you are programming mainly in Java objects and using Swing-like constructs and events. But that is mainly on the client side of things. On the server side, GWT is strictly Servlet based, with some excellent marshalling thrown. The marshalling is so good that sometimes can make you forget the HTTP underpinnings. A dead giveaway, other than of course reading the documentation, is that any remote service must be defined in web.xml as a Servlet. I always found this odd, since most newer request /response frameworks(that gladly expose HTTP constructs) tend to use a single “Base” Servlet that you then must extend. Typically, you would create a single Servlet Mapping for this Base Servlet, which would handle essentially all requests. The Base Servlet, based on some xml, annotated, convention based, or a combination of the above, would pass control to a custom Java class which would handle the actual implementation. The Base Servlet and related framework will also provide much of the “plumbing” and other features, such as parameter object mapping, view integration, etc.

With GWT, every remote service you make available to the client must be defined as a distinct Servlet in web.xml (I feel like I’ve already said this, but it is worth repeating). The Servlet class defined is actually the developer’s specific java class, not a base Servlet. This class must extend RemoteServiceServlet, which is a descendent of HttpServlet. This is a key point in the discussion that will follow. Beware of a framework that forces you to extend its own classes (Ok, for the few of you in the know, XX Framework makes you do this as well, but I plead ignorance since I didn’t know better at the time. And I hadn’t seen Spring MVC yet).

Begin a Servlet, our GWT remote service implementation has access to all the HTTP goodies, specifically HttpSession, which I at one time said this post was about. To access the HTTP Session, you use the method


If this was a HttpServlet Sevice() method, you’d have access to this directly via the HttpServletRequest parameter . But since that method is long gone by the time your code is called, GWT stores this information and makes it available in a ThreadLocal object. ThreadLocal is a construct that lets each JVM thread have its own version of any class level variables. GWT needs ThreadLocal since a Servlet, as in HTTPServlet, needs to serve multiple threads. TheThreadLocal makes data available to all threads that may be accessing that Servlet.

Now remember the following point:

Each Servlet maintains its own ThreadLocal storage

There is nothing unusual with this. How else could multiple threads be served?

The problem arises when you decide to treat your Remote Service Implementation as just another Java class (POJO anyone) and not what it truly is, an HTTPServlet.

So the problem arises when any server side GWT code instantiates a GWT Remote service implementation directly.

Why is this a problem? Well in most cases, it may not be. We won’t include bad architecture in this discussion, which that most certainly is. The problem occurs when you try to access our old friend, getThreadLocalRequest().

The Remote Service Serlvet’s, which our Implemenation must extend, private ThreadLocal storage is initialized when the HTTP Service (POST, GET) happens. The HttpServletRequest, which includes the HttpSession is stored in the Servlet’s Threadlocal storage for access by the current thread.

When that Remote Service Implementation, or any other subsequent code, instantiates another Remote Service Implementation, the new Service’s ThreadLocal is created (it has to be as we are creating a new object) but it is not initialized, since no HTTP Get or Post has occurred. Therefore, any access to getThreadLocalRequest() will throw a NullPointerException, as this information has not yet been stored in ThreadLocalStorage.

I recently hit this problem while working with a client’s code. Doing an internet search and looking at some GWT books didn’t really shed any light on the problem. The only mention was a simple description, useful nonetheless, of the basic method for accessing the HttpSession and related objects. No warning or discussion of what happens when you instantiate a new Remote Service Servlet implementation object.

This is another reason why the SpringSource guys are being proved right time and time again. Please check out Spring MVC for an example of a web framework that can use pure POJO’s for most functionality. These POJO’s can be subsequently instantiated and used, as they have no dependency on the framework.

Implementing GWT, Pigs are Flying

I’ve always promoted a “standards” oriented approach to web development, meaning, a server side app that produces pure XHTML, styled with CSS, with Ajax added where appropriate. I’ve worked with GWT for some time and feel, while it is a tremendous product, it is essentially VB (ok maybe closer to Swing) for the web/JavaScript. It excels at building a desktop application look and feel. Contrast this with a more “web” look and feel, especially some of the sites associated with web 2.0.

I haven’t written a post for some time. I’ve been debating what client tool to use on quiz application. I originally planned on using Flex, figuring I could do a nifty interface and still integrate with Spring and Java on the back end. I also did some quick prototyping of CRUD screens in Spring MVC. It is amazing how easy it is to get simple HTML forms and data entry working  with that framework. I really like it and the philosophy behind it.

However, whenever I do HTML based apps, there is always the missing piece which is graphic design. I will admin that is not my strong point. I can do a passable job (see Domuswap.com archive), but it is not something that comes quick and easy to me. I would sure love to spend time learning photoshop, etc. I have no doubt that there are some nice approaches to easily styling HTML, I just haven’t stumbled across one that works for me yet.

So far, I can really get into Flex. I felt I was jury rigging the thing to get it to speak to Java/Spring. I wish Springsource would release an integration layer with GWT. I am sure it is coming. Not that is was that much work, but it is much more involved that what I’ve been doing for the past year with GWT. The client and server integration is so tight, you sometimes don’t realize on what side of the app you are.

The final blow came when I explored the excellent GWT add on library/framework, Ext GWT. The Web Desktop demo really blew me away. It is really just some nice CSS, but that is really important. The look of an application is the majority of it’s appeal.

I’ve always held that a major benefit of GWT is that it lets graphics impaired developers put together a good looking application. I think I may go down that path, or should I say, towards the dark side.

Always Start with the Use Cases

You usually come into any project with somewhat of an idea of what you want the thing to do. The first step, therefore, is to get these ideas down on paper. This process can encompass a mission statement, feature list, or other textual description of what you want to get done. We are in the brainstorming phase here, so anything you write is good. Let the ideas flow.

Now when you are ready to sit down and actually begin work (making sure your coffee cup is filled first) the first step should be use case diagramming. We are still in the brainstorming phase at this point, but use cases make the application begin to take shape, with early definitions of actual application components emerging.

Many of the use cases will be obvious. Some will become evident once the more obvious ones are defined. For use cases, there will certainly be “view available quizzes”, “take quiz” and of course some sort of authentication / log in behavior.

The initial data model can be developed in parallel with the use cases. Remember, both of these models will evolve throughout the life of the project. We are not doing big upfront design here, just enough architecture to get going. But some formal design is always a good idea.

As you go through the use case modeling, keep a note of the domain objects that you start describing. Start building your domain / class model now as well. Some of these will be obvious. In my cases, things like Quiz, Answer, Question, and of course the always present object User, were things I didn’t need to think much about. But the relationships between the two are not obvious. Is user related to quiz, quiz to question, or is there something more complex going on.

As soon as a few main uses cases are defined, it is time to jump into coding. Besides the fact that this is what I like to do, early coding will help you solve early problems and answer unknowns related to new technologies. You just want to make sure you are on the right track. This is called the vertical slice approach, where you build out a piece of functionality, generally a couple of use cases, from start to finish (from the web page to the database, the full stack). Plus it is always nice to have a working application to show. I won’t go into a full discussion of this topic. Just see any of the Agile literature for more information.

The quiz application is not yet an earth shattering innovation (but I do have a few things planned that could very well be). However, one goal is to implement the latest best practices in web application development. As such, I finally have the luxury to take the time and do it right. Of course, there are time pressures for this one as well, there always are. Even if there aren’t any dictated timelines, technology will eventually move ahead, you can’t stop that, and you will always be chasing the latest and greatest technology and practices.

The Complete Rewrite

Have you ever worked on a project and not thought that is would really benefit from a complete rewrite? It would be nice if that was not the case, but I believe reality dictates that what we wind up releasing is less than ideal.

One reason for this is changes in technology. New tools, techniques, and frameworks are constantly being developed. How many projects out there using Struts would not prefer a rewrite in a more modern framework.

The second reason is time constraints. We just do not always have the time to implement things the way we would like in the ideal world. There is always pressure to get things done yesterday. Much of programming wisdom is in finding the right balance between quick development and a well designed application, and delivering as much of both as possible.

We also seem to like the complete rewrite, such as when a new release of a product comes out. Check out this announcement from Spectral Core for their excellent Full Convert product.

Full Convert 5.0 released:

1-Conversion engine rewritten so that .NET framework is no longer required. This considerably reduces installation size and memory consumption, improves conversion speed and user interface responsiveness.

I feel good about this new feature, after all, it is a complete rewrite.

When I wrote Domuswap, I didn’t have the luxury of a complete rewrite. Domuswap was developed concurrently with the XX framework 1.1 and 2.0. Once the framework proved successful in Domuswap, it was released. However, I was still using the underlying framework and legacy code. Some was rewritten, but the time certainly wasn’t there for a complete rewrite. Indeed, I was very happy with how easily the existing code fit into the Spring MVC components that were added.

Would I have liked to do a complete rewrite? Definitely. I’d probably like to prove that XSL could indeed be speedy, or get rid of that approach entirely. I’d also like to enhance the multi threading techniques. I did this to some extent for version 2.0, in conjunction with my Sarasota Java Users Group presentation on concurrency. But that feature is still in experimental stages.

If I was to do a complete rewrite of the XX Framework, I would probably start with pure Spring MVC and just weave in some of the more interesting XX features, all the while sticking to their interfaces as much as possible.

All that being said, I find myself with the luxury of doing a complete rewrite at this very moment with the New Project. I plan to do this, in addition to satisfying the necessary functionality, as an implementation of what I see as the current best practices in web application development. I’ll have much more to say about this project in future columns.

The New Project

I began a new project today. We’ll really last weekend; I am just getting to write about it now.

The projects not in relation to my current full time consulting gig (which is a GTW project for the insurance industry). The new project will be an education testing program for a local community college, essentially online quizzes. I am also using this project as an opportunity to explore new tools and frameworks.

When we think education application, Flex comes to mind, and it is certainly a frontrunner, especially for the interface/testing component and if multimedia is incorporated.

For the back end, I am moving away from the XX Framework. While I think the framework is awesome, I need to get additional experience on more industry standard tools. Of course, XX is built on Spring MVC. But I want to get some additional experience in pure Spring apps.

Spring Web Flow is another possibility. The more I read about Spring MVC and Spring web flow, the more in common I see with what is in the XX Framework. Regarding Web Flow, I don’t know if I want to write so much in their XML/Expression based DSL. I don’t mind specifying this stuff for control reasons (like what XX does) but getting into defining variables doesn’t seem the place for XML based grammars.

Spring web flow does lend itself to a graphical editor. I haven’t tried Spring IDE, but since they were a recent SunJug sponsor, I took a quick spin in Skyway Builder , an eclipse based GUI for generating Spring MVC/Spring Web Flow apps. It is really an impressive product. However, being impressive doesn’t mean it is useful (sort of how I feel about GWT most of the time). Why try to graft a GUI over what is a perfectly capable and expressive language (Java / XML). In some cases, this will make sense, but in many or most, just writing plain old Java is quicker and quite understandable.

I need to work more with these tools to really make a judgment on them, however.

The one thing I always start with is a bit of upfront UML modeling. I use Enterprise Architect, which is a really inexpensive and reasonable good UML tool. Just brainstorm out the use cases and draw up some classed. It always helps to diagram these out before putting them to Java , and it doesn’t take too long to get to the Java stage.

One thing I did take away from reading some of the Web Flow docs was the use of UML state diagrams. I have always used Use Case diagrams and activity diagrams almost exclusively, but the web flow authors showed how State diagrams can more easily model the overall flow of the entire applications.

So I will most certainly do a Spring MVC / Hibernate / MySQLback end. Build out the model and services. I haven’t decided on the front end. It may be Flex, with BlazeDS or web service interface. Maybe JSF, which I have the least experience in and would like to learn. Most likely a portion will be in a Spring MVC view technology, namely JSF, Velocity, or Freemarker. Most likely, the application wills involve several of the above tools.

Java Versus PHP

One of my main interests is in web frameworks, or more simply put “what is the best way to implement a given application?”.

I like Java, love the IDE’s available and what they can do, and believe that a good Object Oriented design is the foundation of a good application, irrespective of the technologies used.

That being said, there are some really great PHP applications out there (WordPress, Joomla. Drupal, etc). You really can’t point to as many open source, easily available Java applications.

The main selling point of the PHP is the ease of installation and deployment. Most of the popular programs just require you to upload the source code and run an installation script.

Java on the other hand is a bit more involved. If all goes well, you should just be able to copy a War or Ear file to your server and you are all set. Of course, there are issues with restarting the application and such architecture is of questionable ease to extend with plug-ins the way PHP seems to be. I’d like to think that all the good Java developers are too busy building really cool corporate applications, which might actually be the case.

I bring all this up due to my recent experience in finalizing the XX Framework. I have two demo applications that are part of the distribution, a guestbook and an implementation of Java Pet Store. I’ve successfully converted these to XX 2.0, and they can easily be deployed as a War file.

My intention was to have the demos available online. This is always a nice to have when looking at a new framework or product.

I use and love Eapps.com for hosting. I’ve been able to run Domuswap.com on their shared VPS environment, but soon outgrew them and moved to a GoDaddy dedicated box.

Since I don’t want to spend much money to keep the demo apps online, I attempted to deploy the War to a shared 256MB server. It deployed and ran fine, but quickly blew through available CPU, so I had to back it out before I received a phone call from Eapps support “suggesting” that I upgrade.

I thought, if this was a PHP application, it would likely work fine and be quite fast. Is this just the nature of PHP versus Java, PHP being more suitable for the low end and Java more for the high end. I think this is probably the case. I should add, that the XX framework is a known CPU hog, being entirely dependent on XSL transformation and those can certainly spin up the processor.

I’d like to compare apples to apples some day and deploy a simple and lean Java app, with and without additional frameworks like Spring and Hibernate. I could rewrite the demos to do this and hopefully someday I will have the time to do just that.

Introduction to Java Concurrency

Presented by David Moskowitz to the Sarasota Java Users Group on June 11, 2009

All java code discussed in this article can be found at http://sunjug.org/presentations/concurrency/


Java concurrency interests me because I see it as a somewhat untapped feature of the language. Most of the work I’ve done, mainly developing enterprise Java web applications, hasn’t dealt much with concurrency directly. I emphasis directly since Java Servlets are one of the most widely use forms of java functionality and are implemented in a multi threaded manner. While most experienced programmers know of the problems in using class variables in Servlets, studying multi threaded can give us a more complete understanding of this issue

Concurrency has been a core feature of the language since JDK 1.0. Indeed most of the concurrency functionality is contained in the java.lang package, so it is always there and available. If you’ve used code completion in an IDE, you will see methods like notify () and wait() on all objects. These are concurrency related methods contained in the Object class, the class from which all other classes inherit.

Java concurrency is also intriguing because of its two sided nature. Firstly, it is extremely easy to implement multiple threads in Java, as we shall see by example in this article. On the other hand, problems and bugs often occur in multi threaded application that don’t occur in their non threaded counterpart. Because of the non deterministic nature of the Java thread scheduler (especially on the Windows platform), two runs of the same program may (or more accurately, will) have different execution timings and therefore different interaction between threads.

Why use threads

Threads may be used for two reasons

  1. Improved performance
  2. Improved application design

Regarding improved performance, I am a firm believer in the idea, to paraphrase many others, “Premature optimization is evil”. Therefore, it would be unwise to initiate a threaded implementation based only on the assumption that performance can be improved by such an implementation. Performance improvements should only be made after application profiling indicates such a need, and more importantly where, a performance issue exists. It can then be determined whether added concurrency can improve the problem.

It is likely that threading will have more and more impact in the area of performance in the future. Processor trends have shifted from more and more powerful single CPU machines, to multiple CPU or multi core machines. These machines can inherently run more than one process simultaneously, as opposed to single CPU machines which only simulate multi tasking. While it is still likely that the JVM will take care of these issues, the knowledge of concurrency should still prove more important and potentially applicable than ever.

The main performance benefit, especially on a single CPU machine, is when an application is waiting on an outside resource. If all work is performed by the local CPU, it is questionable whether “simulating” multiple processes will have a performance benefit, due the fact that the single CPU is doing all the work anyway and the amount of work hasn’t changed. Indeed, there is minor overhead to creating new threads in the first place. But if the application involves much waiting an outside resource, like an external web service or database, concurrency may be able to provide improved performance.

Another common implementation of this idea is in the area of Ajax. While JavaScript is single threaded (or so I am told), remote calls can be done in an asynchronous manner, so the engine is not waiting for the results of that call by can perform other tasks while waiting. A true multi threaded application can do as many of these operations simultaneously as necessary and appropriate.

Regarding improved application design, this is one area that could indicate concurrent design from the start. Take the example of a real time strategy game. If is certainly conceptually more simple to break down the game into individual, autonomous entities (units, divisions, etc) that implement certain behavior with respect to the state of the game world. A non-concurrent implementation with some sort of master controller could be seen as more complicated in that it also has to maintain the appropriate view of the world provided to each entity and translate a non real time view into what should in fact appear to be real time activity.

That being said, this simulation example is somewhat non standard. It is debatable whether most typical business, database driven applications don’t immediately scream for concurrency in their design. We will see some examples where concurrency could be an appropriate for solution for a standard web application in a future article.

In addition, performance improvements are much easier to add to a logically design, object oriented application. In fact many improvements can come without any work whatsoever, in the form of faster machines, improved JVM and libraries, etc. Most JVM’s already optimize for performance, through inlining of methods or other techniques, and trying to implement these techniques, or other ways you think will improve things, could actually make it more difficult for the compiler to perform its own optimizations.

It also is much more difficult to refractor elegance into an application that might contain numerous low level or non object oriented approaches aimed at performance improvements.

On to the examples, beginning with the very simplest one.

Extending Thread

Our first example illustrates the simplest way to create and execute a Java thread, extending the      Java.lang.Thread class. This class implements the java.lang.Runnable interface. Runnable contains one method, run();

Code Link: Example 1a.java

In example 1a, we create three instances of the Example1a class. As Example1a extends Thread, the run () method is automatically inherited and available.

Threads are started or run by calling start(), which is actually a static method in the Thread class. This causes the Example1 instance’s run() method to be called in a new thread of execution.

Here is the output from example1a

starting threads


two starting

two done

one starting

one done

three starting

three done

Output Example1a

The only interesting thing about the output is that instance two is run before instance one, even through one.start() is called prior to two.start(). This happens because the JVM thread scheduler does not guarantee any particular order of execution when scheduling threads. The start() method causes the JVM to schedule the thread for execution at some point in the future.

The output doesn’t event verify that all three tasks are indeed running concurrently. Since not much happens within each task, each task completes before the next can even get started.

In the next example, we add some additional work in the run() method.

Code Link: Example1b.java

In this example, we add a sleep property and call Thread.sleep for that time period, in this case milliseconds. This added statement simulates additional “work” that a task may be performing, or perhaps simulates a wait on an outside resource.

threads started

main sleeping

three starting

two starting

one starting

two done

three done

one done

Waking main loop


Output Example1b

As shown in the output from running this program, all three classes start up, then all three complete. This sort of proves there is some simultaneous activity happening. As you may have noticed, we also added a sleep statement to the “Main” thread. The sleep method can be called in any Java program, even one that does not explicitly implement additional multithreading. There is always at least one thread of execution in a Java application and it can be treated in many respects like any of the other Threads we’ve created, although you won’t be controlling the starting of the main thread.

You may have also noticed an additional class imported, Sleeper. This class simply encapsulates the Thread.sleep method, which we will be using often on the examples.

Code Link: Sleeper.java

The next example shows how in even the simplest examples, threads might not behave as expected. This example uses the setName() method of the Thread class, and it does what you might expect: associates a name with a thread.

Code Link: Example1C.java

In this example, instead of setting a class property to store the name, we attempt to use the name property of Thread itself. A name is passed into the constructor, where the Thread’s name is set to this value.

The output, however, shows that this naming was unsuccessful, as the name printed are Thread-0, Thread-1, and thread-2, which are actually the default names in this case. Perhaps the name cannot actually be set in this manner?

threads started


Thread-1 starting

Thread-0 starting

Thread-2 starting

Thread-1 done

Thread-2 done

Thread-0 done

Waking main loop

Done – Why didn’t the name print. Press any key to find out.

Main thread name was : three

Output Example1c

Actually, if you look at the last line of the output, where the name of the “Main” thread is printed, we see that its name was set to “three”. Either this is an extreme coincidence, or when we executed the line Example1c example3 = new Example1c(“three”, 900), it didn’t set the name of the thread associated with example example3, but instead set that associated with the Main thread. This is actually the case. Looking at the constructor of Example1,


When this line is executed, the Example1c threads have not yet been started. The actual thread executing the constructor code is the calling thread (Main). So in fact, the name of the Main thread was set three times, with “three” begin the final value set.

The following example shows how to correctly set the thread names.

Code Link: Example1d.java

The output of this program is as follows. Note the name of the Main thread.

threads started


one starting

two starting

three starting

two done

three done

one done

Waking main loop

Main thread name was : main

Output Example1d

Implementing Runnable

The more preferred way to create a thread is to implement java.lang.Runnable. When you extend Thread, you are implementing Runnable by inheritance. However, using the interface allows just about any class to act as a thread, since multiple interfaces can be implemented, but only one class can be inherited from. There is really no good reason to extend Thread, although it can sometimes be more convenience, as a later example shows.

Here is a modified version of the previous program that takes this approach.

Code Link: Example 2.java

Here is the program’s output, which is identical to that above (of course the order of thread execution may change).

two starting

three starting

one starting

threads started


two done

three done

one done

Waking main loop. Exiting

Output Example2

More fun with Runnable

In the above example, we created three instances of a single Class, and then executed each in its own thread.

The next example creates two class instances, but created three threads of execution. How does these change things?

Code Link: Example 3.java

We create two instances of a single class

Example3 example1 = new Example3(1000);

Example3 example2 = new Example3(500);

Then we create three threads from those two instances; two threads are running on a single instance.

Thread thread1 = new Thread(example1);

Thread thread2 = new Thread(example2);

Thread thread3 = new Thread(example2);

From the output below, not much has changed, but the objects were created much differently. All three threads start, print their message, and stop.

Starting threads

two (thread2) starting

one starting

two (thread1) starting

two (thread2) done

two (thread1) done

one done

Waking main


Output Example3

Not much has changed because the threads are really not doing anything. As I’ve mentioned, creating and running a thread is not very difficult. Problems start to arise when the threads do some meaningful work, particular in how they can interact with each other.

Let’s add some actual calculation and properties to the above example. Here, the run method of each class performs a calculation, then prints out the result of that calculation when exiting run().

Code Link: Example 4a.java

In this example, we create three instances of a class, and start four threads from those instances, similar to what we did in the last example.

For each threads’s run() method, we perform a calculation and store the results as an class instance property, in this case simply generate a random integer. Then we sleep, to simulate performing some additional work. When the thread awakes, it prints out the result previously calculated.

The output from this program is the following

Starting threads

three (thread2) starting. result = 93

three (thread1) starting. result = 2

one starting. result = 81

two starting. result = 73

three (thread1) exiting. result = 93

three (thread2) exiting. result = 93

one exiting. result = 81

two exiting. result = 73

Waking main

What went wrong?

Output Example4a

If things perform as expected, the result printed with the starting method should match the result printed with the exiting method. In the output above, all looks fine except for thread “three (thread 1)”. It calculates and stores a value of 2, then sleeps and prints out the stored value, which is printed as 93.

What happened here? The answer illustrates the basic operation of threading.

When we create an instance of a class, a new object is allocated and stored on the heap. Any non static properties are also allocated memory. In our case, the new property “result” is allocated and stored with the instances we create. As above, we create several instances, but for one of those instances, we create two threads. These threads, therefore share the same instance variables. The change made from one can affect the values seen in another, as this example indicates. For this to happen, the thread scheduler needs to switch control to another thread after the result of the first thread has been calculated. The second thread then performs the calculation, storing the result in the single instance variable. Then both threads awake to print the result, which will be the last stored value.

Most threading problems occur from simultaneous (concurrent) access to shared resource.

One way around this problem is to avoid the use of instance variables in cases where multiple threads are involved.

Code Link: Example 4b.java

The only change made is in moving the result variable from the class level to a local method variable in run(). Code and variables in (non static) methods are executed on the JVM stack, and each thread has its own stack. Therefore, the output is what we want.

one starting. result = 87

Starting threads

two starting. result = 77

three (thread2) starting. result = 42

three (thread1) starting. result = 76

three (thread2) exiting. result = 42

three (thread1) exiting. result = 76

one exiting. result = 87

two exiting. result = 77

Waking main

Output 4b

This situation has much in common with Java Servlet technology. Servlets are executed in a multi threaded manner. The doService(), or doGet() and doPost(), method is quite analogous to our run() method above. Any Servlet level variables run the risk of collision amongst multiple threads. This is called a Race Condition; the timing of the data access affects the data.

Another alternative solution to this problem is using the ThreadLocal object. ThreadLocal allows you to essentially create a single variable, but give each thread its own unique copy of this variable. In the example below, we store the result value in a ThreadLocal object. Note, we must switch the type from int to Integer, since we can’t define a generic object with a primitive type.

Code Link: Example 4c.java

Instead o f just accessing result directly, we must use the methods result.set () and result.get(), when using ThreadLocal. This will get and store the values specific to the current thread of execution.

The output below should yield the correct result.

Starting threads

two starting. result = 43

three (thread2) starting. result = 63

three (thread1) starting. result = 35

one starting. result = 22

three (thread1) exiting. result = 35

three (thread2) exiting. result = 63

two exiting. result = 43

one exiting. result = 22

Waking main

Output example 4c

A caveat on using ThreadLocal is necessary. Using ThreadLocal in a managed environment (ex. an app server with a Thread Pool ) could potentially cause problems if the stored object is not cleaned up correctly when the thread’s processing is finished. Any ThreadLocal variables that existing when a thread is finished, could potentially be accessed by another thread if the thread pool simply keeps the thread active and allows another task to use it.

As a final solution to the problem of Race Condition we can use synchronized blocks of code. Synchronized blocks guarantee that only one thread of execution at a time can execute a give block of code. In our earlier example, issues arose when one thread set a value then went to sleep (or was swapped out by the thread scheduler). Another task came along, set the value again, and then the first task awoke only to read the incorrect value.

Synchronized blocks allow us to force the first thread to set the value, then finish whatever task is necessary, in this case print out the value, before any other thread can gain control over that block of code.

Code Link: Eample 4d.java

In the above example, we wrap the entire run method in a synchronized block. The statement

synchronized (this) {



First gets a lock on “this”. Note the lock can be gotten on a class instance, as in this example, or on the class itself. Locking an instance allows multiple instances of that class to process concurrently. In our case, since we are concerned about two threads running on the same instance conflicting, this approach works. The output below should again show the correct output/

one starting. result = 84

Starting threads

three (thread1) starting. result = 91

two starting. result = 13

three (thread1) exiting. result = 91

three (thread2) starting. result = 86

one exiting. result = 84

three (thread2) exiting. result = 86

two exiting. result = 13

Waking main

Output example 4d

How did the output from this version differ from previous versions? Note that thread “three (thread1)” starts and completes before “three (thread2)” even starts, even though we put thread1 to sleep during that time period. This is the result of synchronization, as you might imagine, can lead to performance degradation, since no thread swapping can occur during the block. Therefore, even if we are waiting on an outside resource during this block, no other thread can gain control of that lock to execute the synchronized code.

Exceptions in Threads

Let’s try and implement a typical exception handler in our threaded program. Here, in our run () method we throw an exception to see what happens.

Code Link: Example5.java

The output is the following

threads started.


Thread-0 starting

Exception in thread “Thread-0” java.lang.NullPointerException

at example5.Example5.run(Example5.java:15)

at java.lang.Thread.run(Thread.java:619)

Output example5

That is sort of expected, as we didn’t do anything to catch or handle the Exception. Let’s try to add error handling.

Code Link: Example5a.java

Here, we wrap everything in a try catch.
We even suspend the main thread to it doesn’t finish before the thread can throw it’s Exception.

Thread-0 starting

Exception in thread “Thread-0” java.lang.NullPointerException

at example5.Example5a.run(Example5a.java:14)

at java.lang.Thread.run(Thread.java:619)

threads started

threads finally finished

Output example5a

That didn’t work. As you can see, the thread threw its exception almost immediately, certainly while the main thread was within its try catch loop. So as you might imagine, a try-catch like this will only work on the specific thread executing that code.

To catch an Exception thrown by a thread, we need to pass the Thread an instance of UncaughtExceptionHandler.

Code Link: Example5b.java

In the example above, we create things like before, but add the following lines.

thread1.setUncaughtExceptionHandler(new MyExceptionHandler());

Of course, we need to implement the actual UncaughtExceptionHandler, which is simply the following class

package example5;

public class MyExceptionHandler implements Thread.UncaughtExceptionHandler {

public void uncaughtException(Thread t, Throwable e) {

System.out.printf(“Caught Exception %s in Thread %s%n”,e.getClass(), t.getName());



Code Link: MyExceptionHandler.java

When a thread throws an uncaught exception, and remember the thread class can catch exceptions the same as any Java program can, the uncaughtException() method will be called.

The output below demonstrates this.

threads started

threads finally finished

Thread-0 starting

Caught Exception class java.lang.NullPointerException in Thread Thread-0

Output example 5b

JDK 1.5 enhancements to concurrency

JDK 1.5 introduced numerous enhancements to Java Threading as part of the import java.util.concurrent package. Most of these changes add higher level controlling structures to performance and managed tasks that before needed to be programmed at a lower level. These changes save the programmer a great deal of work and ensure are generally quite easy to use and integrate. We will look at a few of the most significant additions in the next section.

JDK1.5 introduces Executors. Instead of controlling thread creation explicitly, as was done in the above examples through thread creation and thread start, we can create an Executor, tell the executor what to create, along with some parameters, and have the executor manager thread creation and control.

In the next example, we see how using an Executor can easily control thread pooling.

Code Link: Example6.java

In this example, we instantiate three types of ExecutorService. For each of these three, we spawn 10 thread instances of the same class.

The three types we use are

  1. CachedThreadPool
  2. FixedThreadPool
  3. SingleThreadExecutor

Notice that two of these Executors are Thread Pools.

CachedThreadPool will create as many new Threads as necessary (in our case, up to 10), but reuse existing threads when they become available.

FixedThreadPool is similar to CachedThreadPool, but puts an upper limit on the number of Threads that will be created. New tasks submitted will wait until threads free up for use.

SingleThreadExecutor limits the tread pool size to one. This approach may be used for activity that must be serialized. Remember that, as the above example shows, different Executors can be used in the same application, so using a SingleThreadExecutor only affects a specific task without causing the entire application to become single threaded.

Also notice how easy it is to choose one approach or the new; simply a change in the object creation code.

Also note the shutdown() method. This doesn’t stop any of the threads that were created; it just stops new threads from being submitted to the corresponding thread pool.

Here is the (somewhat longer) output from the above program.

starting cached threads

ID:1-pool-1-thread-2 starting

ID:3-pool-1-thread-4 starting

ID:8-pool-1-thread-9 starting

ID:6-pool-1-thread-7 starting

ID:4-pool-1-thread-5 starting

ID:2-pool-1-thread-3 starting

ID:0-pool-1-thread-1 starting

ID:9-pool-1-thread-10 starting

ID:7-pool-1-thread-8 starting

ID:5-pool-1-thread-6 starting

ID:1-pool-1-thread-2 exiting

ID:3-pool-1-thread-4 exiting

ID:8-pool-1-thread-9 exiting

ID:9-pool-1-thread-10 exiting

ID:5-pool-1-thread-6 exiting

ID:7-pool-1-thread-8 exiting

ID:6-pool-1-thread-7 exiting

ID:4-pool-1-thread-5 exiting

ID:2-pool-1-thread-3 exiting

ID:0-pool-1-thread-1 exiting

starting single threads

ID:0-pool-2-thread-1 starting

ID:0-pool-2-thread-1 exiting

ID:1-pool-2-thread-1 starting

ID:1-pool-2-thread-1 exiting

ID:2-pool-2-thread-1 starting

ID:2-pool-2-thread-1 exiting

ID:3-pool-2-thread-1 starting

ID:3-pool-2-thread-1 exiting

ID:4-pool-2-thread-1 starting

ID:4-pool-2-thread-1 exiting

ID:5-pool-2-thread-1 starting

ID:5-pool-2-thread-1 exiting

ID:6-pool-2-thread-1 starting

ID:6-pool-2-thread-1 exiting

ID:7-pool-2-thread-1 starting

ID:7-pool-2-thread-1 exiting

ID:8-pool-2-thread-1 starting

ID:8-pool-2-thread-1 exiting

ID:9-pool-2-thread-1 starting

starting fixed threads

threads started

ID:1-pool-3-thread-2 starting

ID:0-pool-3-thread-1 starting

ID:2-pool-3-thread-3 starting

ID:9-pool-2-thread-1 exiting

ID:1-pool-3-thread-2 exiting

ID:2-pool-3-thread-3 exiting

ID:4-pool-3-thread-3 starting

ID:0-pool-3-thread-1 exiting

ID:5-pool-3-thread-1 starting

ID:3-pool-3-thread-2 starting

ID:4-pool-3-thread-3 exiting

ID:6-pool-3-thread-3 starting

ID:5-pool-3-thread-1 exiting

ID:7-pool-3-thread-1 starting

ID:3-pool-3-thread-2 exiting

ID:8-pool-3-thread-2 starting

ID:6-pool-3-thread-3 exiting

ID:9-pool-3-thread-3 starting

ID:7-pool-3-thread-1 exiting

ID:8-pool-3-thread-2 exiting

ID:9-pool-3-thread-3 exiting

Output example6

With the CachedThreadPool, all 10 tasks start immediately, and then exit. With, SingleThreadExecutor each task is started then exits before the next task starts. With FixedThreadPool, three tasks start then exit, before the next three tasks start.

Returning Values

Another additional to JDK 1.5 is the ability for threads to return values. Prior to this capability, you needed to store method results in another object, or make the result available in a public get type method and handle all the issues around multi threaded access to shared data.

In JDK 1.5 we thread can return values by implementing the java.util.concurrent.Callable interface instead of java.lang.Runnable.

This approach is illustrated in the example below.

Code Link: Example7.java

In this example, we run () with call(). Call can take any return type, similar to any other java method.

The call() method in this example performs some (simulated) work, then returns an integer result.

starting cached threads

ID:0-pool-1-thread-1 starting

ID:9-pool-1-thread-10 starting

ID:8-pool-1-thread-9 starting

ID:6-pool-1-thread-7 starting

ID:3-pool-1-thread-4 starting

ID:4-pool-1-thread-5 starting

ID:1-pool-1-thread-2 starting

ID:5-pool-1-thread-6 starting

ID:2-pool-1-thread-3 starting

threads started.

ID:7-pool-1-thread-8 starting

ID:4-pool-1-thread-5 exiting with retval:4

ID:6-pool-1-thread-7 exiting with retval:6

ID:3-pool-1-thread-4 exiting with retval:3

ID:5-pool-1-thread-6 exiting with retval:5

ID:1-pool-1-thread-2 exiting with retval:1

ID:8-pool-1-thread-9 exiting with retval:8

ID:0-pool-1-thread-1 exiting with retval:0

ID:7-pool-1-thread-8 exiting with retval:7

ID:9-pool-1-thread-10 exiting with retval:9

ID:2-pool-1-thread-3 exiting with retval:2

Output example7

The output shows each class starting up, and then exiting along with the return value calculated.

Having a return value didn’t really do much for us in this example, as that value was lost when the thread exited.

To read this value, one approach might be to wait for the threads to finish, then interrogate the result value.

Let’s show how this could be done.

Code Link: Example7a.java

In this example, we create several instances of a class that inherits Thread and store these instances in an ArrayList. Since these are already first class Thread objects, we loop through the Array list, and start() each Thread.

We can then wait for the threads complete, but looping through the array list again

for (Example7a thread : threads) {

and calling


This method will cause the current Thread, in this case the Main thread, to wait until thread completes. The loop will therefore exit when all threads have completed.

The results show this performs as expected

adding threads

starting threads

threads started.

waiting on 0

ID:0-Thread-0 sleeping for 2454 ms

ID:2-Thread-2 sleeping for 2887 ms

ID:4-Thread-4 sleeping for 1515 ms

ID:6-Thread-6 sleeping for 4073 ms

ID:8-Thread-8 sleeping for 2842 ms

ID:1-Thread-1 sleeping for 1227 ms

ID:3-Thread-3 sleeping for 1132 ms

ID:5-Thread-5 sleeping for 4952 ms

ID:7-Thread-7 sleeping for 1351 ms

ID:9-Thread-9 sleeping for 1605 ms

ID:3-Thread-3 exiting

ID:1-Thread-1 exiting

ID:7-Thread-7 exiting

ID:4-Thread-4 exiting

ID:9-Thread-9 exiting

ID:0-Thread-0 exiting

Thread 0 is complete

waiting on 1

Thread 1 is complete

waiting on 2

ID:8-Thread-8 exiting

ID:2-Thread-2 exiting

Thread 2 is complete

waiting on 3

Thread 3 is complete

waiting on 4

Thread 4 is complete

waiting on 5

ID:6-Thread-6 exiting

ID:5-Thread-5 exiting

Thread 5 is complete

waiting on 6

Thread 6 is complete

waiting on 7

Thread 7 is complete

waiting on 8

Thread 8 is complete

waiting on 9

Thread 9 is complete


Output example 7a

Since we are implementing (by inheritance) Runnable, there is no actual return value. However, the main thead can call the public getter on id, which is the return value we want. Remember that if we create multiple threads for a single class instance, this approach could lead to a race condition. But in our example, we create a new instance of the class in the line

threads.add(new Example7a(i));

Now let’s try this approach with what appears to be a preferred method for retrieve values , the Callable interface. We will also add a bit of randomness, but changing up the sleep time used during the call() method.

Code Link: Example7b.java

The above example does things similarly to the prior example. Here we use an ExecutorService to create the thread. Also, since in this example, the instantiated class, Example7b, does not extend Thread and is therefore not a Thread object so we cannot call thread.join() in the final check loop. Instead, we get the underlying Thread with


and attempt to wait using this approach.

Running the program will show that it hangs (or trust me, it hangs).

starting threads

submitting threads

waiting on 0

ID:0-pool-1-thread-1 sleeping for 1824 ms.

ID:2-pool-1-thread-3 sleeping for 2430 ms.

ID:4-pool-1-thread-5 sleeping for 1748 ms.

ID:6-pool-1-thread-7 sleeping for 3887 ms.

ID:8-pool-1-thread-9 sleeping for 1338 ms.

ID:1-pool-1-thread-2 sleeping for 4987 ms.

ID:3-pool-1-thread-4 sleeping for 4440 ms.

ID:5-pool-1-thread-6 sleeping for 4645 ms.

ID:7-pool-1-thread-8 sleeping for 4960 ms.

ID:9-pool-1-thread-10 sleeping for 4435 ms.

ID:8-pool-1-thread-9 exiting with retval:8

ID:4-pool-1-thread-5 exiting with retval:4

ID:0-pool-1-thread-1 exiting with retval:0

ID:2-pool-1-thread-3 exiting with retval:2

ID:6-pool-1-thread-7 exiting with retval:6

ID:9-pool-1-thread-10 exiting with retval:9

ID:3-pool-1-thread-4 exiting with retval:3

ID:5-pool-1-thread-6 exiting with retval:5

ID:7-pool-1-thread-8 exiting with retval:7

ID:1-pool-1-thread-2 exiting with retval:1

Output example 7b

The main thread starts all the threads, and then waits for the first to complete. Each thread completes its work, but Main is still waiting on thead 0.

The reason for this is that we told main to wait for itself to finish.

Looking at the getThread getter

protected Thread getThread() {

return Thread.currentThread();


It returns a thread, but actually returns the current thread executing that statement. This method is called by Main, so it returns the thread underlying Main. This causes an endless wait cycle, since Main can’t finish before the check loop finished, and the check loop won’t finish until main finished. Essentially we have deadlock on itself.

Before we discuss the correct way to retrieve return values from threads, lets continue down this path and look and other ways to ‘wait’ for threads to finish.

One way is by using the CyclicBarrier, introduced in JDK 1.5.

This object is useful when threads need to coordinate with other threads.

In this example, we create a CyclicBarrier and pass it to each of the threads created. The threads then perform their processing and then call cyclicBarrier.await(). This acts like a staging area, where all threads will wait until the barrier “opens”, which occurs after a specific number of threads call await.

The code illustrates this.

Code Link: Example7c.java

In the output below, we see each thread execute , then wait at the cyclicBarrier. Periodically, the main thread awakens, checks to see if the barrier is open, then sleeps. When all threads have completed and the barrier is open, Main completes and exits.

starting threads

submitting threads

waiting for threads to finish

10 to go.

ID:1-pool-1-thread-2 sleeping for 3898 ms

ID:0-pool-1-thread-1 sleeping for 3002 ms

ID:2-pool-1-thread-3 sleeping for 4934 ms

ID:4-pool-1-thread-5 sleeping for 2566 ms

ID:6-pool-1-thread-7 sleeping for 2261 ms

ID:8-pool-1-thread-9 sleeping for 4656 ms

ID:9-pool-1-thread-10 sleeping for 3932 ms

ID:7-pool-1-thread-8 sleeping for 2067 ms

ID:5-pool-1-thread-6 sleeping for 750 ms

ID:3-pool-1-thread-4 sleeping for 2608 ms

ID:5-pool-1-thread-6 Finished work. waiting along with 0 others

9 to go.

9 to go.

ID:7-pool-1-thread-8 Finished work. waiting along with 1 others

ID:6-pool-1-thread-7 Finished work. waiting along with 2 others

ID:4-pool-1-thread-5 Finished work. waiting along with 3 others

ID:3-pool-1-thread-4 Finished work. waiting along with 4 others

5 to go.

ID:0-pool-1-thread-1 Finished work. waiting along with 5 others

ID:1-pool-1-thread-2 Finished work. waiting along with 6 others

ID:9-pool-1-thread-10 Finished work. waiting along with 7 others

2 to go.

ID:8-pool-1-thread-9 Finished work. waiting along with 8 others

ID:2-pool-1-thread-3 Finished work. waiting along with 9 others

Cleaning up

ID:2-pool-1-thread-3 exiting with retval:2

ID:5-pool-1-thread-6 exiting with retval:5

ID:7-pool-1-thread-8 exiting with retval:7

ID:6-pool-1-thread-7 exiting with retval:6

ID:4-pool-1-thread-5 exiting with retval:4

ID:3-pool-1-thread-4 exiting with retval:3

ID:0-pool-1-thread-1 exiting with retval:0

ID:1-pool-1-thread-2 exiting with retval:1

ID:9-pool-1-thread-10 exiting with retval:9

ID:8-pool-1-thread-9 exiting with retval:8


Output example 7c

The cyclic barrier is useful when threads coordinate the work they are doing with other threads. Our next option is a better choice in our situation, where one thread needs to wait for the completion of a group of other threads. We could have had Main call await(), but then it would be participating in the work, not just observing and waiting, and that just doesn’t seem right.

A CountDownLatch is initialized with a count value, then any task can call countdown() on the latch, decrementing the count by one. Calling countdown does not block the calling task, it can continue processing. Calling await() however, does block the calling task until the latch opens.

The following example illustrates this

Code Link: Example7d.java

This is a more natural approach to the problem of waiting for a set number of tasks to complete. No sleep/awake cycle was necessary in the checking class.

starting threads

ID:0-pool-1-thread-1 sleeping for 4129 ms.

ID:2-pool-1-thread-3 sleeping for 3522 ms.

ID:4-pool-1-thread-5 sleeping for 692 ms.

submitting threads

waiting for threads to finish

ID:6-pool-1-thread-7 sleeping for 3644 ms.

ID:8-pool-1-thread-9 sleeping for 1250 ms.

ID:1-pool-1-thread-2 sleeping for 2516 ms.

ID:5-pool-1-thread-6 sleeping for 3562 ms.

ID:3-pool-1-thread-4 sleeping for 1871 ms.

ID:7-pool-1-thread-8 sleeping for 3177 ms.

ID:9-pool-1-thread-10 sleeping for 3038 ms.

ID:4-pool-1-thread-5 finished work.

ID:4-pool-1-thread-5 exiting. 9 to go

ID:8-pool-1-thread-9 finished work.

ID:8-pool-1-thread-9 exiting. 8 to go

ID:3-pool-1-thread-4 finished work.

ID:3-pool-1-thread-4 exiting. 7 to go

ID:1-pool-1-thread-2 finished work.

ID:1-pool-1-thread-2 exiting. 6 to go

ID:9-pool-1-thread-10 finished work.

ID:9-pool-1-thread-10 exiting. 5 to go

ID:7-pool-1-thread-8 finished work.

ID:7-pool-1-thread-8 exiting. 4 to go

ID:2-pool-1-thread-3 finished work.

ID:2-pool-1-thread-3 exiting. 3 to go

ID:5-pool-1-thread-6 finished work.

ID:5-pool-1-thread-6 exiting. 2 to go

ID:6-pool-1-thread-7 finished work.

ID:6-pool-1-thread-7 exiting. 1 to go

ID:0-pool-1-thread-1 finished work.

ID:0-pool-1-thread-1 exiting. 0 to go


Output example 7d

And finally, let’s get back to the preferred approach to getting return from threads, the Future object.

Instead of storing our tasks in an ArrayList, we store them in a list of Future objects. The Future object represents the results of an asynchronous operation.

In the example below, we create a List of Future TaskResult objects

List<Future<TaskResult>> results = new ArrayList<Future<TaskResult>>();

Notice the use of Generic types.

We could create a Future<Integer>, but then we wouldn’t have access to name or other instance variables.

The example below shows this implementation

Code Link: Example7e.java

Here, instead of just calling the submit method to start each thread, we call submit and set store the result value in the Future list. Submit actually has a Future return type. The return type of call() must match the type of Future. No additional changes are necessary for the call() method, such as a countdown. The call() simply completes and returns a value. That value is stored in the future object.

The main thread then loops through the Future List similarly to how it looped through the ArrayList in the previous examples. For each future object, it can get the result of the operation by calling


The first part of this method chain, taskResult.get(), will cause the calling thread to block until future task completes. We could also call get() with a timeout parameter, which will only wait for a specific time interval. There are also additional methods to see if a task is complete.

Code Link: Cleanup.java

Here is the output from this example.

starting cached threads

ID:0-pool-1-thread-1 starting

ID:2-pool-1-thread-3 starting

ID:4-pool-1-thread-5 starting

ID:6-pool-1-thread-7 starting

threads started.

getting results.

ID:8-pool-1-thread-9 starting

ID:1-pool-1-thread-2 starting

ID:3-pool-1-thread-4 starting

ID:5-pool-1-thread-6 starting

ID:7-pool-1-thread-8 starting

ID:9-pool-1-thread-10 starting

ID:0-pool-1-thread-1 exiting with retval:0

ID:8-pool-1-thread-9 exiting with retval:8

ID:5-pool-1-thread-6 exiting with retval:5

ID:6-pool-1-thread-7 exiting with retval:6

ID:7-pool-1-thread-8 exiting with retval:7

ID:3-pool-1-thread-4 exiting with retval:3

ID:4-pool-1-thread-5 exiting with retval:4

ID:2-pool-1-thread-3 exiting with retval:2

ID:1-pool-1-thread-2 exiting with retval:1

ID:9-pool-1-thread-10 exiting with retval:9

Thread: pool-1-thread-1: result: 0

Thread: pool-1-thread-2: result: 1

Thread: pool-1-thread-3: result: 2

Thread: pool-1-thread-4: result: 3

Thread: pool-1-thread-5: result: 4

Thread: pool-1-thread-6: result: 5

Thread: pool-1-thread-7: result: 6

Thread: pool-1-thread-8: result: 7

Thread: pool-1-thread-9: result: 8

Thread: pool-1-thread-10: result: 9

exiting main

Output example 7e


We briefly mentioned deadlock in perhaps an unusual circumstance where a thread is deadlocked on itself. The more common occurrence is when two tasks are waiting on a resource the other task has.

This scenario is illustrated in the following example. Here, instead of simply sleeping, which can actually give up a lock that a task has, we load an external web page into an XML document (not caring whether the html is actual valid XML). This will certainly cause some processing delay, and is a good example of waiting on an outside resource, where multiple threads make sense.

Code Link: Example8.java

In this example, we create several threads as before. When started, each thread can do one of two things, depending on whether it has an odd or even id. In the case of even id’s, it gets a lock on Object1 , performs some processing, then attempts to get a lock on object 2. Locks are acquired implicitly, by attempting to enter a synchronized block of code (A Lock object is also introduced in JDK1.5). For the case of odd ids, it first gets a lock on object 2, performs some processing, and then attempts to get a lock on object 1. If we time things just right, one thread has a lock on 1 and is waiting for 2, while another has a lock on 2 and is waiting for 1, causing a deadlock.

In this example work1 and work 2 are created solely for their locks and serve no other purpose. This is perfectly legal.

Her e is the output illustrating this.

Starting threads. exiting

pool-1-thread-1 starting. getting resource one …

pool-1-thread-2 starting. getting resource two +++

pool-1-thread-3 starting. getting resource one …

pool-1-thread-4 starting. getting resource two +++

pool-1-thread-5 starting. getting resource one …

pool-1-thread-1 getting resource two …

pool-1-thread-2 getting resource one +++

(program hangs due to deadlock)

Output example 8

Deadlock can also occur when synchronized methods are used. Unlike the above example, where an explicit lock on an object is acquired, the next example acquires a lock on the class instance itself. Both are potential deadlock scenarios.

In the following example, instead of a local synchronized block, a synchronized method in an external class is called.

Code Link: Example8a.java

Code Link: SyncWorker.java

The output shows the predicted deadlock.

pool-1-thread-1 starting. getting resource worker1

pool-1-thread-2 starting. getting resource worker2

pool-1-thread-5 starting. getting resource worker1

Starting threads. exiting

pool-1-thread-3 starting. getting resource worker1

pool-1-thread-4 starting. getting resource worker2

pool-1-thread-1processing. getting resource worker2

pool-1-thread-2processing. getting resource worker1

Output example 8a

If we remove the synchronization, as in the following example, the deadlock is avoided. In reality, we can assume the synchronization was there for a reason, and not simply to cause a deadlock. Therefore, simply removing synchronization is not the answer. The solution is dependent on the actual problem at hand. As a general heuristic, try to avoid multiple, nested lock acquisition and be aware of any external synchronous methods called.

Code Link: Example8b.java

Code Link: Worker.java

pool-1-thread-2 starting. getting resource worker2

pool-1-thread-5 starting. getting resource worker1

pool-1-thread-3 starting. getting resource worker1

pool-1-thread-1 starting. getting resource worker1

Starting threads. exiting

pool-1-thread-4 starting. getting resource worker2

pool-1-thread-2 processing. getting resource worker1

pool-1-thread-1 processing. getting resource worker2

pool-1-thread-4 processing. getting resource worker1

pool-1-thread-3 processing. getting resource worker2

pool-1-thread-5 processing. getting resource worker2

pool-1-thread-2 exiting

pool-1-thread-5 exiting

pool-1-thread-1 exiting

pool-1-thread-4 exiting

pool-1-thread-3 exiting

Output example 8b

Topics not covered

This article certainly does not intend to cover the entire domain of Java concurrency. Several excellent references are listed in the appendix. However, some topics are recommended for additional study. It is recommended that the reader become briefly acquainted with wait() and notify() methods and Blocking queue. Please research these on your own, as there was not enough neither time nor space to include these topics in the original presentation given at the Sarasota Java Users group.

The next article will discuss performance profiling of multi-threaded applications.

Books and links

  1. Java Concurrency In Practice: The best, most current book on the subject, written by some of the people who wrote the Java concurrency implementation


  1. Thinking in Java has a nice, long section on concurrency, updated for JDK1.5. This book should be on every Java programmer’s bookshelf and can keep you learning for the rest of your Java career, or until the next edition is out.


  1. Java Tutorial: Concurrency

From Sun.com. This article serves as a good online reference when needed.


  1. Any article by Brian Goetz, one of the authors of Java Concurrency In Practice. Search Google for some good, though dated, IBM publications.
  2. http://tutorials.jenkov.com/java-concurrency/index.html

Basically the same material I chose to present to the Sunjug.