Java Multithreading

Why we need Threads?

1.  Responsiveness - can be achieved with Concurrency (Multitasking)
2.  Performance      - can be achieved with Parallelism

Context Switching

•  Context switching is expensive 
•  Context switching between threads is a lot cheaper than context switching between processes
•  Too many threads - OS spending more time in management than real productive work
•  Thread consuming less resources than processes.

Thread scheduling 

• There are different possible of ways to schedule
• First Come First Serve - problem with that if long threads come first other thread will be unresponsiveness, it is called starvation  
• Short Job First - this time longest job will wait
• Epochs -  OS divides CPU time to moderately sized pieces called Epochs.  OS allocates different time for each thread in each Epoch. It is done according to Dynamic Priority calculations. 

Thread creation & it's methods

• Two way of creating threads
• Implement Runnable interface provide in construction of Thread object
• Extend Thread object
• Number of threads should be equal to number of cores in machines
• Use thread.setUncaughtExceptionHandler  to catch unchecked exceptions during run-time.
  You can either clean up resources or log the issue for trouble shooting purposes
• Stopping thread from another thread has two ways
• Thread.interrupt() - you can interrupt the thread in two scenarios
1. If the thread is executing a method that throws an InterruptedException
2. If the thread code is handing the interrupt signal explicitly
• Daemon threads - background threads that do not prevent the application from exiting if the main thread terminates. Other reason , code in a worked thread is not under our control, and we do not want it to block our application from terminating
• By default, at least if one thread is running application will not stop even main thread stopped. So we need to stop all threads gracefully
• Thread.join() 
• calling the join() method has a synchronization effect. join() creates a happens-before relationship
• Happens-before :  This means that when a thread t1 calls t2.join(), then all changes done by t2 are visible in t1 on return. However, if we do not invoke join() or use other synchronization mechanisms, we do not have any guarantee that changes in the other thread will be visible to the current thread even if the other thread has completed.
• When we invoke the join() method on a thread, the calling thread goes into a waiting state. It remains in a waiting state until the referenced thread terminates.
• Timed join() is dependent on the OS for timing. So, we cannot assume that join() will wait exactly as long as specified.
• In order to avoid creation/destroy of threads there is thread pooling mechanisms.

Data Sharing between Threads

• Thread local variables are stored in stack . Like local variable and local object references
• Shared information stored in Heap. Like Objects, class members and static variables
• Critical section guarded with synchronized keyword. Two ways of doing this
• synchronized on method level - Monitor

• synchronized inside method with explicit object - lock

• Re-entrant - thread in synchronized method/section can access to other synchronized method/section  

Atomic Operations

• Object reference assignment - including getter, setter for exmaple
• Primitive type assignments except long and double. Because long and double 64 bit long 
• We can define long and double volatile.  With volatile they are guaranteed in single HW operation
• Knowledge of atomic operations is key to us create high performance applications 

Concurrency problems

• Race condition : two threads working on same shared object. One of them modifying the object , due to OS scheduling  it may cause incorrect results. Core of the problem is non-atomic operation performed on shared object . Solution - identifying  the critical section where race condition happened and protecting with  synchronized block.
  https://stackoverflow.com/questions/34510/what-is-a-race-condition
• Data race : solution, establish happens-before semantics by one of these methods
• synchronization of method
• using volatile. No compiler re-ordering will happen. whatever code before and after volatile will run as is.

Locking Strategies

• Coarse-grained strategy : lock whole object. Might impact the performance
• Fine-grained strategy  : lock party of shared objects using lock object

Deadlock 

• Condition to leads to deadlock
• Mutual exclusion
• Hold and wait
• Non-preemptive allocation 
• Circular wait
• Solution to deadlock is avoid one the conditions mentioned above
• Avoid circular wait - this one easiest one. 
• Deadlock detection
• Watchdog
• Thread interruption 
• tryLock operation

Reentrant Lock

•  Similar locking with synchronized locking but provides more control over lock with advanced operations
•  Pattern to use it
  
  class SharedData{
     private Lock lockObject = new ReenterantLock();
  
  
     public void method(){
          lockObject.lock();
          try{
               userSharedObject();
         }finally(){
              lockObject.unlock();
          } 
     }
  }
• In order to avoid starvation - one thread is continuously using shared object but other are waiting - you can set true into constructor of  ReenterantLock(true) object. which is fairness flag. But this one comes with cost. Use only when you really need it.
• ReenterantLock.lockInterrupility()
• ReenterantLock.tryLock()
• ReenterantReadWriteLock - if our shared object is read intensive we can use it otherwise it can perform worse then traditional locks. Example of using read-write lock is caching where system is read intensive. Multiple read threads can access the shared object and lock it, we can see number of concurrent read threads. Only one write thread can lock the shared object no other write/read threads can access during write lock. 

Semaphore

• Can restrict number of threads accessing to shared data.
• similar to lock but different in many ways. 
• One use case if Producer-Consumer using semaphore. Producer-consumer pattern used in web sockets, video streaming, Actor models

Condition variable

• 
  

Other methods

• wait
• notify() and notifyAll()

Lock free programming

• AtomicInteger, AtomicLong...
• AtomicReferences

Reference

https://www.udemy.com/course/java-multithreading-concurrency-performance-optimization/