News »Browse Articles »
Building Multithreaded Java Applications
0
Building Multithreaded Java Applications
Most server-side applications require the ability to process tasks concurrently, which improves performance and increases utilization of hardware resources. In early versions of Java (1.4 or earlier), developers needed to implement concurrent applications—including thread pool logic—themselves using low-level language constructs and the Java Thread API. The results were often poor. The nature of the Java Thread API often led unwitting programmers to develop code that introduced hard-to-debug programming errors.
In Java 5.0, Sun introduced the Java concurrency utilities (JSR-166) to address these issues and provide a standard set of APIs to create concurrent applications. This article explores some of the features provided by the Java concurrency package and demonstrates techniques for writing concurrent applications using these utilities.
Challenges of Concurrent Programming
Since its inception, Java has provided the Thread class and low-level language constructs such as synchronized and volatile for developing platform-independent concurrent applications. However, building concurrent applications with these features has never been easy. Developers faced the following challenges:
* Incorrect programming can lead to deadlocks, where two or more threads waiting for each other are blocked forever.
* No mechanism is available for writing wait-free, lock-free algorithms in the Java language. Developers must use native code.
* Developers have to write their own complex thread pool logic, which can be tricky and prone to error.
Brief Overview of Java Concurrency Utilities
JSR-166 (Java concurrency utilities), which is part of Java 5.0, greatly simplifies the development of concurrent applications in Java by focusing on breadth and providing critical functionality that is useful across a wide range of concurrent programming styles.
Java concurrency utilities provides multiple features that developers can leverage for faster, more predictable development of concurrent applications. These features free developers from reinventing the wheel by writing custom code. Some of JSR-166`s most notable features are:
1. Standard interfaces and frameworks for defining custom thread-like sub systems
2. A mechanism for standardizing invocation, scheduling, execution, and control of asynchronous tasks, according to a set of execution policies in the Executor framework
3. A mechanism for thread coordination through classes such as semaphore, mutexe, barrier, latche, and exchangers
4. Non-blocking FIFO queue implementation (the ConcurrentLinkedQueue class) for scalable, efficient thread-safe operations
5. Blocking queue implementation classes to cover the most common usage contexts for the producer/consumer approach, messaging, parallel tasking, and related concurrent designs
6. A framework for locking and waiting for conditions that is distinct from the built-in synchronization and monitors
7. Ready-to-use classes for lock-free, thread-safe programming on single variables
Developing a Concurrent Java Application
The sections to follow demonstrate how to use the Java concurrency utility API to develop a multithreaded e-commerce application that processes orders placed online. After the application validates and authorizes orders, it places them in the order-processing queue (java.util.concurrent.BlockingQueue). A pool of order-processor threads polls the order queue continuously and processes the orders when they become available.
Decoupling the application`s order-processing code provides the flexibility to increase or decrease the order-processing rate by changing the thread pool size. Putting order objects in a concurrent BlockingQueue ensures that a particular order is processed by only one processor, and it takes care of synchronization automatically.
The code snippets in the upcoming sections are taken from the application source code that accompanies this article.
Extending ThreadPoolExecutor
The Executor interface defines only one method and decouples task submission from how the task will be run. The ExecutorService sub-interface defines additional methods for submitting and tracking asynchronous tasks, as well as shutting down the thread pool. The ThreadPoolExecutor class is a concrete implementation of the ExecutorService interface, which should be sufficient for most of the order-processing application`s requirements.
ThreadPoolExecutor also provides useful hookup methods (e.g., beforeExecute), which can be overridden for customization purposes. The CustomThreadPoolExecutor class in Listing 1 extends the ThreadPoolExecutor class and overrides the beforeExecute, afterExecute, and terminated methods.
@Override
public void afterExecute(Runnable r, Throwable t) {
super.afterExecute(r, t);
Logger.log("After calling afterExecute() method for a thread "
+ r);
}
@Override
public void terminated() {
super.terminated();
Logger.log("Threadpool terminated");
}
Source:
http://www.devx.com/Java/Article/41377?trk=DXRSS_LATEST
In Java 5.0, Sun introduced the Java concurrency utilities (JSR-166) to address these issues and provide a standard set of APIs to create concurrent applications. This article explores some of the features provided by the Java concurrency package and demonstrates techniques for writing concurrent applications using these utilities.
Challenges of Concurrent Programming
Since its inception, Java has provided the Thread class and low-level language constructs such as synchronized and volatile for developing platform-independent concurrent applications. However, building concurrent applications with these features has never been easy. Developers faced the following challenges:
* Incorrect programming can lead to deadlocks, where two or more threads waiting for each other are blocked forever.
* No mechanism is available for writing wait-free, lock-free algorithms in the Java language. Developers must use native code.
* Developers have to write their own complex thread pool logic, which can be tricky and prone to error.
Brief Overview of Java Concurrency Utilities
JSR-166 (Java concurrency utilities), which is part of Java 5.0, greatly simplifies the development of concurrent applications in Java by focusing on breadth and providing critical functionality that is useful across a wide range of concurrent programming styles.
Java concurrency utilities provides multiple features that developers can leverage for faster, more predictable development of concurrent applications. These features free developers from reinventing the wheel by writing custom code. Some of JSR-166`s most notable features are:
1. Standard interfaces and frameworks for defining custom thread-like sub systems
2. A mechanism for standardizing invocation, scheduling, execution, and control of asynchronous tasks, according to a set of execution policies in the Executor framework
3. A mechanism for thread coordination through classes such as semaphore, mutexe, barrier, latche, and exchangers
4. Non-blocking FIFO queue implementation (the ConcurrentLinkedQueue class) for scalable, efficient thread-safe operations
5. Blocking queue implementation classes to cover the most common usage contexts for the producer/consumer approach, messaging, parallel tasking, and related concurrent designs
6. A framework for locking and waiting for conditions that is distinct from the built-in synchronization and monitors
7. Ready-to-use classes for lock-free, thread-safe programming on single variables
Developing a Concurrent Java Application
The sections to follow demonstrate how to use the Java concurrency utility API to develop a multithreaded e-commerce application that processes orders placed online. After the application validates and authorizes orders, it places them in the order-processing queue (java.util.concurrent.BlockingQueue). A pool of order-processor threads polls the order queue continuously and processes the orders when they become available.
Decoupling the application`s order-processing code provides the flexibility to increase or decrease the order-processing rate by changing the thread pool size. Putting order objects in a concurrent BlockingQueue ensures that a particular order is processed by only one processor, and it takes care of synchronization automatically.
The code snippets in the upcoming sections are taken from the application source code that accompanies this article.
Extending ThreadPoolExecutor
The Executor interface defines only one method and decouples task submission from how the task will be run. The ExecutorService sub-interface defines additional methods for submitting and tracking asynchronous tasks, as well as shutting down the thread pool. The ThreadPoolExecutor class is a concrete implementation of the ExecutorService interface, which should be sufficient for most of the order-processing application`s requirements.
ThreadPoolExecutor also provides useful hookup methods (e.g., beforeExecute), which can be overridden for customization purposes. The CustomThreadPoolExecutor class in Listing 1 extends the ThreadPoolExecutor class and overrides the beforeExecute, afterExecute, and terminated methods.
@Override
public void afterExecute(Runnable r, Throwable t) {
super.afterExecute(r, t);
Logger.log("After calling afterExecute() method for a thread "
+ r);
}
@Override
public void terminated() {
super.terminated();
Logger.log("Threadpool terminated");
}
Source:
http://www.devx.com/Java/Article/41377?trk=DXRSS_LATEST
