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.

1. Concurrency: Best Practices
Pramod B Nagaraja
IBM India Pvt LTD 1

2. Agenda

Why Concurrency?

Concurrency Panoramas

Synchronization
 When and What to synchronize

Guidelines for designing Concurrent Applications

Excessive Synchronization

Synchronization Optimization

Latches & Barriers
2

3. 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

4. 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

5. 2.O Concurrency Panoramas
• Atomicity
– Certain pieces of an application must all be
executed as one unit
5

6. 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

7. 2.O Concurrency Panoramas

Visibility
− Changes that you make to a value to be
visible precisely when you intend them to be
7

8. 2.O Concurrency Panoramas

Visibility
class LoopMayNeverEnd {
boolean done = false;
void work() { void stopWork() {
while (!done) { done = true; }
}
// do work
}
}
8

9. 3.0 Synchronization
Things which matter MOST should never be at
mercy of things which matter LEAST
9

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 5. Excessive Synchronization

Poor performance

Deadlock
 Can occur when multiple threads each acquire
multiple locks in different orders
22

23. 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

24. 5.1 Deadlock
public void transferMoney(Account fromAccn,
Account toAccn, Amount amnt) {
synchronized (fromAccn) {
synchronized (toAccn) {
if (fromAccn.hasSufficientBalance(amnt) {
fromAccn.debit(amnt);
toAccn.credit(amnt);}}}
Thread A : transferMoney(accountOne, accountTwo, amount);
Thread B : transferMoney(accountTwo, accountOne, amount);
24

25. 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

26. 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

27. 5.1 Deadlock
synchronized (firstLck) {
synchronized (secondLck) {
if (fromAccn.hasSufficientBalance(amnt){
fromAccn.debit(amnt);
toAccn.credit(amnt); }
} } }
27

28. 6. Synchronization Optimization
JVM optimizes synchronization [under the
hood]:
 Lock Elision
 Biased Locking
 Lock Coarsening
 Thread Spinning vs Thread Suspending
28

29. 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

30. 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

31. 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

32. 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

33. 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

34. 7.1 Latches
class TestLatch {
final CountDownLatch latch = new CountDownLatch(3);
class myThread extends Thread {
public void run() { task.run();
latch.countDown()}}
public static void main (String[] args){
TestLatch tst = new TestLatch();
tst.new myThread().start();
tst.new myThread().start();
tst.new myThread().start();
latch.await();//Thread execution completed}}
34

35. 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

36. 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(flight.new Worker(i)).start(); }}
36

37. References

https://www6.software.ibm.com/developerwor
ks/education/j-concur/index.html

http://www.infoq.com/articles/java-threading-
optimizations-p1

http://www.infoq.com/presentations/goetz-
concurrency-past-present
37

38. Q&A
38

39. Thank You !!!!
39