Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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

Modern threading: A Java concurrency primer

Understanding Java threads in a post-JDK 1.4 world

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

Page 5 of 7

Listing 3. MonitorModel

import java.util.Random;

class MonitorModel {
   public static void main (String [] args) {
      new RemoteHost("example 1");
      new RemoteHost("example 2");
   }
}

class MonitoredObject {
}

// This models a simple monitor of a remote host, as an
// administrative program might use.  A new value from
// the RemoteHost appears every 'delay' milliseconds, and
// is reported to the screen.
class RemoteHost extends MonitoredObject implements Runnable {
    String name;
    int delay;
    RemoteHost(String n) {
        name = n;
        new Thread(this).start();
    }
    public void run() {
      int count = 0;
      Random r = new Random();

        // Continue indefinitely, until a keyboard interrupt.
      while (count++) {
         try {
            int delay = r.nextInt(1000);
            System.out.format(
              "Line #%d from RemoteHost '%s', after %d-milliseconds.\n",
                                             count, name, delay);
            Thread.currentThread().sleep(delay);
         }
         catch (InterruptedException ie) {
            // This would be a surprise.
         }
     count++;
      }
    }
}

When you run this example, you'll see output from two different threads interleave unpredictably, as is likely to happen in a real-world system monitor. Output is likely to include "runs" where one RemoteHost reports repeatedly while the other is silent. Listing 4 shows three notices from 'example-1' in succession:

Listing 4. Output from MonitorModel

.
      .
      .
Line #54 from RemoteHost 'example 1', after 875-milliseconds.
Line #59 from RemoteHost 'example 2', after 964-milliseconds.
Line #55 from RemoteHost 'example 1', after 18-milliseconds.
Line #56 from RemoteHost 'example 1', after 261-milliseconds.
Line #57 from RemoteHost 'example 1', after 820-milliseconds.
Line #60 from RemoteHost 'example 2', after 807-milliseconds.
Line #58 from RemoteHost 'example 1', after 525-milliseconds.
      .
      .
      .

Using Runnable is thus nearly as succinct as directly subclassing from Thread. (Remember that most application code relies on Runnable definitions rather than Thread subclassing, if only to avoid a multiple-inheritance conflict.)

About monitors

Note that monitor in Listing 3 stems from the vocabulary of system administrators or network operators, who monitor objects -- often physical ones -- for which they're responsible. Coincidentally, programming theory applies the same word to a specific concept in concurrency. In a classic JavaWorld article from 1997, Bill Venners explained monitors thus:

A monitor is basically a guardian in that it watches over a sequence of code, making sure that only one thread at a time executes the code ... Each monitor is associated with an object reference. When a thread arrives at the first instruction in a block of code that is under the watchful eye of a monitor, the thread must obtain a lock on the referenced object. The thread is not allowed to execute the code until it obtains the lock. Once it has obtained the lock, the thread enters the block of protected code.

The examples of multithreading to this point have involved little coordination between threads; there's been no particular consequence for one thread executing before another, nor much teamwork required between them. A programming monitor is one of several mechanisms for managing thread synchronization. Locking is another concept, which I'll discuss shortly.