Here are a few steps I would take to analyze the issue: 1. Collect a thread dump of the application to see what threads are currently running and in what state. This will give clues about any threads that may be blocked or spinning. 2. Analyze the thread dump looking for threads that are in a RUNNABLE or BLOCKED state long-term. These could indicate spinning or long waits. 3. Check for threads waiting on locks, semaphores or other synchronization primitives. This could point to a potential deadlock. 4. Trace the code path and logic for threads of interest to understand what they are trying to accomplish and why they may be spinning or blocked. 5. Check

1. 1
Industrial IoT | Digital Transformation | Industry 4.0
Ramith Jayasinghe
CEO, Co-Founder
E: Jayasinghe@Xiges.io | Blog: https://medium.com/@ramithj
Why Concurrency is hard ?

2. 2
What We are going to discuss…
● Concurrency Coursework – Recap ?
● Common Perceptions / Observations
● Best Practices

3. 3
Concurrency – Recap?
● What's Concurrency/Parallelism?
○ Doing multiple tasks simultaneously. If there are multiple processors/computers, its truly
parallel.
● Thread ? Thread Groups? Thread States?
○ A (simultaneously) running task(s) with in a application. Logically grouped for convenience
(from a programmer’s prospective). Thread states can help when debugging (+ framework
development)
● Race Conditions ? Mutual Exclusion ?
○ Undesired effect of due to concurrent execution. Outcome depends on speed / timing.
○ There got to be a critical-section which screws up the whole thing !
○ Make sure only one thread can execute the critical section at a time.

4. 4
Concurrency – Recap?
● Locks ? Barriers ?
○ Locks are a mechanism to enable mutual exclusion.
○ Barriers are a mechanism to coordinate between set of threads. So all threads needs to wait
until others reach the barrier to proceed.
● Dead Locks ?
○ Program cannot make progress. Threads involved in dead lock are in a ‘circular wait’ on
others due to mutual exclusion and no preemption

5. 5
Concurrency – Recap?
● Starvation ?
○ Happens due to mutual exclusion or due to how scheduling algorithm works.
○ Thread/Process don’t have access to required resources to make progress.
● Atomic Variables ?
○ Implements compare and swap schematics for memory/variables.
○ Atomically read/write shared variables.

6. 6
Concurrency – Recap?
● ThreadLocal Variables ?
○ Each thread is its own version/copy of the variable.
○ Particular thread can’t see other thread’s value.
● Runnable ? Callable ? Futures ?
○ Runnable – (in java) an frequently implemented interface to specify work that needs to
happen concurrently. Doesn’t return a value after the work is completed.
○ Callable – same as Runnable. But allows programmer to return a value.
○ Future – provides a means retrieve the result of a completed callable.

7. 7
Reality
● Most of us will forget most of these in couple of weeks/months 
● If you are in to J2EE/ .NET /JavaScripts you will not deal with most of these
constructs.
● Concurrency is managed by Application Servers/Frameworks.
○ Simple / Component-based programming models (Beans, Servlets, Controllers etc).
○ Load balancing (Local/Cluster-wide) / Automatic, Bean-Managed Concurrency
○ Resource Management
● Most (= ~ 90 % ) of us just move data around:
○ Get Data  Transform  Show in GUI and/or put into a storage.

8. 8
Concurrency: Why is it difficult?
“Too many programmers writing multithreaded programs are like Mickey
Mouse in The Sorcerer's Apprentice. They learn to create a bunch of threads and
get them mostly working, but then the threads go completely out of control and
the programmer doesn't know what to do.”
Source : https://smartbear.com/blog/test-and-monitor/why-johnny-cant-write-
multithreaded-programs/

9. 9
Concurrency: Why is it difficult?
● There is a gap between with examples in text books and
real-world concurrent/distributed applications.
● Programmers don’t understand/care for best practices.
● Applying text book, intro-level content (or cut-n-paste from
web) to solve the problem at hand.

10. 10
Concurrency: Why is it difficult?
● Problems pop-up  Introduce ‘smart solutions’ [= hacks]
to remedy the issues.
● Result is:
○ Poor application performance / Stability.
○ Nobody understands the code.
○ Lots of sleepless nights / cursing !
○ Time / Money wasted.

11. 11
Concurrency: Why is it difficult?
Rule #1
With or With-out Concurrency.
Global Mutable State is bad !
Note: Anything is mutable if its state changes over
time, immutable otherwise.
java.lang.String,
java.time.LocalDate
java.lang.StringBuilder
java.util.Date
class Foo {
private final String state;
public Foo(final String initialValue) {
this.state = initialValue;
}
public String getState() {
return this.state;
}
}

12. Concurrency: Why is it difficult?
● Examples of Goble State?
○ Global static variables, static classes with public instance variables.
○ Environment Variables, Configurations.
○ Singleton Objects
● Why is it bad?
○ No control over state changes.
○ Very hard to predict / determine program’s state at a given time.
12

13. What should be the approach?
● If you are using an application server adhere to it’s programming model !
● There is no such a thing as zero global state [ In real life].
● However try to minimize it. How?
○ Define components/layers in the application correctly.
○ Figure out how to how the communication/coordination works for each layer/component.
○ Threading architecture is not thing you will figure-out/design later !
13

14. What should be the approach?
● Use a threading framework, than creating threads/locks/synchronizations
manually.
○ Thread Pools/Executor Frameworks, Disruptors, Reactive Programming
● Consider what application does:
○ Compute Heavy / IO Heavy
○ Where its going to run on, Load requirements
○ Data Access Patterns
○ Error Handling / Tracing / Debugging.
14

15. 15
Concurrency Programming Models
● Threads + Locks
● Threads + Queues
● Thread Pools / Executors
● Futures, Callbacks
● Reactive Streams, Disruptors
● Etc.
For a good comparison refer: [Concurrency – The good, the bad, the ugly]
https://www.youtube.com/watch?v=OJfS7K-Vkgk

16. 16
Concurrency: Best Practices
● Prefer local variables where possible. Reduce the use of public variables.
● If you are using collections, at least synchronize them. Its wise use concurrent
collections.
● Minimize locking scope:
○ Don’t misuse synchronized methods, blocks. Prefer synchronized blocks over methods.
○ More synchronization means your program performance may suffer.
e.g. Collections.synchronizedList(…), java.util.concurrent.ConcurrentHashMap

17. 17
Concurrency: Best Practices
● Consider using atomic variables. These implement compare-and-swap (CAS)
instructions. On modern processors supports these at hardware level.
e.g. java.util.concurrent.atomic.AtomicInteger:
boolean compareAndSet(int expect, int update)
AtomicInteger atomicInt = new AtomicInteger(4);
Atomic.compareAndSet(5, 0); // if the current value is 5 then set it to 0.

18. 18
Concurrency: Best Practices
● Think twice before creating a thread. Prefer Thread Pools / Executors instead
○ Creating threads are expensive.
○ Requires lots of boiler plate code. ( - Let’s not re-invent the wheel !)
○ Likely to be error prone.
e.g. Thread thread = new Thread(runnable); //why would you do this?
ExecutorService executor = Executors.newCachedThreadPool();
executor.submit(runnable); // <- when you can do this.

19. 19
Concurrency: Best Practices
● Work with higher level concurrency control constructs. You don’t need to deal
with Object.wait() and Object.notify().
● Most of the time concurrency requirements you will encounter would be
consumer-producer. Use a subclass of java.util.concurrent.BlockingQueue.
● If you are doing something funky, consider using:
○ LMax Disruptor – Solves performance problems in JDK concurrent framework/collections.
○ RxJava/ Akka.io / Spring Reactor - More higher-level abstractions for data intensive
applications.
○ Netty.io – A framework for developing high throughput network applications

20. 20
Conclusion
● Dealing with concurrency is hard when:
○ Lack of ‘working knowledge’
○ Best practices not followed.
● Adhere to server/framework’s preferred way of doing it.
● Prefer higher-level abstractions.
● Designing/choosing the concurrency scheme upfront is important.
● Be careful not to have too much of ‘global mutable state’

21. 21
References
● https://smartbear.com/blog/test-and-monitor/why-johnny-cant-write-multithreaded-programs/
● https://towardsdatascience.com/is-concurrency-really-increases-the-performance-8cd06dd762f6
● https://www.quora.com/What-are-some-good-and-bad-use-cases-for-concurrency-models-like-
threading-actors-and-STM-Software-Transactional-Memory-When-should-I-choose-one-over-the-
other
● https://joearms.github.io/published/2016-01-26-The-Unintentional-Side-Effects-of-a-Bad-
Concurrency-Model.html
● Concurrency – The good, the bad, the ugly - https://www.youtube.com/watch?v=OJfS7K-Vkgk
● https://javarevisited.blogspot.com/2015/05/top-10-java-multithreading-and.html
● https://www.youtube.com/watch?v=OJfS7K-Vkgk

22. Thank You !

23. 23
Exercise #1 – Detecting a Deadlock
● It’s a (Black) Friday night. You are in the application support duty roaster !!!
● Suddenly you are getting a loads of entries (in Splunk) :
connection timeouts when invoking order management service.
● Customers can’t place orders  Business is loosing money  Your lead is
freaking out  Pressure is building !!!
● How are you going to figure out what’s going on ?
Reference: https://dzone.com/articles/how-analyze-java-thread-dumps

24. 24
Exercise #2 – Find which thread is spinning
● It’s a (Black) Friday night. You are in the application support duty roaster !!!
● Suddenly you are getting a loads of entries (in Splunk) :
connection timeouts when invoking package management service.
● Customers can’t place orders  Business is loosing money  Your lead is
freaking out  Pressure is building !!!
● How are you going to figure out what’s going on ?