Your SlideShare is downloading. ×
Java Core | Modern Java Concurrency | Martijn Verburg & Ben Evans
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Java Core | Modern Java Concurrency | Martijn Verburg & Ben Evans

2,101
views

Published on

Published in: Technology, News & Politics

1 Comment
11 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,101
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
104
Comments
1
Likes
11
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • * Hands up for Java 6, 5, 4.... * Hands up for j.u.c
  • Hands up if you’re daunted by the refactoring that would be required
  • The practice of managing your threads (or Otters!) is governed by four forces (after Doug Lea)
  • It’s a little-known fact that Otters are scared of log-linear graphs
  • Very successful within own frame of reference, but caveats Reference Mechanical sympathy again here
  • * So you can contort more and more, but you’re chasing diminishing returns * Ultimately, that exponent gap between clock speed and memory will do for you
  • * Raise your hand if you use the process monitor on Ubuntu or another Linux. OK, have you seen how Java processes behave under that?
  • * Explain that we’re going to show replacements for using synchronized * Raise your hand if you know why we use the keyword “synchronized” to denote a critical section in Java
  • How performant do we think FS objects are? Immutability is good, but watch the copy-cost
  • happens-before defines a “partial order” (if you’re a mathematician) JMM is even worse than the generics constraints part of the spec!
  • * Hands up if you know what a NUMA architecture is? * In some ways, this is actually easier to explain on a NUMA arch...
  • Lock basically replaces synchronized, but is more flexible MONITORENTER & MONITOREXIT
  • Condition takes the place of wait() / notify() (Object monitors) Talk to the cases - 1 putter, 1 taker, many putters, few takers, few putters, many takers - think about this stuff at the design stage
  • Basically it’s a drop-in replacement for regular HashMap “ What’s the worst thing that can happen if you’re iterating over the keys of a regular HashMap and someone alters it underneath you?”
  • Not quite a drop-in replacement - Performance needs to be thought about Talk about Iterators
  • BlockingQueue offers several different ways to interact with it (see the Javadoc)
  • offer is similar to add but doesn’t throw exceptions Producers adding trade orders for example
  • Let’s step through a quasi-realistic example
  • As well as RecursiveAction there’s the more general ForkJoinTask
  • Multithreaded Quicksort - shows a speedup from O(nlog n) to O(n) - not quite linear, but not bad
  • So this is pretty much a statement of the state-of-the-art in Java concurrency
  • * Thread is the assembly language of concurrency * We need to move to a more managed model
  • Coroutines, etc
  • Transcript

    • 1. Modern Java Concurrency
      • Ben Evans and Martijn Verburg
      • (@kittylyst @karianna)
      • http://www.teamsparq.net
      • Creative Commons - Attribution-NonCommercial-NoDerivs 3.0
      Slide Design by http://www.kerrykenneally.com
    • 2. No, we’re not in sales!
      • Directors of TeamSparq
        • “Optimisation for Technical Teams”
      • Ben is known for his performance and concurrency work
      • Martijn is “the Diabolical Developer” - @diabolicaldev
      • Authors of “The Well-Grounded Java Developer”
      • Co-Leaders of the LJC (London’s Java User Group)
        • Hold a seat on the JCP SE/EE Executive Committee
      • Regular conference speakers (JavaOne, Devoxx, OSCON, etc)
    • 3. Who are these two anyway?
    • 4. About this talk
      • We only have 1 hour to talk today
      • Huge amount to talk about
      • This subject fills 2 (or even 4) days worth of training
      • We will give you some highlights today
    • 5. Modern Java concurrency
      • Not a new subject
        • Underwent a revolution with Java 5
      • More refinements since
        • Still more coming in 7
      • java.util.concurrent (j.u.c) really fast in 6
        • Better yet in 7
      • However, still under-appreciated by a surprising number
      • Too much Java 4-style concurrency code still in PROD
        • Why...?
    • 6. Java concurrency - Why not upgrade?
      • Too much legacy code?
        • People scared to refactor?
      • People don’t know j.u.c is easier than “classic” Java concurrency?
      • 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. Modern Java concurrency
      • Perhaps: Previous treatments haven’t involved enough otters.
      • We will rectify this.
      • If you suffer from lutraphobia, you may want to leave now...
    • 8. Otterly Amazing Tails of Modern Java Concurrency
      • Srsly.
      • Otters!
    • 9. Why Otters?
      • Otters are a very good metaphor
      • for concurrency
      • Not just because they look a bit
      • like threads (i.e. long and thin)
      • Collaborative, Competitive & Sneaky
      • Can hare off in opposite directions
      • Capable of wreaking havoc
      • if not contained
    • 10. Otter Management
      • 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 processing cores?
      • Reusability
        • How easy is it to reuse the system in other applications?
    • 11. Some History
      • Until recently, most computers had only one processing core
      • Multithreading was simulated on a single core
        • Not true concurrency
      • Serial approach to algorithms often sufficed
      • Interleaved multithreading can mask errors
        • Or be more forgiving than true concurrency
      • Why and how (and when) did things change?
    • 12. 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 transistor counts
        • Not clock speed
        • Or overall performance
    • 13. Transistor Counts
    • 14. Moore’s Law - Problems
      • 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 restricted by L1 cache misses rather than CPU speed
        • After JIT compilation
    • 15. Spending the transistor budget More and more complex contortions... ILP, CMT, Branch prediction, etc, etc
    • 16. Multi-core
      • If we can’t increase clock speed / overall performance
        • Have to go multi-core
        • Concurrency and performance are tied together
      • Real concurrency
        • Separate threads executing on different cores at the same moment
      • The JVM runtime controls scheduling
        • Java thread scheduling does NOT behave like OS scheduling
      • Concurrency becomes the performance improver
    • 17. Classic Concurrency
      • Provides exclusion
      • Need locking to make mutation concurrency-safe
      • Locking gets complicated
      • Can become fragile
      • Why synchronized ?
    • 18. Three 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
        • Often the only game in town
    • 19. The JMM
      • Mathematical description of memory
      • Most impenetrable part of the Java language spec
      • JMM makes
      • minimum guarantees
      • Real JVMs (and CPUs) may do more
      • Primary concepts
      • synchronizes-with
      • happens-before
      • release-before-acquire
      • as-if-serial
    • 20. Synchronizes-with
      • Threads have their own description 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
    • 21. java.util.concurrent
      • Thanks, Doug!
      • j.u.c has building blocks for
      • concurrent code
        • ReentrantLock
        • Condition
        • ConcurrentHashMap
        • CopyOnWriteArrayList
        • Other Concurrent Data Structures
    • 22. Locks in j.u.c
      • Lock is an interface
      • ReentrantLock is the usual implementation
    • 23. Conditions in j.u.c
    • 24. Conditions in j.u.c
    • 25. ConcurrentHashMap (CHM)
      • HashMap has:
        • Hash function
        • Even distribution of buckets
      • Concurrent form
        • Can lock independently
        • Seems lock-free to users
        • Has atomic operations
    • 26. CopyOnWriteArrayList (COWAL)
      • Similar idea to CHM
        • Makes separate copies of underlying structure
      • Iterator will never throw ConcurrentModificationException
    • 27. CountDownLatch
      • A group consensus construct
      • countDown() decrements the count
      • await() blocks until count == 0
        • i.e. consensus
      • Constructor takes an int param
        • The count
      • Quite a few use cases
        • e.g. Multithreaded testing
    • 28. Example - CountDownLatch
    • 29. 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
    • 30. Example - LinkedBlockingQueue
      • Imagine multiple producers and consumers
    • 31. 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
      • Final building block for modern concurrent applications with Java
    • 32. Example - ThreadPoolManager
    • 33. Example - QueueReaderTask
    • 34. 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
    • 35. Fork/Join
      • Typical divide and conquer style problem
        • invokeall() performs the threadpool/worker queue magic
    • 36. Concurrent Java Code
      • Mutable state (objects) protected by locks
      • Concurrent data structures
        • CHM, COWAL
      • Be careful of performance
        • especially COWAL
      • Synchronous multithreading - explicit synchronization
      • Executor -based threadpools
      • Asynch multithreading communicates using queue-like handoffs
    • 37. 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
    • 38. Imagine a world...
      • The runtime & environment 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
    • 39. 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
        • LMAX’s OSS “Disruptor” framework proves this
        • Modern low-latency Java trading systems are screamingly fast
        • 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
    • 40. 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
    • 41. Acknowledgments
      • All otter images Creative Commons or Fair Use
      • 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
      • Slide design by http://www.kerrykenneally.com
      • The Disruptor! http://code.google.com/p/disruptor/
    • 42. Thanks for listening! (@kittylyst, @karianna)
      • http://www.teamsparq.net
      • http://www.java7developer.com