Java & ConcurrencyLakshmi Narasimhan
2Agenda United at birth Why more relevant now Concurrency over the years Basics & Myths Concurrency Patterns Deep-di...
3Java & Concurrency : United at birth●In-built into the language●Not an after thought●Support for threads from Day 1●Every...
4Why is it more relevant now• H/W & S/W trends– No longer privilege of few– Scaling accentuates Vertical and horizontal sc...
5Concurrency over the yearsJava VersionJava Version FeaturesFeaturesJDK 1.0 ●Threads●“synchronized” keyword●HashTable(thre...
6Concurrency : BasicsThree elements of a concurrent ApplicationAtomicityCertain pieces of an application must all be exe...
7Concurrency : Myths●The more the threads, faster my application is• A bigger system means faster execution• Processors/co...
8Common concurrency patternsDynamic Exclusion Through Implicit Locks• a.k.a “synchronized”• Lock obtained if method is dec...
9Common concurrency patternsStructural Exclusion Through Confinement• Options:– Thread confinement : Access object from a ...
10Common concurrency patternsImmutability• Object state cannot change after construction• Are automatically thread-safe• I...
11Common concurrency patternsCo-operation• Wait-notify mechanisms• One thread creates a condition and another one waits fo...
12Deep Dive• JSR166 - “java.util.concurrent” packages• Introduced in JDK 5• Motivation– Creating APIs for commonly used fu...
13Deep Dive – Atomic Classes• java.util.concurrent.atomic.Atomic* classes●Provides a worthy substitute for “volatile” and ...
14Deep Dive : LocksReentrantLock“synchronization” on steroidsSupports Lock state, non-blocking tryLock() and interruptib...
15Deep Dive : Executor Framework●Implemented via java.util.concurrent.ExecutorService●Provides flexible thread pool implem...
16Deep Dive : Executor Framework●Remember to shut it down●Asynchronous execution may hide hidden tasks●
17Deep Dive: Fork Join Framework“Framework for supporting a style of programming in which problems are solved by recursive...
18Theres more than one way to solve it●Theres always more than one way to solve the problem●Know the pros/cons of each app...
19Option 1 : Using “volatile” keywordPros:●Simple, easy to write and understand●Would solve most of the requirementCons:●T...
20Option 2 : Using “AtomicBoolean”Pros:●Fairly straight-forward●“tryLock()” can prevent costly thread spins●Flexibility to...
21Option 3 : Using “synchronized”Pros:●Locks are intrinsic and so no need to release them explicitlyCons●Code is a lot mor...
22Common concurrency mistakes●synchronization– Fine/coarse grained synchronization– Synchronizing just data– Validating da...
23Common concurrency mistakes●Volatile will work only when– write to variable does not depend on current value– Write does...
24Re-cap Relevance of concurrency Basics & Myths Concurrency Patterns Deep-dive Theres more than one way to solve it!...
Upcoming SlideShare
Loading in …5
×

Concurrency in Java

709 views
615 views

Published on

A set of slides on the basics of concurrency touching upon Java's support for multi-threaded programming, do's and dont's, common approaches to developing concurrent applications and evolution of APIs in Java that support effective multi-threaded programming

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

  • Be the first to like this

No Downloads
Views
Total views
709
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Concurrency in Java

  1. 1. Java & ConcurrencyLakshmi Narasimhan
  2. 2. 2Agenda United at birth Why more relevant now Concurrency over the years Basics & Myths Concurrency Patterns Deep-dive Theres more than one way to solve it!! Common gotchas Q&A
  3. 3. 3Java & 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. 4Why is it more relevant now• H/W & S/W trends– No longer privilege of few– Scaling accentuates Vertical and horizontal scaling mean morecomplexity– 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. 5Concurrency over the yearsJava VersionJava Version FeaturesFeaturesJDK 1.0 ●Threads●“synchronized” keyword●HashTable(thread-safe but synchronized classes)JDK 1.2 ●Collections framework(updated)●un-synchronized classes bound bysynchronized accessors●eg: Collections.synchronizedMap()●Use when you need syncJDK 1.5 ● concurrency package JSR166 java.util.concurrentJDK 7 ● Updated java.util.concurrent package(JSR166y)Fork-Join and Executor FrameworkJDK 8 ● Modularity● Lamda
  6. 6. 6Concurrency : BasicsThree 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 tobe●SynchronizationConcurrent access to shared variables should be guardedTerms 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. 7Concurrency : Myths●The more the threads, faster my application is• A bigger system means faster execution• Processors/compilers can optimize my code forparallelism• Locks make the program go slow• Re-factoring is easy• Writing concurrent application is a black-art
  8. 8. 8Common concurrency patternsDynamic Exclusion Through Implicit Locks• a.k.a “synchronized”• Lock obtained if method is declared synchronized• Watch out for fine/coarse grained locks.• Dos/Donts:– 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. 9Common concurrency patternsStructural Exclusion Through Confinement• Options:– Thread confinement : Access object from a single thread usingthread-per-session approach– Instance confinement : Use encapsulation techniques to restrictaccess to object state from multiple threads– Method confinement : Do not allow an object to escape frommethod by referencing it through local variables• Dos/Donts:– 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. 10Common concurrency patternsImmutability• 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 objectgraph reachable from the fields after construction– The class should be declared final (to prevent a subclass from subvertingthese rules)• Immutable objects eliminate a bunch of issues around concurrency. Use whenever youcan.• Have “failure atomicity” - upon an exception, state is never undesirable orindeterministic."Classes should be immutable unless theres a very good reason to make them mutable....If a class cannot"Classes should be immutable unless theres a very good reason to make them mutable....If a class cannotbe made immutable, limit its mutability as much as possible." - Joshua Blochbe made immutable, limit its mutability as much as possible." - Joshua Bloch
  11. 11. 11Common concurrency patternsCo-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• Dos/Donts:– Use notifyAll() instead of notify()– Wait() in a while loop– Call wait() and notify() inside synchronized block
  12. 12. 12Deep 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. 13Deep 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. 14Deep Dive : LocksReentrantLock“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. 15Deep 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 dont want to bound no. of threads
  16. 16. 16Deep Dive : Executor Framework●Remember to shut it down●Asynchronous execution may hide hidden tasks●
  17. 17. 17Deep Dive: Fork Join Framework“Framework for supporting a style of programming in which problems are solved by recursively splitting them into 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 sequentiallyComponents 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. 18Theres more than one way to solve it●Theres always more than one way to solve the problem●Know the pros/cons of each approach●Example :Not Thread Safe
  19. 19. 19Option 1 : Using “volatile” keywordPros:●Simple, easy to write and understand●Would solve most of the requirementCons:●Thread looping●No option to know/set priority of waiting threadsTheres more than one way to solve it
  20. 20. 20Option 2 : Using “AtomicBoolean”Pros:●Fairly straight-forward●“tryLock()” can prevent costly thread spins●Flexibility to set Condition and “fairness” of waiting threadsCons:●Slight over-head if you need primitive data lockingTheres more than one way to solve it
  21. 21. 21Option 3 : Using “synchronized”Pros:●Locks are intrinsic and so no need to release them explicitlyCons●Code is a lot more verbose●Empty thread loopingTheres more than one way to solve it
  22. 22. 22Common 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. 23Common 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 resourcessooner than you thought●●The list never ends.....●Recommend go through “Java Platform Concurrency Gotchas”- Alex Miller●
  24. 24. 24Re-cap Relevance of concurrency Basics & Myths Concurrency Patterns Deep-dive Theres more than one way to solve it!! Common gotchas Q&A

×