JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 240 contents

https://www.youtube.com/watch?v=PNx9WqQ9QeA
The 10 Common Concurrency Models (Page last updated May 2019, Added 2019-05-26, Author Jack Shirazi, Publisher Devoxx). Tips:

• "Shared mutable state" is what makes concurrency particularly difficult. You can either eliminate one of those 3 words, or you need to use optimistic or pessimistic transactional operations.
• Your high level options for correct concurrency are: Optimistic transactional operations (compare and swap); Pessimistic transactional operations (locks); Unshared state (state is isolated to a single thread); Immutable state; No state (stateless).
• Frameworks that implement high level concurrency models tend to have a fundamental flaw in making maintenance difficult because the framework tends to obscure where problems are when troubleshooting. So far no frameworks have adequately addressed this. Consequently, the best practice when using any concurrency model framework is to keep your codebase small enough to be able to reason about the whole application. (Project Loom with fibres is potentially going to avoid this limitation, but that's currently - in 2020 - only available as a non-main build).

https://www.youtube.com/watch?v=RMR75VzYoos
Race Conditions in Java Multithreading (Page last updated October 2020, Added 2020-11-29, Author Jakob Jenkov, Publisher Jenkov.com). Tips:

• Race conditions can occur when two or more threads read and write the same variable non-atomically with a read-modify-write or check-then-act pattern
• Race conditions can be avoided by synchronizing the critical section of code that is doing the non-atomic read-modify-write or check-then-act pattern
• When one thread is updating a field and another thread is reading that field, you can have a type of race condition called a visibility problem, where the reading thread is not guaranteed to see the updates made in the updating thread so it sees stale values. You can use synchronize or volatile to make the updates visible

https://www.youtube.com/watch?v=kQEu1VsrG44
Memory Efficient Java (Page last updated November 2020, Added 2020-11-29, Author Kirk Pepperdine, Publisher GOTO). Tips:

• Allocations are cheap, but still can be excessive if done too much. Target reducing excessive memory allocations from yours and your 3rd party code (eg logging frameworks).
• Memory allocations above 1GB/sec tend to produce a bottleneck. Under 300MB/sec tends to be fine. This is correlated to chip speed rather than other CPU and memory aspects, so more powerful hosts doesn't change this much.
• Profilers can disturb the JIT optimizations enough to stop allocation eliminations optimizations happening, so beware that happening when allocation profiling. JFR should avoid that as it uses internal JVM counters.
• Making allocations too often also means GCs happen more often and objects tend to get promoted to old gen more often so have to be collected with the more expensive old gen collector - it all snowballs

https://www.youtube.com/watch?v=O3mKz7HgSN8
Prepare for What "Loom"s Ahead (Page last updated November 2020, Added 2020-11-29, Author Heinz Kabutz, Publisher JDConf). Tips:

• Native threads are large resources so you can't use millions of them in a single JVM. Lightweight virtual threads - fibres - are light resources and can be used like threads for massive concurrency, especially efficient for IO bound calls
• Callables and Futures and Executors let you simply parallelize requests in a thread pool, but for IO bound calls the pool size (so number of threads) limits the parallelism
• CompletableFuture let's you build asynchronous parallelized features but results in complicated code, and you need to explicitly separate CPU bound and IO bound tasks into separate thread pools or they will conflict on resource consumption
• JVM Loom virtual threads are multiplexed in a fork-join pool of native threads (termed carrier threads) and are only active on the carrier thread when they are not blocked. When they block, they move off the carrier thread, letting that carrier thread execute another virtual thread. This allows very efficient serial-like code which can be easily parallelized by having a task per virtual thread.
• ExecutorService is no (JDK 16+) AutoCloseable, close() will call shutdown and awaitTermination() when it exits scope
• If you find you have blocked threads in your pool, you may need to use ManagedBlocker, the latest JDKs do this but older ones might need you to manually wrap code in a ManagedBlocker
• Uncontended ConcurrentHashMap operations are slower without biased locking - consider using -XX:+UseBiasedLocking if you have this situation, and report to the JDK developers your situation so they can evaluate it, as biased locking is deprecated (since JDK 15) and will be removed soon
• Use ScopedVariables instead of ThreadLocals when using virtual threads, because ThreadLocal objects are large (they have an internal maps per value) so won't scale as well as the virtual threads
• If you are doing a huge amount of concurrent IO in many virtual threads, you need to check the size of the IO objects you are using because you will have one per virtual threads, and some are much bigger than others, eg PrintStream uses 25k per stream which would limit your concurrency because not that many can fit into reasonable memory

Jack Shirazi Back to newsletter 240 contents