The document discusses Java concurrency. It covers how concurrency has evolved in Java over the years. Some key concurrency concepts and patterns are explained like atomicity, visibility, synchronization, confinement, immutability and cooperation. The document does a deep dive into the java.util.concurrent packages, atomic classes, locks, executor framework and fork join framework. It discusses that there are usually multiple ways to solve a concurrency problem and compares options. Common concurrency mistakes are also highlighted.
2. 2
Agenda
ď§ United at birth
ď§ Why more relevant now
ď§ Concurrency over the years
ď§ Basics & Myths
ď§ Concurrency Patterns
ď§ Deep-dive
ď§ There's more than one way to solve it!!
ď§ Common gotchas
ď§ Q&A
3. 3
Java & Concurrency : United at birth
â
In-built into the language
â
Not an after thought
â
Support for threads from Day 1
â
Everything is a monitor
â
Simplicity over complexity
â
Multiple inheritance
â
Operator overloading
â
Choice of languages
â
Scala, Clojure
4. 4
Why is it more relevant now
⢠H/W & S/W trends
â No longer privilege of few
â Scaling accentuates Vertical and horizontal scaling mean more
complexity
â Distributed caches, faster I/O
â Weak Cache coherence
⢠Application requirements
â Impunity of slow system lifted
â Elasticity is the mantra
â The weakest link draws the whole system down
â Bottlenecks can be really really costly
5. 5
Concurrency over the years
Java VersionJava Version FeaturesFeatures
JDK 1.0 âThreads
ââsynchronizedâ keyword
âHashTable(thread-safe but synchronized classes)
JDK 1.2 âCollections framework(updated)
âun-synchronized classes bound by
synchronized accessors
âeg: Collections.synchronizedMap()
âUse when you need sync
JDK 1.5 â concurrency package JSR166 java.util.concurrent
JDK 7 â Updated java.util.concurrent package(JSR166y)
Fork-Join and Executor Framework
JDK 8 â Modularity
â Lamda
6. 6
Concurrency : Basics
Three elements of a concurrent Application
ďŹ
Atomicity
ďŹ
Certain pieces of an application must all be executed as one unit
â
Visibility
ďŹ
Changes that you make to a value to be visible precisely when you intend them to
be
â
Synchronization
ďŹ
Concurrent access to shared variables should be guarded
Terms you will come across
â
JMM â The specification that guarantees how the JVM should work
â
Monitor â Intrinsic lock (Every object has a monitor associated with it)
â
Race condition â An operation on shared resources whose outcome may be in-
deterministic
â
ďŹ
7. 7
Concurrency : Myths
â
The more the threads, faster my application is
⢠A bigger system means faster execution
⢠Processors/compilers can optimize my code for
parallelism
⢠Locks make the program go slow
⢠Re-factoring is easy
⢠Writing concurrent application is a black-art
8. 8
Common concurrency patterns
Dynamic Exclusion Through Implicit Locks
⢠a.k.a âsynchronizedâ
⢠Lock obtained if method is declared synchronized
⢠Watch out for fine/coarse grained locks.
⢠Dos/Dont's:
â Avoid CPU/IO intensive operations inside âsynchronizedâ block.
â âsynchronizeâ on a code block and not method (if appropriate)
⢠Remember that JIT can re-order execution
9. 9
Common concurrency patterns
Structural Exclusion Through Confinement
⢠Options:
â 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
⢠Do's/Dont's:
â Confinement cannot be relied on unless a design is leak proof
â Combine confinement with appropriate locking discipline
â Use ThreadLocal variables to maintain Thread Confinement
10. 10
Common concurrency patterns
Immutability
⢠Object state cannot change after construction
⢠Are automatically thread-safe
⢠Immutability is guranteed only when :
â All fields are declared final
â Object reference fields must not allow modifications anywhere in the object
graph reachable from the fields after construction
â The class should be declared final (to prevent a subclass from subverting
these rules)
⢠Immutable objects eliminate a bunch of issues around concurrency. Use whenever you
can.
⢠Have âfailure atomicityâ - upon an exception, state is never undesirable or
indeterministic.
"Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot"Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot
be made immutable, limit its mutability as much as possible." - Joshua Blochbe made immutable, limit its mutability as much as possible." - Joshua Bloch
11. 11
Common concurrency patterns
Co-operation
⢠Wait-notify mechanisms
⢠One thread creates a condition and another one waits for it
⢠All threads are treated the same - when multiple threads are waiting,
no guarantee on which one would wake up
⢠Missed or early notifications
⢠Do's/Dont's:
â Use notifyAll() instead of notify()
â Wait() in a while loop
â Call wait() and notify() inside synchronized block
12. 12
Deep Dive
⢠JSR166 - âjava.util.concurrentâ packages
⢠Introduced in JDK 5
⢠Motivation
â Creating APIs for commonly used functionality
â Application/scenario agnostic
â âvolatileâ guaranteed visibility but not atomicity
â Synchronization is expensive (and can cause dead-lock)
â
Atomic Variables, nanosecond timing, Condition variables, Lock classes,
tryLock, Queues, Barriers, Executors.....
â
13. 13
Deep Dive â Atomic Classes
⢠java.util.concurrent.atomic.Atomic* classes
â
Provides a worthy substitute for âvolatileâ and âsynchronizedâ
â
Available on Integer, Long, Boolean, Object Ref, Arrays
â
CompareAndSet(), incrementAndGet() etc guarantee atomicity
14. 14
Deep Dive : Locks
ReentrantLock
ďŹ
âsynchronizationâ on steroids
ďŹ
Supports Lock state, non-blocking tryLock() and interruptible locking
ďŹ
Throughput can be higher by order of magnitudes
ďŹ
Can be extended to set âfairnessâ and âConditionâ
ďŹ
ďŹ
ďŹ
ďŹ
ďŹ
ďŹ
ďŹ
Use ONLY and ONLY if âsynchronizedâ will not solve your problems
ďŹ
If your Application needs timed-locks, interruptible locks, multiple condition locks
15. 15
Deep Dive : Executor Framework
â
Implemented via java.util.concurrent.ExecutorService
â
Provides flexible thread pool implementation
â
Producer-consumer pattern
â Producer : Creates work
â Consumer : Executes the work
â
â
â
â
â
Consider newCachedThreadPool if you don't want to bound no. of threads
16. 16
Deep Dive : Executor Framework
â
Remember to shut it down
â
Asynchronous execution may hide hidden tasks
â
17. 17
Deep Dive: Fork Join Framework
âFramework for supporting a style of programming in which problems are solved by recursively splitting them in
to sub tasks that are solved in parallel, waiting for them to complete and then composing resultsâ
â
Introduced through JSR166y and part of Java 7
â
Introduces Parallel-Array (PA) concept to Java (simlar to Map-Reduce?)
â
Extends the executor framework for Recursive style problems
â
Makes use of work stealing algorithm
â
Transparent Parallelism requiring no tuning (almost!)
â
Suited for MMP Architectures.
â
Number of sub tasks can be altered at run-time
ďŹ
âForkâ Starts a new parallel fork/join subtask
ďŹ
âJoinâ causes current task not to proceed until the forked task is complete
ďŹ
This can happen recursively till tasks are smaller enough to be solved sequentially
Components of a FJ framework
â
The guy who does the work (business logic)
â
The guy who tells how the work can be split
â
The guy who coordinates it all (FJ)
18. 18
There's more than one way to solve it
â
There's always more than one way to solve the problem
â
Know the pros/cons of each approach
â
Example :
Not Thread Safe
19. 19
Option 1 : Using âvolatileâ keyword
Pros:
â
Simple, easy to write and understand
â
Would solve most of the requirement
Cons:
â
Thread looping
â
No option to know/set priority of waiting threads
There's more than one way to solve it
20. 20
Option 2 : Using âAtomicBooleanâ
Pros:
â
Fairly straight-forward
â
âtryLock()â can prevent costly thread spins
â
Flexibility to set Condition and âfairnessâ of waiting threads
Cons:
â
Slight over-head if you need primitive data locking
There's more than one way to solve it
21. 21
Option 3 : Using âsynchronizedâ
Pros:
â
Locks are intrinsic and so no need to release them explicitly
Cons
â
Code is a lot more verbose
â
Empty thread looping
There's more than one way to solve it
22. 22
Common concurrency mistakes
â
synchronization
â Fine/coarse grained synchronization
â Synchronizing just data
â Validating data integrity at one level
â Synchronizing on ânullâ
â Changing synchronizing object instance
â Synchronizing on string literals
â Writing with synchronization but reading w/o it
â Volatile array -
⢠âvalarrâ is a volatile reference to an array, but array elements are not
23. 23
Common concurrency mistakes
â
Volatile will work only when
â write to variable does not depend on current value
â Write does not depend on any other non-atomic operation
â
CachedThreadPool is un-bound â You may run out of resources
sooner than you thought
â
â
The list never ends.....
â
Recommend go through âJava Platform Concurrency Gotchasâ
- Alex Miller
â
24. 24
Re-cap
ď§ Relevance of concurrency
ď§ Basics & Myths
ď§ Concurrency Patterns
ď§ Deep-dive
ď§ There's more than one way to solve it!!
ď§ Common gotchas
ď§ Q&A