Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modern Java Concurrency (OSCON 2012)


Published on

OSCON 2012 tutorial session Part III

Published in: Technology, News & Politics
  • Be the first to comment

Modern Java Concurrency (OSCON 2012)

  1. The Well-Grounded Java Developer Modern Java Concurrency
  2. Are you a fluffy animal lover..? Leave now. 2
  3. 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
  4. 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
  5. 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
  6. 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?
  7. Perhaps... previous treatments didnt involve enough Otters. We will rectify this. 7
  8. If you suffer from lutraphobia, you may want to leave now... Fluffy cute animals BITE 8
  9. Otterly Amazing Tails of Modern Java Concurrency • Srsly - Otters! See those teeth? We warned you.
  10. 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
  11. 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?
  12. 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?
  13. 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
  14. Transistor Counts
  15. Transistor Counts
  16. 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
  17. Spending the transistor budget• More and more complex contortions... - ILP, CMT, Branch prediction, etc, etc
  18. 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
  19. Classic Java Concurrency
  20. Classic Java Concurrency• Why synchronized?• Provides exclusion• Need locking to make mutation concurrency-safe• Locking gets complicated - Can become fragile
  21. I wrap sychronized....around entire classes Safe as Fort Knox 21
  22. 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
  23. 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
  24. The JMM• Primary concepts: - synchronizes-with - happens-before - release-before-acquire - as-if-serial
  25. Synchronizes-with
  26. 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
  27. java.util.concurrent
  28. 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
  29. Locks in j.u.c• Lock is an interface• ReentrantLock is the usual implementation
  30. Conditions in j.u.c
  31. Conditions in j.u.c
  32. HashMap• HashMap has: - Hash function - Even distribution of buckets
  33. ConcurrentHashMap (CHM)• Concurrent form - Can lock independently - Seems lock-free to users - Has atomic operations
  34. CopyOnWriteArrayList (COWAL)•
  35. CopyOnWriteArrayList (COWAL)• Makes separate copies of underlying structure• Iterator will never throw ConcurrentModificationException
  36. CountDownLatch
  37. 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
  38. Example - CountDownLatch
  39. Handoff Queue (in-mem)
  40. 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
  41. Just use JMS! 41
  42. Example - LinkedBlockingQueue
  43. Executors
  44. Animals were harmed in the making of this presentation Crab got executed 44
  45. 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
  46. Example - ThreadPoolManager
  47. Example - QueueReaderTask
  48. Fork/Join
  49. 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
  50. Fork/Join• Typical divide and conquer style problem - invokeall() performs the threadpool, worker & queue magic
  51. 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
  52. Stepping Back
  53. 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
  54. 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
  55. 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
  56. 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
  57. 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
  58. Where is our beer!? 58
  59. Thanks for listening! (@kittylyst, @karianna)