Concurrency: Best Practices
Upcoming SlideShare
Loading in...5

Concurrency: Best Practices



Introduction: This session discusses simple guidelines that can help develop reliable and high performing parallelism friendly applications in Java. It introduces some of the best practices that can ...

Introduction: This session discusses simple guidelines that can help develop reliable and high performing parallelism friendly applications in Java. It introduces some of the best practices that can be adopted in Concurrent programming in Java. The session also briefly explains various techniques used by the Java Virtual Machine to optimize synchronization.

Background: Over the years, there has been significant amount of work to make Java support concurrency with less overhead. With the advent of multi-cores, Parallelism is very essential to increase the Application throughput. Parallelism introduces atomicity and visibility issues. From Java 5 onwards, significant improvements like java.util.concurrency, Latches, Barriers are introduced to support Concurrency.

Considerable improvements have also been done at the Virtual Machine level to optimize synchronizations.

Session Agenda: The Session focuses on the “What?Why?How? of Concurrency” in java. It briefly describes the synchronizing features available in Java. A common set of pitfalls faced in Concurrent programming and methods to over come these pitfalls are also introduced. Usage of concurrent collections, Latches and Barriers is demonstrated. Much attention has been given to optimize lock management and synchronization in Java virtual machine. Features like biased locking, lock coarsening, lock elision by escape analysis and adaptive spin locking aim at this optimization. The Session explains each of these features.

Summary: The session describes some of the best practices in developing bug-free concurrent applications. Common pitfalls encountered in concurrent design and methods to avoid such pitfalls are also described.



Total Views
Views on SlideShare
Embed Views



6 Embeds 36 14 6 6
http://localhost 5 4 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Concurrency: Best Practices Concurrency: Best Practices Presentation Transcript

  • Concurrency: Best Practices Pramod B Nagaraja IBM India Pvt LTD 1
  • Agenda  Why Concurrency?  Concurrency Panoramas  Synchronization  When and What to synchronize  Guidelines for designing Concurrent Applications  Excessive Synchronization  Synchronization Optimization  Latches & Barriers 2
  • 1.0 Why Concurrency Story so far….  Most of the applications ran on system with few processors  Relied on faster hardware, rather than Software Concurrency/Parallelism, for better performance 3
  • 1.0 Why Concurrency …Current scenario  Moore's Law predicts that the number of transistors on a chip doubles every two years  Faster Dual core machines demand Concurrency  Multithreading is the pulse of Java 4
  • 2.O Concurrency Panoramas • Atomicity – Certain pieces of an application must all be executed as one unit 5
  • 2.O Concurrency Panoramas  Atomicity synchronized int getBalance() { return balance; } synchronized void setBalance(int x) { balance = x;} void deposit(int x) { void withdraw(int x) { int b = getBalance(); int b = getBalance(); setBalance(b + x);} setBalance(b - x);}} 6
  • 2.O Concurrency Panoramas  Visibility − Changes that you make to a value to be visible precisely when you intend them to be 7
  • 2.O Concurrency Panoramas  Visibility class LoopMayNeverEnd { boolean done = false; void work() { void stopWork() { while (!done) { done = true; } } // do work } } 8
  • 3.0 Synchronization Things which matter MOST should never be at mercy of things which matter LEAST 9
  • 3.1 When to Synchronize Pitfalls when synchronizing:  Forgetting to synchronize a resource that should be synchronized  Synchronizing the wrong resource  Synchronizing too often 10
  • 3.2 What to Synchronize  Not just the resource, but also the Transaction involving the resource  Pay attention to Data integrity at multiple levels of granularity 11
  • 3.2 What to Synchronize private int foo; public synchronized int getFoo() { return foo; } public synchronized void setFoo(int f) { foo = f; } setFoo(getFoo() + 1); //not thread safe 12
  • 4. Guidelines for designing Concurrent Applications  4 common concurrency mechanisms generally used in combination with each other to safely access data from multiple threads − Dynamic Exclusion Through Implicit Locks − Structural Exclusion Through Confinement − Immutability − Cooperation 13
  • 4.1 Dynamic Exclusion Through Implicit Locks Lock associated with an object is acquired when a method is declared synchronized. public synchronized void setName(String name);  Limitation − When synchronization is used inappropriately or excessively it causes poor performance and deadlock. 14
  • 4.1 Dynamic Exclusion Through Implicit Locks  Best Practice Tip  Do not perform CPU intensive and I/O operations inside synchronized method.  When possible synchronize on block of code instead of synchronizing entire method. Ex: synchronize(lock) { //critical section guarded by lock} 15
  • 4.2 Structural Exclusion Through Confinement  Thread confinement : Access object from a single thread using thread-per-session approach  Instance confinement : Use encapsulation techniques to restrict access to object state from multiple threads  Method confinement : Do not allow an object to escape from method by referencing it through local variables 16
  • 4.2 Structural Exclusion Through Confinement  Limitations : − Confinement cannot be relied on unless a design is leak proof  Best Practice Tip :  Combine confinement with appropriate locking discipline  Use ThreadLocal variables to maintain Thread Confinement 17
  • 4.3 Immutability  Immutable objects do not need additional synchronization afe { Public final class ImmutableClass ea d-s private final intThr = 100; field1 ly ent String field2=“FIN”; private final In her ……….. } 18
  • 4.3 Immutability  Limitation − In a software application only some classes can be immutable.  Best Practice Tip − Even when class is not fully immutable, declare its non changeable fields as final to limit its mutability. 19
  • 4.4 Cooperation What is purpose of wait-and-notify mechanism? When one thread needs a certain condition to exist and another thread can create that condition then we use wait and notify methods. Thread 1 Thread 2 CONDITION MET STOP!! CONDITION NOT MET Thread 1 can proceed cannot progress Thread 1 Thread 2 - “I will meet your condition.” 20
  • 4.4 Cooperation Limitation − When there are multiple waiting threads, you cannot be certain which thread is woken up. − Due to race conditions there could be missed or early notifications. Best Practice Tip  Safe to wake up all the threads using notifyAll() method instead of waking an arbitrary thread using notify()  Sometimes condition that caused thread to wait is not achieved when wait() returns, therefore put wait() call in a while loop.  Wait() and notify() must always be called inside synchronized code. 21
  • 5. Excessive Synchronization  Poor performance  Deadlock  Can occur when multiple threads each acquire multiple locks in different orders 22
  • 5.1 Deadlock public static Object cacheLock = new Object(); public static Object tableLock = new Object(); ... public void oneMethod() { public void anotherMethod() { synchronized (cacheLock) { synchronized (tableLock) { synchronized (cacheLock) { synchronized (tableLock) { doSomethingElse(); doSomething(); } } } }}} Need not be this obvious !!!! 23
  • 5.1 Deadlock public void transferMoney(Account fromAccn, Account toAccn, Amount amnt) { synchronized (fromAccn) { synchronized (toAccn) { if (fromAccn.hasSufficientBalance(amnt) { fromAccn.debit(amnt);;}}} Thread A : transferMoney(accountOne, accountTwo, amount); Thread B : transferMoney(accountTwo, accountOne, amount); 24
  • 5.1 Deadlock How to avoid Deadlock  Avoid acquiring more than one lock at a time  Allow a thread to voluntarily give up its resources if a second level or successive lock acquisition fails, this is called Two Phase Locking  Never call a synchronized method of another class from a synchronized method  Follow a fixed order while acquiring and releasing locks  Induce Lock ordering, if required  Object.identityHashCode() method 25
  • 5.1 Deadlock Banking example revisited public void transferMoney(Account fromAccn, Account toAccn,Amount amnt) { Account firstLck, secondLck; if (fromAccn.accountNumber() < toAccn.accountNumber()) { firstLck = fromAccn; secondLck = toAccn; } else { firstLck = toAccn; secondLck = fromAccn; } 26
  • 5.1 Deadlock synchronized (firstLck) { synchronized (secondLck) { if (fromAccn.hasSufficientBalance(amnt){ fromAccn.debit(amnt);; } } } } 27
  • 6. Synchronization Optimization JVM optimizes synchronization [under the hood]:  Lock Elision  Biased Locking  Lock Coarsening  Thread Spinning vs Thread Suspending 28
  • 6.1 Synchronization Optimization  Lock Elision :: Locks on local scope references can be elided public String concatBuffer(String s1,String s2,String s3) { StringBuffer sb = new StringBuffer(); sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString(); } 29
  • 6.2 Synchronization Optimization • Biased Locking :: Most locks are never accessed by more than one thread during their life time  Release the lease only if another thread attempts to acquire the same lock  Default in Java 6 Hotspot/JIT 30
  • 6.3 Synchronization Optimization  Lock coarsening :: Adjacent synchronized blocks may be merged into one synchronized block public static String concatToBuffer(StringBuffer sb, String s1, String s2, String s3) { sb.append(s1); sb.append(s2); sb.append(s3); return sb.toString();} 31
  • 6.4 Synchronization Optimization  Thread Suspending vs Thread Spinning  In 1.4.2, spin for (default value of) 10 iterations before being suspended  Adaptive Spinning  Introduced in 1.6  Spin duration based on the previous spin attempts and state of the lock owner 32
  • 7.1 Latches  Latches allows one or more threads to wait until a set of operations being performed in other threads completes.  When N concurrent sub-tasks occur, the coordinating thread will wait until each sub- task is executed 33
  • 7.1 Latches class TestLatch { final CountDownLatch latch = new CountDownLatch(3); class myThread extends Thread { public void run() {; latch.countDown()}} public static void main (String[] args){ TestLatch tst = new TestLatch(); myThread().start(); myThread().start(); myThread().start(); latch.await();//Thread execution completed}} 34
  • 7.2 Barriers  Barrier allows a set of threads to wait for each other at a common barrier point.  When Barrier point occurs all the threads waiting on it are released and run() method of Barrier object is called. class TestBarrier { final static int no_of_engines = 4; Runnable task = new Runnable() { public void run() { flyplane() }} 35
  • 7.2 Barriers final CyclicBarrier barrier = new CyclicBarrier(no_of_engines,task); class Worker implements Runnable { public void run() { startEngine(); barrier.await();} } public static void main(String[] args) { TestBarrier flight = new TestBarrier (); for (int i = 0; i < no_of_engines; ++i) new Thread( Worker(i)).start(); }} 36
  • References  ks/education/j-concur/index.html  optimizations-p1  concurrency-past-present 37
  • Q&A 38
  • Thank You !!!! 39