Java Concurrency

  • 5,767 views
Uploaded on

 

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,767
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
418
Comments
2
Likes
17

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.

Transcript

  • 1. J2SE 5.0 Concurrency,
    • Carol McDonald
      • Java Technology Architect
        • Sun Microsystems, Inc.
  • 2. Speaker’s Qualifications
    • Carol cDonald:
      • Java Architect at Sun Microsystems
      • Before Sun, worked on software development of:
        • Application to manage car Loans for Toyota (>10 million loans)
        • Pharmaceutical Intranet ( Roche Switzerland)
        • Telecom Network Mgmt ( Digital France)
        • X.400 Email Server ( IBM Germany)
  • 3. Java Concurrency
  • 4. Motivation for Concurrency Utilities
    • Developing concurrent classes was too hard
    • Java has concurrency primitives:
      • wait() , notify() , sleep() , interrupt() , synchronized
      • These are too primitive, Too low level
      • Easy to use incorrectly
        • Incorrect use can produce poor performance
  • 5. Concurrency Utilities Goals
    • Provide a good set of concurrency building blocks
      • library for concurrency like Collections for data structures
    • Enhance scalability, performance, readability and thread safety of Java applications
    • Beat C performance in high-end server applications
  • 6. Puzzle: “Ping Pong”
    • 01 class PingPong {
    • 02 public static synchronized void main (String[] a) {
    • 03 Thread t = new Thread() {
    • 04 public void run() {
    • 05 pong();
    • 06 }
    • 07 };
    • 08
    • 09 t.run();
    • 10 System.out.print("Ping");
    • 11 }
    • 12
    • 13 static synchronized void pong() {
    • 14 System.out.print("Pong");
    • 15 }
    • 16 }
  • 7. What Does It Print?
    • (a) PingPong
    • (b) PongPing
    • (c) It varies
  • 8. What Does It Print?
    • (a) PingPong
    • (b) PongPing
    • (c) It varies
    • Not a multithreaded program!
  • 9. Example How to start a thread
    • public class HelloRunnable implements Runnable {
    • public void run() {
    • System.out.println("Hello from a thread!");
    • }
    • public static void main(String args[]) {
    • (new Thread (new HelloRunnable())) .start();
    • }
    • }
  • 10. Another Look
    • 01 class PingPong {
    • 02 public static synchronized void main(String[] a) {
    • 03 Thread t = new Thread() {
    • 04 public void run () {
    • 05 pong();
    • 06 }
    • 07 };
    • 08
    • 09 t. run (); // Common typo!
    • 10 System.out.print("Ping");
    • 11 }
    • 12
    • 13 static synchronized void pong() {
    • 14 System.out.print("Pong");
    • 15 }
    • 16 }
  • 11. How Do You Fix It?
    • 01 class PingPong {
    • 02 public static synchronized void main(String[] a) {
    • 03 Thread t = new Thread() {
    • 04 public void run() {
    • 05 pong();
    • 06 }
    • 07 };
    • 08
    • 09 t. start ();
    • 10 System.out.print("Ping");
    • 11 }
    • 12
    • 13 static synchronized void pong() {
    • 14 System.out.print("Pong");
    • 15 }
    • 16 }
  • 12. The Moral
    • Invoke Thread.start , not Thread.run
      • Common error
      • Can be very difficult to diagnose
  • 13. Concurrency Utilities: JSR-166
    • Task Scheduling Framework: Executor interface replaces direct use of Thread
    • Callable and Future
    • Synchronisers
      • Semaphore, CyclicBarrier, CountDownLatch
    • Concurrent collections : BlockingQueue
    • Lock
    • Atomic
  • 14. Concurrency Utilities: JSR-166
    • Task Scheduling Framework: Executor interface replaces direct use of Thread
    • No more direct Thread invocation
      • Use myExecutor.execute(aRunnable);
      • Not new Thread(aRunnable).start();
    public interface Executor { void execute (Runnable command); }
  • 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. Creating Executors
    • Factory methods in the Executors class
    public class Executors { static ExecutorService newSingleThreadedExecutor (); static ExecutorService newFixedThreadPool (int poolSize); static ExecutorService newCachedThreadPool (); static ScheduledExecutorService newScheduledThreadPool (); // Other methods not listed }
  • 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. ExecutorService for Lifecycle Support
    • ExecutorService supports graceful and immediate shutdown
    public interface ExecutorService extends Executor { void shutdown (); List<Runnable> shutdownNow (); boolean isShutdown (); boolean isTerminated (); boolean awaitTermination (long timeout, TimeUnit unit); // additional methods not listed }
  • 19. ScheduledExecutorService
    • Deferred and recurring tasks
      • Schedule execution of Callable or Runnable to run once after a fixed delay
        • schedule ()
      • Schedule a Runnable to run periodically at a fixed rate
        • scheduleAtFixedRate ()
      • Schedule a Runnable to run periodically with a fixed delay between executions
        • scheduleWithFixedDelay ()
    • Submission returns a ScheduledFuture
      • Can be used to cancel task
  • 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. Synchronize Critical Section
    • E.g., shared resource is an customer account. Certain methods called by multiple threads.
    • Hold monitor lock for as short a time as possible .
    synchronized double getBalance() { Account acct = verify(name, password); return acct.balance; } Lock held for long time double getBalance() { synchronized (this) { Account acct = verify(name, password); return acct.balance; } } Current object is locked Equivalent to above double getBalance() { Account acct = verify(name, password); synchronized (acct) { return acct.balance}; } Better Only acct object is locked – for shorter time
  • 22. Locks
    • Java provides basic locking via synchronized
    • Good for many situations, but some issues
      • Single monitor per object
      • Not possible to interrupt thread waiting for lock
      • Not possible to time-out when waiting for a lock
      • Block structured approach
        • Aquiring multiple locks is complex
        • Advanced techniques like hand-over-hand locking are not possible
    • New Lock interface addresses these issues
  • 23. Lock Interface
    • No automatic unlocking
    Interface Lock { void lock (); void lockInterruptibly () throws IE ; boolean tryLock (); boolean tryLock (long t, TimeUnit u) throws IE ; //returns true if lock is aquired void unlock (); Condition newCondition () throws UnsupportedOperationException; } IE = InterruptedException
  • 24. RentrantLock
    • Simplest concrete implementation of Lock
    • Same semantics as synchronized, but with more features
    • Generally better performance under contention than synchronized
    • Remember Lock is not automatically released
      • Must use a finally block to release
    • Multiple wait-sets supported
      • Using Condition interface
  • 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(); } }
  • 26. ReadWriteLock Interface
    • Has two locks controlling read and write access
      • Multiple threads can aquire the read lock if no threads have a write lock
      • Only one thread can aquire the write lock
      • Methods to access locks
      • rwl.readLock().lock();
      • rwl.writeLock().lock();
      • Better performance for read-mostly data access
  • 27. ReadWriteLock Example ReentrantReadWriteLock rwl = new ReentrantReadWriteLock (); Lock rLock = rwl.readLock (); Lock wLock = rwl.writeLock (); ArrayList<String> data = new ArrayList<String>(); public String getData(int pos) { r.lock () ; try { return data.get (pos); } finally { r.unlock (); } } public void addData(int pos, String value) { w.lock (); try { data.add (pos, value); } finally { w.unlock (); } }
  • 28. Synchronizers
    • Co-ordinate access and control
    • Semaphore
      • Manages a fixed sized pool of resources
    • CountDownLatch
      • One or more threads wait for a set of threads to complete an action
    • CyclicBarrier
      • Set of threads wait until they all reach a specified point
    • Exchanger
      • Two threads reach a fixed point and exchange data
  • 29. BlockingQueue Interface
    • Provides thread safe way for multiple threads to manipulate collection
    Interface BlockingQueue<E> { void put (E o) throws IE; boolean offer (E o) throws IE; boolean offer (E o, long t, TimeUnit u) throws IE; E take () throws IE; E poll () throws IE; E poll (long t, TimeUnit u) throws IE; int drainTo (Collection<? super E> c); int drainTo (Collection<? super E> c, int max); // Other methods not listed }
  • 30. BlockingQueue Implementations
    • ArrayBlockingQueue
      • Bounded queue, backed by an array, FIFO
    • LinkedBlockingQueue
      • Optionally bounded queue, backed by linked nodes, FIFO
    • PriorityBlockingQueue
      • Unbounded queue
      • Uses comparator or natural ordering to determine the order of the queue
  • 31. Blocking Queue Example: 1 private BlockingQueue<String> msgQueue ; public Logger ( BlockingQueue<String> mq) { msgQueue = mq; } public void run() { try { while (true) { String message = msgQueue.take (); /* Log message */ } } catch (InterruptedException ie) { } }
  • 32. Blocking Queue Example: 2 private ArrayBlockingQueue messageQueue = new ArrayBlockingQueue<String>(10); Logger logger = new Logger( messageQueue ); public void run() { String someMessage; try { while (true) { /* Do some processing */ /* Blocks if no space available */ messageQueue.put(someMessage) ; } } catch (InterruptedException ie) { } }
  • 33. Concurrent Collections
    • ConcurrentMap (interface)
      • Extends Map interface with atomic operations
    • ConcurrentHashMap
      • Fully concurrent retrieval
      • Tunable concurrency for updates
        • Constructor takes number of expected concurrent threads
    • ConcurrentLinkedQueue
      • Unbounded, thread safe queue, FIFO
    • CopyOnWriteArrayList
      • Optimised for frequent iteration, infrequent modifications
  • 34. Summary
    • New concurrency features are very powerful
    • Lots of great features
    • Take time to learn how to use them correctly
    • Use them!
  • 35. For More Information
  • 36. Resources and Summary
  • 37. For More Information (1/2)
    • Memory management white paper
      • http://java.sun.com/j2se/reference/whitepapers/
    • Destructors, Finalizers, and Synchronization
      • http://portal.acm.org/citation.cfm?id=604153
    • Finalization, Threads, and the Java Technology Memory Model
      • http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3281.html
    • Memory-retention due to finalization article
      • http://www.devx.com/Java/Article/30192
  • 38. For More Information (2/2)
    • FindBugs
      • http://findbugs.sourceforge.net
    • Heap analysis tools
      • Monitoring and Management in 6.0
        • http://java.sun.com/developer/technicalArticles/J2SE/monitoring/
      • Troubleshooting guide
        • http://java.sun.com/javase/6/webnotes/trouble/
      • JConsole
        • http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
  • 39. Resources
    • http://java.sun.com/javase
    • Java.net
    • http://jdk.dev.java.net
  • 40. Stay in Touch with Java SE
    • http://java.sun.com/javase
    • JDK Software Community
      • planetjdk.org
      • community.java.net/jdk
    • JDK 6
      • http://jdk6.dev.java.net/
      • http://jcp.org/en/jsr/detail?id=270
    • JDK 7
      • http://jdk7.dev.java.net/
      • http://jcp.org/en/jsr/detail?id=277
  • 41. Thank You!
    • Carol McDonald
      • Java Technology Architect
        • Sun Microsystems, Inc.