Modern Java Concurrency (OSCON 2012)

The Well-Grounded Java Developer Modern Java Concurrency

Are you a fluffy animal lover..? Leave now. 2

Why Modern Java Concurrency? • The WGJD wants to utilise modern hardware • The WGJD wants to write concurrent code - Safely - Without fear - With an understanding of performance implications • The WGJD wants to take advantage of: - JVM support for parallelised operations - An API that expands on synchronized • Modern Java Concurrency lets you do all of this

About this section• We only have ~60mins hour to talk today• Huge amount to talk about• This subject typically fills 4 days worth of training• We will give you some highlights today• For die-hard low latency fiends - Locks are actually bad hmmkay! - Come talk to us afterwards to find out more

Modern Java concurrency• Not a new subject - Underwent a revolution with Java 5 - More refinements in 6 and 7 - Another major library overhaul coming in 8 with lambdas• java.util.concurrent (j.u.c) really fast in 6 - Better yet in 7 & blazing in 8• j.u.c. is still under-appreciated - Too much Java 4-style concurrency code still written

Java concurrency - Why not upgrade? • Too much legacy code? - People scared to refactor? • People don’t know j.u.c is easier? - People don’t know j.u.c is faster than classic? • People don’t know that you can mix-and-match - With a bit of care • Still not being taught at Universities? • Not enough people reading Doug Lea or Brian Goetz?

Perhaps... previous treatments didnt involve enough Otters. We will rectify this. 7

If you suffer from lutraphobia, you may want to leave now... Fluffy cute animals BITE 8

Otterly Amazing Tails of Modern Java Concurrency • Srsly - Otters! See those teeth? We warned you.

Why Otters?• Otters are a very good metaphor - Not just because they look a bit like threads (i.e. long and thin)• They are Collaborative, Competitive & Sneaky• Hare off in opposite directions - Wreaking havoc if not contained

Otter Management (aka the 4 forces) • Safety - Does each object stay self-consistent? - No matter what other operations are happening? • Liveness - Does the program eventually progress? - Are any failures to progress temporary or permanent? • Performance - How well does the system take advantage of cores? • Reusability - How easy is it to reuse the system in other applications?

Some History• Until recently, most CPUs had one processing core• Multithreading was simulated on that single core - Not true concurrency• Serial approach to algorithms often sufficed• Interleaved multithreading can mask errors - Or be more forgiving than true concurrency• Why, how and when did things change?

Moore’s Law• “The number of transistors on an economic-to- produce chip roughly doubles every 2 years”• Originally stated in 1965 - Expected to hold for the 10 years to 1975 - Still going strong• Named for Gordon Moore (Intel founder) - About # transistors, not clock speed or overall performance

Transistor Counts

Moore’s Law - Problems• Remember, its not about overall performance• Memory latency exponent gap - Need to keep the processing pipeline full - Add memory caches of faster SRAM “close” to the CPU • (L1, L2 etc)• Code is restricted by L1 cache misses - Rather than CPU speed - After JIT compilation

Spending the transistor budget• More and more complex contortions... - ILP, CMT, Branch prediction, etc, etc

Multi-core• If we can’t increase clock speed / performance.. - We have to go multi-core - Concurrency and performance are now tied together• Real concurrency - Separate threads executing on cores at the same moment• The JVM runtime controls thread scheduling - Java scheduling does NOT behave like OS scheduling• Concurrency becomes the performance improver

Classic Java Concurrency

Classic Java Concurrency• Why synchronized?• Provides exclusion• Need locking to make mutation concurrency-safe• Locking gets complicated - Can become fragile

I wrap sychronized....around entire classes Safe as Fort Knox 21

3 approaches to Concurrent Type Safety • Fully-synchronized Objects - Synchronize all methods on all classes • Immutability - Useful, but may have high copy-cost - Requires programmer discipline • Be Very, Very Careful - Difficult - Fragile - With Java - Often the only game in town

The JMM• Mathematical description of memory• Most impenetrable part of the Java language spec - Even worse than generics• JMM makes minimum guarantees• Real JVMs (and CPUs) may do more - Especially Intel chipsets

The JMM• Primary concepts: - synchronizes-with - happens-before - release-before-acquire - as-if-serial

Synchronizes-with

Synchronizes-with• Threads have their own desc of an object’s state - This must be flushed to main memory and other threads• synchronized means that this local view: - Has been synchronized-with the other threads• Defines touch-points where threads must perform synching

java.util.concurrent

java.util.concurrent• Thanks, Doug Lea and co!• j.u.c has building blocks for concurrent code - ReentrantLock - Condition - ConcurrentHashMap - CopyOnWriteArrayList - Other Concurrent Data Structures

Locks in j.u.c• Lock is an interface• ReentrantLock is the usual implementation

Conditions in j.u.c

HashMap• HashMap has: - Hash function - Even distribution of buckets

ConcurrentHashMap (CHM)• Concurrent form - Can lock independently - Seems lock-free to users - Has atomic operations

CopyOnWriteArrayList (COWAL)•

CopyOnWriteArrayList (COWAL)• Makes separate copies of underlying structure• Iterator will never throw ConcurrentModificationException

CountDownLatch

CountDownLatch• A group consensus construct• countDown() decrements the count• await() blocks until count == 0 - i.e. consensus• Constructor takes an int (the count)• Quite a few use cases - e.g. Multithreaded testing

Example - CountDownLatch

Handoff Queue (in-mem)

Handoff Queue (in-mem)• Efficient way to hand off work between threadpools• BlockingQueue a good pick• Has blocking ops with timeouts - e.g. for backoff / retry• Two basic implementations - ArrayList and LinkedList backed• Java 7 introduces the shiny new TransferQueue

Just use JMS! 41

Example - LinkedBlockingQueue

Executors

Animals were harmed in the making of this presentation Crab got executed 44

Executors• j.u.c execution constructs - Callable, Future, FutureTask• In addition to the venerable - Thread and Runnable• Stop using TimerTask!• Executors class provides factory methods for making threadpools - ScheduledThreadPoolExecutor is one standard choice

Example - ThreadPoolManager

Example - QueueReaderTask

Fork/Join

Fork/Join• Java 7 introduces F/J - similar to MapReduce - useful for a certain class of problems - F/J executions are not really threads• In our example, we subclass RecursiveAction• Need to provide a compute() method - And a way of merging results• F/J provides an invokeAll() to hand off more tasks

Fork/Join• Typical divide and conquer style problem - invokeall() performs the threadpool, worker & queue magic

Concurrent Java Code• Mutable state (objects) protected by locks• Concurrent data structures - CHM, COWAL• Be careful of performance - especially COWAL• Explicit synchronization for multi-threading• Executor-based threadpools• Queue-like handoffs used for asynch comms

Stepping Back

Stepping Back• Concurrency is key to the future of performant code• Mutable state is hard• Need both synch & asynch state sharing• Locks can be hard to use correctly• JMM is a low-level, flexible model - Need higher-level concurrency model - Thread is still too low-level

Imagine a world...• The JVM helped out the programmer more: - Runtime-managed concurrency - Collections were thread-safe by default - Objects were immutable by default - State was well encapsulated and not shared by default• Thread wasn’t the default choice for unit of concurrent execution• Copy-on-write was the basis for mutation of collections / synchronous multithreading• Hand-off queues were the basis for asynchronous multithreading

What can we do with Java?• We’re stuck with a lot of heritage in Java - But the JVM and JMM are very sound• You don’t have to abandon Java - Mechanical sympathy and clean code get you far - The JIT compiler just gets better and better• If we wanted to dream of a new language - It should be on the JVM - It should build on what we’ve learned in 15 years of Java

New Frontiers in Concurrency• There are several options now on the JVM - New possibilities built-in to the language syntax - Synch and asynch models• Scala offers an Actors model - And the powerful Akka framework• Clojure is immutable by default - Has agents (like actors) & shared-nothing by default - Also has a Software Transactional Memory (STM) model• Groovy has GPARs

Acknowledgments• All Otter images Creative Commons or Fair Use• Matt Raible - 20 criteria of selecting web frameworks• Ola Bini - Polyglot pyramid• Photos owned by Flickr Users - moff, spark, sodaro, lonecellotheory, tomsowerby - farnsworth, prince, marcus_jb1973, mliu92, Ed Zitron, - NaturalLight & monkeywing• Dancing Otter by the amazing Nicola Slater @ folksy

Where is our beer!? 58

Thanks for listening! (@kittylyst, @karianna)

http://tddv-conf-01	20
http://vestawiki	3
http://tddv-conf-01.ad.trustvesta.com	2
http://coderwall.com	1
http://www.linkedin.com	1

Modern Java Concurrency (OSCON 2012)

by Martijn Verburg on Jul 17, 2012

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 27

Statistics

Modern Java Concurrency (OSCON 2012) Presentation Transcript