15. Executor Framework for asynchronous execution public interface Executor { void execute (Runnable command); } public interface ExecutorService extends Executor { .. } public class Executors { //Factory methods static ExecutorService newFixedThreadPool(int poolSize); ... } Executor pool = Executors.newFixedThreadPool(5); pool.execute ( runnable ) ;
16.
17. Thread Pool Example class WebService { public static void main(String[] args) { Executor pool = Executors.newFixedThreadPool(5); ServerSocket socket = new ServerSocket(999); for (;;) { final Socket connection = socket.accept(); Runnable task = new Runnable() { public void run() { new Handler().process ( connection ); } } pool.execute ( task ) ; } } } class Handler { void process (Socket s); }
18.
19.
20. ScheduledExecutorService Example ScheduledExecutorService sched = Executors. newSingleThreadScheduledExecutor (); public void runTwiceAnHour(long howLong) { final Runnable rTask = new Runnable() { public void run() { /* Work to do */ } }; final ScheduledFuture<?> rTaskFuture = sched. scheduleAtFixedRate (rTask, 0, 1800, SECONDS); sched. schedule (new Runnable { public void run { rTaskFuture.cancel(true); } }, howLong, SECONDS); }
21.
22.
23.
24.
25. Lock Example Lock lock = new RentrantLock(); public void accessProtectedResource() throws IllegalMonitorStateException { lock.lock(); try { // Access lock protected resource } finally { // Ensure lock is always released lock.unlock(); } }
Lets look at some of the changes and new features in the Java Virtual Machine
Previously Java has supported several very primitive mechanisms for co-ordinating a number of threads. The synchronized keyword can be applied to methods or code blocks and the Thread class supports the wait, notify, sleep and interrupt mothods. The problem with these primitive mechanisms is that they are just that: primitive. As we will see the new utilities will greatly enhance Java applications in terms of scalability, performance, readability and thread safety.
The idea behind the new concurrency utilities is to provide a much richer set of functions that programmers can use to create simple and powerful multi-threaded applications, in the same way that the Collections classes provided a much richer set of data structure based APIs. By providing much finer granularity of locking and different approaches such as multiple read-single write locks a secondary aim is t o enable the performance of a multi-threaded Java application to match or exceed that of native C applications in the high-end server environment. Previously Java has supported several very primitive mechanisms for co-ordinating a number of threads. The synchronized keyword can be applied to methods or code blocks and the Thread class supports the wait, notify, sleep and interrupt mothods. The problem with these primitive mechanisms is that they are just that: primitive. As we will see the new utilities will greatly enhance Java applications in terms of scalability, performance, readability and thread safety.
Here is a list of things we'll talk about in this session. This is not an exhaustive list of all the new features, but given the limited time we have this should give you a good grasp of the main areas of functionality. One of the main changes in using the new concurrency utilities is the concept of moving away from interacting directly with a thread object. As we'll see the new and preferred way is through an interface called ExecutorService. There are several factory methods available to easily provide the programmer with standardised mechanisms for the Executor such as thread pools, single thread and priority threads. # Task Scheduling Framework - The Executor framework is a framework for standardizing invocation, scheduling, execution, and control of asynchronous tasks according to a set of execution policies. Implementations are provided that allow tasks to be executed within the submitting thread, in a single background thread (as with events in Swing), in a newly created thread, or in a thread pool, and developers can create of Executor supporting arbitrary execution policies. The built-in implementations offer configurable policies such as queue length limits and saturation policy which can improve the stability of applications by preventing runaway resource consumption. # Concurrent Collections - Several new Collections classes have been added, including the new Queue and BlockingQueue interfaces, and high-performance, concurrent implementations of Map, List, and Queue. Until now it has required relatively complex coding to allow a child thread to return a result to the its parent. This is even more complex when it is necessary to synchonize the threads so that the parent can only continue when the child has completed generatijng the result. This becomes very simple now through the use of Callable and Future. Semaphores are a well understood mechanism that are now supported on Java. BlockingQueues allow simple data structures to be used by multiple threads in a concurrent way such that the programmer is not responsible for ensuring safe concurrent access. Lastly the idea of an Atomic variable that can safely be accessed and modified is also iincluded in the concurrency utilities.
Here is a list of things we'll talk about in this session. This is not an exhaustive list of all the new features, but given the limited time we have this should give you a good grasp of the main areas of functionality. One of the main changes in using the new concurrency utilities is the concept of moving away from interacting directly with a thread object. As we'll see the new and preferred way is through an interface called ExecutorService. There are several factory methods available to easily provide the programmer with standardised mechanisms for the Executor such as thread pools, single thread and priority threads. # Task Scheduling Framework - The Executor framework is a framework for standardizing invocation, scheduling, execution, and control of asynchronous tasks according to a set of execution policies. Implementations are provided that allow tasks to be executed within the submitting thread, in a single background thread (as with events in Swing), in a newly created thread, or in a thread pool, and developers can create of Executor supporting arbitrary execution policies. The built-in implementations offer configurable policies such as queue length limits and saturation policy which can improve the stability of applications by preventing runaway resource consumption. # Concurrent Collections - Several new Collections classes have been added, including the new Queue and BlockingQueue interfaces, and high-performance, concurrent implementations of Map, List, and Queue. Until now it has required relatively complex coding to allow a child thread to return a result to the its parent. This is even more complex when it is necessary to synchonize the threads so that the parent can only continue when the child has completed generatijng the result. This becomes very simple now through the use of Callable and Future. Semaphores are a well understood mechanism that are now supported on Java. BlockingQueues allow simple data structures to be used by multiple threads in a concurrent way such that the programmer is not responsible for ensuring safe concurrent access. Lastly the idea of an Atomic variable that can safely be accessed and modified is also iincluded in the concurrency utilities.
As mentioned earlier programmers should now not interact directly with the Thread class. Before, we would create a class that implemented the Runnable interface. To start this in a new thread we would use a line like this: create a new thread with using the Runnable class and call the start method that would in turn call the run method in our class. This is still quite correct, but the idea is to replace this with an abstracted interface, Executor. Instead of calling start we call execute. Since this is abstracted away from the Thread class it becomes a simple task to change the way we handle the threading should we wish to do so at a later date. For example, we could start with a piece of code that creates a single thread to execute our new code. As requirements and processing power change we find that we need to run a number of threads for our class. We can simply change the factory method we use to create a thread pool and we are then able to use the same class in a number of threads rather than just one.
Here is an example of code that uses the new Executor, Executors and ExecutorService classes. The example is a standard web service class that needs to handle a number of incoming connections simultaneously through a number of separate threads. The number of threads needs to be bounded to prevent the system from running out of resources when the load becomes too high. Previously it would have been necessary to create your own thread pooling class that would create a set of threads and then manage all of the alloaction and deallocation of those threads with all of the required concurrent access controls. With the concurrency utilities this is all provided by default. In the main routine we initialise a new fixed thread pool with a size of 7. We use the newFixedThreadPool method of the Executors class. This will return a ExecutorService object. Since ExecutorService implements the Executor interface we can assign it to an Executor object reference. To handle an incoming connection we simply call execute on our pool object passing it a Runnable object (which in this case is defined through an inner class). The run method does whatever work we need the thread to do. Whenever connections come in they will be allocates a thread from the pool. When the run method completes the thread will automatically be returned to the pool. If a connection comes in and all threads are in use the main loop will block until a thread is freed.
The Lock interface provides more extensive locking operations than using a synchronized block. Because we are using methods of a class to explicitly perform the lock and unlock operations the programmer needs to be more careful in its use. With a synchronized block of code it is impossible to forget to unlock it. Once the code execution leaves that block whether normally or through some for of exception, the lock is released. Using the Lock class the programmer must typically use a try-finally construct and put the unlock call within the finally clause to ensure that the lock is always released. One advantage of the Lock interface over synchronized is the ability to not block if a lock is not available. The tryLock method will always return immediately, returning true if the lock was aquired or false if not. This method may also be called with a timeout parameter so the thread will only block for the specified time if the lock is not aquired. ReentrantLock provides a concrete implementation of the Lock interface. The thread that holds the lock can call the lock method multiple times without blocking. This is especially useful in recursive code that needs to protect access to a certain section of code.
ReentrantLock provides a concrete implementation of the Lock interface. The thread that holds the lock can call the lock method multiple times without blocking. This is especially useful in recursive code that needs to protect access to a certain section of code.
The ReadWriteLock permits multiple threads to have read access to a protected piece of code, but only one thread may access the code in write mode. Effectively the ReadWriteLock consists of two locks that are implemented as inner classes. If a thread aquires the read lock other threads may also aquire the read lock. If a read lock is held no thread may aquire the write lock until all read locks have been released. If a thread holds the write lock, no thread may aquire either the write lock or a read lock. ReadWriteLock is an interface. RentrantReadWriteLock is a concrete implementation of this interface.
The BlockingQueue interface is a Queue that additionally supports operations that wait for the queue to become non-empty when retrieving an element, and wait for space to become available in the queue when storing an element. A BlockingQueue does not accept null elements. ArrayBlockingQueue is a concrete implementation of the BlockingQueue interface. An ArrayBlockingQueue is a bounded blocking queue backed by an array. This queue orders elements FIFO (first-in-first-out). The head of the queue is that element that has been on the queue the longest time. The tail of the queue is that element that has been on the queue the shortest time. New elements are inserted at the tail of the queue, and the queue retrieval operations obtain elements at the head of the queue. The Blocking queue provides methods to insert and remove objects from the queue (it is generic so can be typed). put() adds the specified element to the tail of this queue, waiting if necessary for space to become available. offer() inserts the specified element at the tail of this queue if possible, returning immediately if this queue is full. peek() retrieves, but does not remove, the head of this queue, returning null if this queue is empty. take() retrieves and removes the head of this queue, waiting if no elements are present on this queue. poll() retrieves and removes the head of this queue, null if this queue is empty. poll can also be specified with a time out so that the call will wait if necessary up to the specified wait time if no elements are present on this queue.
Here is an example of the use of a BlockingQueue. The class implements a logger that will be used by a number of threads to record information. The constructor takes a BlockingQueue (with type argument String). In the run method messages are retrieved from the queue using the take method. When the queue is empty the logging thread will block until messages become available. Once a message is retrieved it can be logged in whichever way is required.
Having defined our logging thread here is a class that uses the logger. A new ArrayBlockingQueue is instantiated with a type argument of String and a size of 10 elements. This is passed to the logger constructor as required. We can now start a number of threads that use this logger to record messages. We use the put method on the messageQueue. If the queue is full the thread will block until the logger has removed messages. The BlockingQueue will handle contention in a thread safe way should multiple threads be waiting for space to become available in the queue.