Manju

Greetings! Protecting shared, mutable data is difficult. Easiest way to guarantee thread safety is not to share. This technique is called thread confinement. One way to achieve this is using ThreadLocal class. This uses internal thread-local variable to store data by the executing thread and provides get() and set() methods to access it. It internally get the current thread (Thread.currentThread()) and a custom Map to assign data directly in Thread class. This behaves like Map<Thread, T> object (though this is not how it is done). ThreadLocal stores per-thread value and provides set(), get() methods to access it. public class TimeHolder { private static ThreadLocal<Long> threadLocal = ThreadLocal.withInitial(() -> System.currentTimeMillis()); public Long get() { return threadLocal.get(); } public void set() { threadLocal.set(System.currentTimeMillis()); } public void print() { System.out.println

Greetings! Problem with shared object is any thread can modify it. What if we have an object type which can not be changed? This is where immutable objects come into play. Immutable object is an object that once created it's state can not be changed. We can construct an immutable object by protecting the inner state by not sharing any setter method to change inner state. How to construct an immutable class? Do not provide setter methods. Make all fields final and private. Make the constructor private and use a factory method to create objects. Do not share mutable objects. If mutable objects need to be shared, share a copy. If the constructor accepts external mutable objects as parameters create a copy of them. Make the class final to avoid sub classing. public final class Counter { private final int count; private Counter(int initialCount) { this.count = initialCount; } public static Counter newCounter(int initialCount)

Greetings! Synchronization is not only protecting critical sections. It also provide memory visibility. That means, when one thread modify the state other threads should be able to see the changes without any issue. We should not share objects without proper synchronization. Unless it will lead to stale data which causes; Unexpected exceptions. Infinite loops. Corrupted data. Inaccurate results. Out of thin air safety A thread can see some value of shared data which is updated by another thread (even it is stale) is called out-of-thin-air safety. All threads should see most up-to-date values of shared mutable variables. Volatile It is a weaker form of synchronization. Do not re-order. Put in shared memory (not in cpu's cache). Good for simple situations like maintaining a flag, completion flag. Does not guarantee atomicity. Guarantee only visibility. Publishing Make an object available outside of its current scope. public variables. non p

Greetings! volatile is a keyword in Java. When we declare a variable as volatile it doesn't store in CPU cache. Instead it is put in shared memory. Because of that multiple threads can access the same memory location and get the updated value. Hence this is considered as a weaker synchronization mechanism. volatile is not suitable for atomic operations. It is best suited for single operations like a flag. private volatile boolean completed; Store in main memory. never store in thread locally. Guarantee visibility. Not suitable for atomic operations like read-modify-write. No lock involved. Never block other threads. Suitable for operations like having a flag. Can be used if the value doesn't depend on previous value. Have a performance hit because it doesn't store in cache. Weaker form of synchronization.