Java Concurrency, Memory Model, and Trends

11,554 views

Published on

Overview of Java Concurrency Utilities from Goetz and Bloch books

Published in: Technology
0 Comments
61 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,554
On SlideShare
0
From Embeds
0
Number of Embeds
146
Actions
Shares
0
Downloads
1,070
Comments
0
Likes
61
Embeds 0
No embeds

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 to 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.
  • If a new Thread is started in an application there is currently no way to return a result from that thread to the thread that started it without the use of a shared variable and appropriate synchronization. This is complex and makes code harder to understand and maintain.
    The Callable interface allows a result to be returned easily to a parent thread or an exception to be sent to indicate some problem.
    To use a Callable you define a class that implements the Callable interface, in the same way that you would define a class that implements Runnable for a new thread. The Callable interface defines one method, call. The return type of the call method is defined by the type argument of the Callable interface specified for the class definition, i.e. Callable is a generic interface. We will see how this works in reality in the next example. The call method contains whatever instructions are required to generate the result that will be returned.
    The Callable is passed to an ExecutorService through the submit method, rather than using the execute method of the Executor interface. The submit method will return a Future object immediately.
    The parent thread can continue concurrently with the Callable. When the parent thread requires the result of the Callable it calls the get method of the Future object. If the Callable has completed the result will be returned immediatley. If the Callable has not completed its work, the parent thread will block until the result is available.
    The submit method may also be called with a Runnable rather than a Callable. In this case get will always return null (but may block until the Runnable has completed its work). There is another form of the submit method that takes a Runnable as an argument and also takes a result as an argument. When the Runnable completes the result will be returned from the Future via the get method. This is useful if the Future is to be passed to another method.
  • This shows a simple example of a Callable object.
    Since Callable is generic we specify the type argument of Callable here as a String, so that the return type of the call method is also String.
    The call method will do some work to generate a result and then return the appropriate String.
  • Here we see an example of the use of the CallableExample with a Future.
    Firstly we create a new ExecutorService using a factory method from the Executors class.
    Next we submit a new CallableExample to the ExecutorService. This returns a Future which we must specify the type argument of. Obviously this must be the same type as the type argument of the Callable (which is String). If we did not we would get a compiler error.
    After we do some work in this thread we need to access the result of the CallableExample thread. To do this we simply call f.get. If the call method has got to the return statement we will immediately get the result. If not this thread will block until the call method of the CallableExample object calls return. We handle exceptions as appropriate. An ExecutionException is thrown if the call method threw an exception rather than returning a result. The cause of the exception can be determined via the Throwable.getCause() method.
  • 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.
  • Here we see an example of the use of a semaphore.
    We want to control access to a fixed size pool of resources so that multiple threads can request the use of a resource and return it when they have finished with it. Since there will be multiple threads involved we need to ensure thread safety. The semaphore can do this for us in a simple way.
    In the creator we create a new semaphore with the same size as the pool of resources we're creating.
    When a thread requests a resource we call the aquire method of the semaphore to see if we can aquire a permit to use a resource. If there are resources available this will return and a resource will be returned from the pool. If all the resources are in use the call to aquire will block until another thread calls release on the semaphore.
    When a thread finishes with a resource the resource is returned to the pool and the release method is called. Both aquire and release can be considered atomic operations.
    NOTE: This is not a complete code sample, it only demonstrates the use of the semaphore. How the next resource is allocated and resources are returned to the pool would also need to be made thread safe using additional code.
  • 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.
  • Welcome to “AJAX Basics” presentation. My name is Sang Shin. I am Java technology architect and evangelist from Sun Microsystems.
  • The java.util.concurrent.atomic package provides a small toolkit of classes that support lock-free thread-safe programming of single variables. In essence, the classes in this package extend the notion of volatile values, fields, and array elements to those that also provide an atomic conditional update operation of the form:
    boolean compareAndSet(expectedValue, updateValue);
    This method (which varies in argument types across different classes) atomically sets a variable to the updateValue if it currently holds the expectedValue, reporting true on success. The classes in this package also contain methods to get and unconditionally set values, as well as a weaker conditional atomic update operation weakCompareAndSet. The weak version may be more efficient in the normal case, but differs in that any given invocation of weakCompareAndSet method may fail, even spuriously (that is, for no apparent reason). A false return means only that the operation may be retried if desired, relying on the guarantee that repeated invocation when the variable holds expectedValue and no other thread is also attempting to set the variable will eventually succeed.
    The specifications of these methods enable implementations to employ efficient machine-level atomic instructions that are available on contemporary processors. However on some platforms, support may entail some form of internal locking. Thus the methods are not strictly guaranteed to be non-blocking -- a thread may block transiently before performing the operation.
    Here we see a simple example of the use of an AtomicInteger object for a bank balance.
  • The java.util.concurrent.atomic package provides a small toolkit of classes that support lock-free thread-safe programming of single variables. In essence, the classes in this package extend the notion of volatile values, fields, and array elements to those that also provide an atomic conditional update operation of the form:
    boolean compareAndSet(expectedValue, updateValue);
    This method (which varies in argument types across different classes) atomically sets a variable to the updateValue if it currently holds the expectedValue, reporting true on success. The classes in this package also contain methods to get and unconditionally set values, as well as a weaker conditional atomic update operation weakCompareAndSet. The weak version may be more efficient in the normal case, but differs in that any given invocation of weakCompareAndSet method may fail, even spuriously (that is, for no apparent reason). A false return means only that the operation may be retried if desired, relying on the guarantee that repeated invocation when the variable holds expectedValue and no other thread is also attempting to set the variable will eventually succeed.
    The specifications of these methods enable implementations to employ efficient machine-level atomic instructions that are available on contemporary processors. However on some platforms, support may entail some form of internal locking. Thus the methods are not strictly guaranteed to be non-blocking -- a thread may block transiently before performing the operation.
    Here we see a simple example of the use of an AtomicInteger object for a bank balance.
  • The java.util.concurrent.atomic package provides a small toolkit of classes that support lock-free thread-safe programming of single variables. In essence, the classes in this package extend the notion of volatile values, fields, and array elements to those that also provide an atomic conditional update operation of the form:
    boolean compareAndSet(expectedValue, updateValue);
    This method (which varies in argument types across different classes) atomically sets a variable to the updateValue if it currently holds the expectedValue, reporting true on success. The classes in this package also contain methods to get and unconditionally set values, as well as a weaker conditional atomic update operation weakCompareAndSet. The weak version may be more efficient in the normal case, but differs in that any given invocation of weakCompareAndSet method may fail, even spuriously (that is, for no apparent reason). A false return means only that the operation may be retried if desired, relying on the guarantee that repeated invocation when the variable holds expectedValue and no other thread is also attempting to set the variable will eventually succeed.
    The specifications of these methods enable implementations to employ efficient machine-level atomic instructions that are available on contemporary processors. However on some platforms, support may entail some form of internal locking. Thus the methods are not strictly guaranteed to be non-blocking -- a thread may block transiently before performing the operation.
    Here we see a simple example of the use of an AtomicInteger object for a bank balance.
  • 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.
  • 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.
  • 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.
  • 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.
  • you can use multiple storage engines in a single application; you are not limited to using only one storage engine in a particular database. So, you can easily mix and match storage engines for the given application need. This is often the best way to achieve optimal performance for truly demanding applications: use the right storage engine for the right job.
    You can use multiple storage engines in a single application. This is particularly useful in a replication setup where a master copy of a database on one server is used to supply copies, called slaves, to other servers. A storage engine for a table in a slave can be different than a storage engine for a table in the master. In this way, you can take advantage of each engine's abilities.
    For instance, assume a master with two slaves environment. We can have InnoDB tables on the master, for referential integrity and transactional safety. One slave can also be set up with innoDB or the ARCHIVE engine in order to do backups in a consistent state. Another can be set up with MyISAM and MEMORY tables in order to take advantage of FULLTEXT (MyISAM) or HASH-based indexing (MEMORY).
  • Java Concurrency, Memory Model, and Trends

    1. 1. JavaJava ConcurrencyConcurrency ● Carol McDonaldCarol McDonald –AvailityAvaility
    2. 2. . 4 Why Concurrency: • Benefits of threads: > Multitasking, Exploit multiple cores or CPUs > Multi-threading good for blocking for I/O or other blocking ops • Java < 1.5 concurrency primitives: > wait(), notify(), sleep(), interrupt(), synchronized > Easy to use incorrectly > Incorrect use can produce poor performance
    3. 3. . 5 Risks of Threads • Safety hazards > Syncronization, contention • Liveness hazards > Race conditions, deadlock • Performance hazards > Context switching overhead
    4. 4. . 6 Concurrency Utilities Goals • set of concurrency building blocks > library for concurrency like Collections for data structures • Enhance scalability, performance, and thread safety • Java Memory Model for Multi tasking
    5. 5. . 7 Do you see the error? 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 }
    6. 6. . 9 What Does It Print? (a) PingPong (b) PongPing (c) It varies Not a multithreaded program!
    7. 7. . 10 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(); } }
    8. 8. . 11 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 }
    9. 9. . 12 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 }
    10. 10. . 14 Concurrency Utilities: • Task Scheduling Framework: Executor interface replaces direct use of Thread • Callable and Future • Synchronisers > Semaphore, CyclicBarrier, CountDownLatch • Concurrent collections • Lock • Atomic, Visible
    11. 11. . 15 Concurrency Utilities: • Task Scheduling Framework: Executor • Separate task submission from execution policy • No more direct Thread invocation > Use myExecutor.execute(aRunnable); > Not new Thread(aRunnable).start(); public interface Executor { void execute (Runnable command); }
    12. 12. . 16 Executor an object whose job it is to run Runnables: public interface Executor { void execute (Runnable command); } public interface ExecutorService extends Executor { .. } public class Executors { static ExecutorService newFixedThreadPool(int poolSize); ... } Executor pool = Executors.newFixedThreadPool(5); pool.execute (runnable); manages the lifecycle of the execution service static factory methods for Executor implementations
    13. 13. . 17 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 }
    14. 14. . 18 How not to manage tasks class UnreliableWebServer { public static void main(String[] args) { ServerSocket socket = new ServerSocket(80); while (true) { final Socket connection = socket.accept(); Runnable r = new Runnable() { public void run() { handleRequest(connection); } }; // Don't do this! new Thread(r).start(); } } } Could create too many threads !
    15. 15. . 19 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); } myExecutor.execute(aRunnable)
    16. 16. . 20 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 }
    17. 17. . 21 Callables and Futures •Callable interface provides way to get a result from a thread ●Implement call() method rather than run() •Callable is submitted to ExecutorService ●Call submit() not execute() ●submit() returns a Future object •Retrieve result using get() method of Future object ●If result is ready it is returned ●If not ready calling thread will block
    18. 18. . 22 Callable Example class CallableExample implements Callable<String> { public String call() { String result = null; /* Do some work and create a result */ return result; } }
    19. 19. . 23 Future Example ExecutorService es = Executors.newSingleThreadedExecutor(); Future<String> f = es.submit (new CallableExample()); /* Do some work in parallel */ try { String callableResult = f.get(); } catch (InterruptedException ie) { /* Handle */ } catch (ExecutionException ee) { /* Handle */ }
    20. 20. . 24 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
    21. 21. . 26 Recommendation • Hold Locks for as short a time as possible • Do not perform CPU intensive or I/O ops inside a synchronized method or while locking
    22. 22. . 27 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 tim
    23. 23. . 28 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 not possible • New Lock interface addresses these issues
    24. 24. . 29 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
    25. 25. . 31 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. 26. . 32 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. 27. . 33 ReadWriteLock Example ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); Lock r = rwl.readLock(); Lock w = 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. 28. . 34 Synchronizers • Co-ordinate access and control -can eliminate most uses of wait or notify • 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. 29. . 35 Semaphore Example private Semaphore available; private Resource[] resources; private boolean[] used; public Resource(int poolSize) { available = new Semaphore(poolSize); /* Initialise resource pool */ } public Resource getResource() { try { available.aquire() } catch (IE) {} } public void returnResource(Resource r) { /* Return resource to pool */ available.release(); }
    30. 30. . 36 Recommendation • Prefer Concurrency utilities to wait and notify
    31. 31. . 37 BlockingQueue Interface • thread safe Producer Consumer Pattern 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 }
    32. 32. . 39 Consumer Blocking Queue Example: Logger thread 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) { } }
    33. 33. . 40 Producer Blocking Queue Example: using the Logger thread private ArrayBlockingQueue messageQueue = new ArrayBlockingQueue<String>(10); Logger logger = new Logger(messageQueue); // runnables : public void run() { String someMessage; try { while (true) { /* Do some processing */ /* Blocks if no space available */ messageQueue.put(someMessage); } } catch (InterruptedException ie) { } }
    34. 34. . 41 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
    35. 35. . 42 Java SE 6: Concurrency Features •Deque interface for double ended queues >ArrayDeque, LinkedBlockingDeque, ConcurrentLinkedDeque •Concurrent skiplists >ConcurrentSkipListMap, ConcurrentSkipListSet •AbstractQueuedLongSynchronizer >Version of AbstractQueuedSynchronizer that uses a long for internal state information
    36. 36. Concurrency:Concurrency: Atomic VariablesAtomic Variables
    37. 37. . 44 Java Memory Model • key ideas: • all threads share the main memory • each thread uses a local working memory • refreshing local memory to/from main memory must comply to JMM rules
    38. 38. . 45 Java Memory Model • • Volatile writing to a volatile forces a flush to shared memory • a read of volatile variable always returns the most recent write by any thread
    39. 39. . 46 Atomics • java.util.concurrent.atomic > classes that support lock-free thread-safe programming on single variables > use efficient machine level atomic processor instructions > AtomicBoolean, AtomicInteger, AtomicLong, AtomicLongArray,AtomicReference, AtomicReferenceArray AtomicInteger balance = new AtomicInteger(0); public int deposit(integer amount) { return balance.addAndGet(amount); }
    40. 40. . 47 Prefer immutable objects/data •An immutable object is one whose > State cannot be changed after construction > All fields are private final , no setters •Immutable objects are automatically thread-safe! •Simpler •Safer > Can be freely shared •More scalable > No synchronization required
    41. 41. . 48 Multithreaded Lazy Initialization is tricky public class Singleton { private static Singleton instance; public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } private Singleton() {} } Shared mutable Non deterministic type bug can result
    42. 42. . 49 Eager Initialization public class Singleton { private static final Singleton instance= new Singleton(); public static Singleton getInstance() { return instance; } private Singleton() {} } immutable
    43. 43. . 50 Servlet Counter public class HelloWithHits extends HttpServlet { int hits; // Shared mutable variable (danger) protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { ++hits; // Risks atomicity + visibility failure ... } }
    44. 44. . 51 Servlet Counter public class HelloWithHits extends HttpServlet { final AtomicInteger hits = new AtomicInteger(); protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { hits.incrementAndGet(); ... } }
    45. 45. . 52 Audit Web • Find the shared variables > Search all servlet classes for instance fields > Search for all instances of getAttribute() on HttpSession or ServletContext > Search JSPs for session- or application-scoped beans • For each, determine if it is mutable > If so, can you replace it with an immutable object? • Identify variables that will change at the same time > Ensure that read/multiple write accesses are atomic > One way is to encapsulate in an immutable holder http://www.ibm.com/developerworks/library/j-jtp09238.html
    46. 46. . 53 Reduce locking • Do As little work as possible inside synchronized blocks • guard different state with different locks > reduces likelihood of lock contention > (but disciplined order or deadlock)
    47. 47. . 54 Reduce locking • reduce locking > replace mutable objects with immutable ones > replace shared objects with thread-local ones > java.util.concurrent.atomic, and > Concurrent collections in java.util.concurrent
    48. 48. . 55 VisualVM Monitoring threads
    49. 49. . 56 VisualVM
    50. 50. . 57 VisualVM
    51. 51. . 58 Trends trend towards concurrent, asynchronous computing
    52. 52. . 59 Actors • message passing concurrency • Share Nothing • Communicate through messages • Asynchronous non-blocking
    53. 53. 60 EBay: Async Everywhere Pattern: Event Queue > Primary application writes data and queues event > Consumers subscribe to event
    54. 54. 62 Ebay: Partition Everything Pattern: Functional Segmentation > Segment processing into pools, services, and stages > Segment data by entity and usage pattern
    55. 55. 63 LinkedIn Best Practices Storage and architecture > Keep the system stateless  eBay, Google, etc. > Partition data and services  Facebook, eBay > Cache data > Replicate your data
    56. 56. . 64 MySQL replication • Writes replicated to In memory memcache for fast reads master slave
    57. 57. Resources
    58. 58. . 68 More Info/References •Books > Java Concurrency in Practice (Goetz, et al) > See http://www.jcip.net > Concurrent Programming in Java (Lea) > Effective Java (Bloch) • Articles > http://www.ibm.com/developerworks/java/tutorials/j- concur/section4.html > http://blogs.sun.com/carolmcdonald/entry/some_concurr ency_tips
    59. 59. . 69 References • http://www.ibm.com/developerworks/library/j-jtp09238.html • http://www.angelikalanger.com/ • Best Practices for Large-Scale Web Sites -- Lessons from eBay http://java.sun.com/javaone/2009/articles/gen_ebay.jsp • Lessons from Linked In > http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS • http://www.ibm.com/developerworks/library/j-jtp03304/
    60. 60. . 70 For More Information • 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/corep latform/TS-3281.html • Memory-retention due to finalization article > http://www.devx.com/Java/Article/30192
    61. 61. . 71 For More Information • 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/ > VisualVM > http://download- llnw.oracle.com/javase/6/docs/technotes/guides/visualvm/threads.html > JConsole > http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
    62. 62. Thank You!Thank You! ● Carol McDonaldCarol McDonald –

    ×