Effective java - concurrency

Effective Java - Concurrency

fli@telenav.cn

The scope of the topic

Multiply-Thread
Concurrency

Multiply-Core Parallel Distributed Multiply-Box
(Process/JVM)

The scope of the topic

Scala
….

Concurrency
Erlang
java
CSP

Multiply-Thread Programming in java

Outline

 Warm-up
 Counter
 What’s concurrency programming
 Shared Data/Coordination : safe(correctness)
 Performance : scalability
 After JDK5 concurrency
 Lock
 Synchronizers
 Executor/Concurrent Collections/ Atomic
 Why it’s hard
 Java Memory Model

Warm-up

 Counter
@NotThreadSafe
public class Counter {
private int count = 0; //shared data

public void increment() {
count++;
}

public int getCount() {
return count;
}
}
Thread A: Retrieve c =0 .
Thread B: Retrieve c = 0 .
Thread A: Increment retrieved value; result is 1.
Thread B: Increment retrieved value; result is 1.
Thread A: Store result in c; c is now 1.
Thread B: Store result in c; c is now 1.

Warm-up

 Counter
@NotThreadSafe

public synchronized void increment() {//write protected by lock
count++;
}

return count;
}
}

Warm-up

 Counter
@ThreadSafe

public synchronized void increment() {
count++;
}

public synchronized int getCount() {
return count;
}
}

get need to be synchronized for the class to be thread-safe,
to ensure that no updates are lost,and that all threads see
the most recent value of the counter. (Visibility)

Warm-up

 Counter
@ThreadSafe
private volatile int count = 0; //shared data

public synchronized void increment() {
count++;
}

return count;
}
}

uses volatile to guarantee the visibility of the current result
where locks(synchronzied)only allow one thread to access a value at once,
volatile reads allow more than one, you get a higher degree of sharing

What’s concurrency programming

 Why concurrency (purpose)
 Multitasking, Exploit multiple cores or CPUs
 Multi-threading good for blocking for I/O or other blocking ops
 Concurrency programming
 Shared Data between threads
 Coordination between threads
 Avoid performance even poor than non-concurrent program


 Shared Data
 Lock/Mutual
 Atomicity
 Visibility
 Safe Publication
 Coordination
 Wait/Notify
 Performance(scalable)
 Lock contention


• Atomicity
• Check-then-act

if (foo != null) // Another thread could set foo to null
foo.doSomething();

•synchronized
•ConcurrentHashMap.putIfAbsent lock

• Read-modify-write

++numRequests; // Really three separate actions even if volatile

•synchronized
•AtomicInteger.getAndSet cmpxchgl


• Visibility
Never-Stop Thread, windows JDK6: java –server StopThread
@NotThreadSafe
public class StopThread
{
private static boolean stopRequested;

public static void main(String[] args) throws InterruptedException
{
Thread backgroudThread = new Thread(new Runnable() {
public void run()
{
int i = 0;
while (!stopRequested)
i++;
}
});
backgroudThread.start();

TimeUnit.SECONDS.sleep(1);
stopRequested = true;
//Compiler Optimization
if (!stopRequested)
} while(true)
} i++;


• Visibility

@ThreadSafe
public class StopThread
{
private static volatile boolean stopRequested;

public static void main(String[] args) throws InterruptedException
{
Thread backgroundThread = new Thread(new Runnable() {
public void run()
{
int i = 0;
while (!stopRequested)
i++;
}
});
backgroundThread.start();

TimeUnit.SECONDS.sleep(1);
stopRequested = true;

}
}
What’s volatile ?

• Visibility : volatile

JLS 8.3.1.4 volatile Fields
A field may be declared volatile, in which case the Java memory model (§17)
ensures that all threads see a consistent value for the variable.

JLS 17.4.4 Synchronization Order
A write to a volatile variable (§8.3.1.4) v synchronizes-with all subsequent
reads of v by any thread (where subsequent is defined according to the
synchronization order).

JLS 17.4.5 Happens-before Order
If one action happens-before another, then the first is visible to and
ordered before the second.

If an action x synchronizes-with a following action y, then we also have
hb(x, y).

Under Hook: Memory Barrier


 Safe Publication : final

class FinalFieldExample {
final int x;
int y;
static FinalFieldExample f;
public FinalFieldExample(){ Re-order
x = 3; it's quite natural to store a pointer to a
y = 4;
} block of memory, and then advance the
pointer as you're writing data to that block
static void writer() {
f = new FinalFieldExample();
}

static void reader() {
if (f != null) {
int i = f.x; // guaranteed to see 3
int j = f.y; // could see 0
}
}

...
}



final int x; Allocate Memory Allocate Memory
int y;
public FinalFieldExample(){ Filed initiation Filed initiation
x = 3;
y = 4;
} Execute Constructor Assign variable
f = new FinalFieldExample(); Assign variable Execute Constructor
}

if (f != null) {
}
} Single-Thread, re-order does not matter
... 1) Thread1.writer() //the java statement is finished
} 2) Thread1.reader()
If Multiply-Thread, re-order may be the evil
1) Thread1.writer() Thread2.reader()



final int x; What’s final ?
int y;
public FinalFieldExample(){
x = 3;
y = 4;
}

f = new FinalFieldExample();
}

if (f != null) {
}
}

...
}

• Safe Publication : final

JLS 8.3.1.2 final Fields
A blank final instance variable must be definitely assigned (§16.9) at the end
of every constructor (§8.8) of the class in which it is declared;
otherwise a compile-time error occurs.

17.5.1 Semantics of Final Fields
The semantics for final fields are as follows. Let o be an object, and c be
a constructor for o in which f is written. A freeze action on a final field f of o
takes place when c exits, either normally or abruptly.
JLS 17.5.3 Subsequent Modification of Final Fields
An implementation may provide a way to execute a block of code in a
final field safe context. If an object is constructed within a final field
safe context, the reads of a final field of that object will not be reordered
with modifications of that final field that occur within that final field safe
context.


 Safe Publication : Double-Checked Locking

// Broken multithreaded version "Double-Checked Locking" idiom
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
synchronized(this) {
if (helper == null)
helper = new Helper();
}
return helper;
}
// other functions and members...
}



@ThreadSafe
class Foo {
private volatile Helper helper = null;
if (helper == null)
if (helper == null)
helper = new Helper();
}
return helper;
}
}



@ThreadSafe // use class initialization
class HelperSingleton {
static Helper singleton = new Helper();
}

@ThreadSafe // Lazy load
class Foo {
private static class HelperHolder {
public static Helper helper = new Helper();
}

public static Helper getHelper() {
return HelperHolder.helper;
}
}



@ThreadSafe
class Foo {
private volatile Helper helper = null;
Helper result = helper; //local variable, for better performance
if (result == null) {
result = helper;
if (result == null) {
helper = result = new Helper();
}
}
}
return result;
}

}

Variant of DDL, each has it’s own standard point


 Safe Publication

public class Cache {
private final Thread cleanerThread;
public Cache() {
cleanerThread = new Thread(new Cleaner(this)); // this escapes again!
cleanerThread.start();
// ….
}

// Clean will call back to this method
public void cleanup() { // clean up Cache }
}

//Careful progmramming //FactoryMethod Pattern
@ThreadSafe @ThreadSafe
public Cache() { public class Cache {
cleanerThread = new Thread(new Cleaner(this); // ...
public static Cache newCache() {
// …. Cache cache = new Cache();
cache.startCleanerThread();
cleanerThread.start(); //last statement return cache;
} }
} }

More safely published method (see book JCIP)


 Cooperation: Object.wait and notify

//Standard Idiom for using the wait method
final Object obj = new Object(); // Do not change your lock object refrence

//Thread 1
synchronized(obj) { // You must synchronize.
while(! someCondition()) // Always wait in a loop.
{
obj.wait(); //Release lock, and reacquires on wakeup
}
}
// Thread 2
synchronized(obj) { // Synchronize here too!
satisfyCondition();
obj.notifyAll();
}


• Performance
• Lock contention
– Multiply-Thread acquires and wait for 1 lock
– Starvation
• DeadLock /LiveLock
– DeadLock : both are waiting the other to release resources
– LiveLock : both are run-able and no one make progress
• Spin Lock
– Check and Sleep, wasting cpu cycle
 Reduce Lock contention
• Use local variables or thread-local storage (Careful  memory leak)
• Get rid of expensive calculations while in locks
• Lock striping (ConcurrentHashMap)
• atomic operations/
• Reader-Writer Locks
• Avoid Object-pooling (Object-creation is expensive)
• Avoid hotspots

JDK5 Concurrency

 Lock
Java provides basic locking via synchronized
Good for many situations, but some issues
 Single monitor per object (single wait/notify condition)
 Not possible to interrupt thread waiting for lock
 Not possible to time-out when waiting for a lock
 Block structured approach
• Acquiring multiple locks is complex
• Advanced techniques not possible
synchronized Lock
Acquire_Lock_1 Acquire_Lock_1
Acquire_Lock_2 Acquire_Lock_2
Release_Lock_2 Release_Lock_1
Release_Lock_1 Release_Lock_2

 New Lock interface addresses these issues

JDK5 Concurrency

 Lock

void lock()
Acquires the lock.
void
lockInterruptibly()
Acquires the lock unless the current thread is interrupted.

Condition
newCondition()
Returns a new Condition instance that is bound to this Lock instance.

boolean
tryLock()
Acquires the lock only if it is free at the time of invocation.

boolean
tryLock(long time, TimeUnit unit)
Acquires the lock if it is free within the given waiting time and the
current thread has not been interrupted.

void unlock()
Releases the lock.

JDK5 Concurrency

 ReentrantLock
 Rentrant means lock holder reacquire the lock: e.g recur method

Lock l = new ReentrantLock();
l.lock();
try {
// access the resource protected by this lock
}
finally {
l.unlock();
}

 ReentrantReadWriteLock
 Lock downgrading. Upgrading is not allowed
• Release read lock first , acquire write lock
• Writer starvation ?

JDK5 Concurrency

 Condition (Object.wait and notify in explicit lock)
private final Lock lock = new ReentrantLock();
private final Condition condition = lock.newCondition();

public void waitTillChange() {
lock.lock();
try {
while(! someCondition()) condition.await();
} finally {
lock.unlock();
}
}
public void change() {
lock.lock();
try {
satisfyCondition();
condition.signalAll();
} finally {
lock.unlock();
}
}

JDK5 Concurrency

• Synchronizers (Higher-level concurrency utilities to Object.wait and notify)
• Semaphore
• CountDownLatch
– Spawn sub-worker and wait for sub-worker
E.g getAds, spawn 3 worker to get ads from different vendor
getAdsFromCitySearch
getAdsFromGoogle
getAdsFromTeleNav
• CyclicBarrier
• Exchanger
• Phaser (1.7)
• ForkJoinPool (1.7)

JDK5 Concurrency

• Executor/Concurrent Collections/ Atomic

• BlockingQueue (producer-consumer queues)

Throws
Special value Blocks Times out
exception
offer(e, time,
Insert add(e) offer(e) put(e)
unit)
poll(time,
Remove remove() poll() take()
unit)
Examine element() peek() not applicable not applicable

A lot of things are not covered today, worth to explore and use …

Why it’s hard

 The “evil”
 Cache Coherency
• Processor /Memory
– A CPU does not always fetch memory values from RAM
• Processor/Processor

 Reordering
• Processor : rearrange the execution order of machine instructions
• Compiler Optimizations : rearrange the order of the statement
• Memory : rearrange the order in which writes are committed to memory cells

Why it’s hard

 Ordering

within-thread
From the point of view of the thread performing the actions in a
method, instructions proceed in the normal as-if-serial manner that
applies in sequential programming languages.

between-thread
From the point of view of other threads that might be "spying" on
this thread by concurrently running unsynchronized methods,
almost anything can happen. The only useful constraint is that the
relative orderings of synchronized methods and blocks, as well as
operations on volatile fields, are always preserved

Why it’s hard

 Java Memory Model
 address three intertwined issues
• Atomicity
• Visibility
• Ordering
 Notation
• Program orders (Intra-Thread)
• Synchronize-with
• Happen-Before (HB)
– synchronized
– volatile
– final

References

 http://www.slideshare.net/sjlee0/robust-and-scalable-concurrent-
programming-lesson-from-the-trenches
 http://www.slideshare.net/caroljmcdonald/java-concurrency-memory-
model-and-trends-4961797
 http://www.slideshare.net/alexmiller/java-concurrency-gotchas-3666977
 Effective Java

Effective java - concurrency

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Effective java - concurrency (20)

More from feng lee (6)

Recently uploaded (20)

Effective java - concurrency